Metrics server unable to fetch the target metrics after downloading components.yaml file from the metrics server installation URL .

[PranitRout07]

ISSUE : Metrics server unable to fetch the target metrics after downloading components.yaml file from the metrics server installation URL .

Metrics Server Installation URL : https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

ISSUE DESCRIPTION :

Here i have first downloaded the components.yaml using the above URL . Then applied the components.yaml , but it is unable to detect the target metrics . Here in the below screenshot you can see the hpa resource is unable fetch the target metrics .

Then added the following lines at line number 140 .

        command:
        - /metrics-server
        - --kubelet-insecure-tls
        - --kubelet-preferred-address-types=InternalIP

After adding the lines , then again i have applied the components.yaml file using kubectl . Now hpa can detect the target metrics .

Question

Why the lines are not directly included at line number 140 in the components.yaml , so that it can work directly after downloaded from the URL ?

/kind bug

[Chander84]

I have a different experience, If I download the components.yaml file using the https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml I am getting empty components.yaml. I am using EKS 1.26 version with fargate nodes. Please suggest me for the fix.

sh "curl -o components.yaml https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml"
sh "ls -ltr"

output:

• curl -o components.yaml https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
  % Total % Received % Xferd Average Speed Time Time Time Current
  Dload Upload Total Spent Left Speed

  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
  [Pipeline] sh

• ls -ltr
  -rw-r-----. 1 root root 0 Apr 9 12:33 components.yaml

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[logicalhan]

/kind support
/triage accepted