### Install Metrics Server Chart

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/charts/metrics-server/README.md

Installs or upgrades the metrics-server chart using Helm. This command deploys the metrics-server to your Kubernetes cluster.

```shell
helm upgrade --install metrics-server metrics-server/metrics-server
```

--------------------------------

### Install Latest Metrics Server Release

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md

Installs the latest release of Metrics Server using its official YAML manifest. Ensure your cluster meets the specified requirements before installation.

```shell
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
```

--------------------------------

### Start Local Development with Live Reload

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/CONTRIBUTING.md

Initiate a local development environment using Kind and Skaffold for live code reloading. This allows for rapid iteration during development.

```sh
kind create cluster
skaffold dev
```

--------------------------------

### HPA Description Output Example

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

This is an example of the output from `kubectl describe hpa`, showing common events and conditions related to scaling failures.

```text
Name:                                                     pwa
Namespace:                                                pwa
Labels:                                                   app=pwa
env=prod
Annotations:                                              <none>
CreationTimestamp:                                        Wed, 23 Mar 2022 12:29:16 +0000
Reference:                                                Deployment/pwa
Metrics:                                                  ( current / target )
resource memory on pods  (as a percentage of request):  <unknown> / 80%
resource cpu on pods  (as a percentage of request):     <unknown> / 70%
Min replicas:                                             14
Max replicas:                                             24
Deployment pods:                                          16 current / 0 desired
Conditions:
Type           Status  Reason                   Message
  ----           ------  ------                   -------
AbleToScale    True    SucceededGetScale        the HPA controller was able to get the target's current scale
ScalingActive  False   FailedGetResourceMetric  the HPA was unable to compute the replica count: failed to get memory utilization: missing request for memory
Events:
Type     Reason                        Age                   From                       Message
  ----     ------                        ----                  ----                       -------
Warning  FailedGetResourceMetric       17m (x8 over 19m)     horizontal-pod-autoscaler  failed to get cpu utilization: missing request for cpu
Warning  FailedComputeMetricsReplicas  17m (x8 over 19m)     horizontal-pod-autoscaler  invalid metrics (2 invalid out of 2), first error is: failed to get memory utilization: missing request for memory
Warning  FailedGetResourceMetric       4m32s (x61 over 19m)  horizontal-pod-autoscaler  failed to get memory utilization: missing request for memory
```

--------------------------------

### Get Metrics Server Configuration Flags

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md

Run this command to view all available configuration flags for the Metrics Server. This is useful for understanding customization options.

```shell
docker run --rm registry.k8s.io/metrics-server/metrics-server:v0.8.0 --help
```

--------------------------------

### Metrics Server Pod Status Example

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

This output shows a metrics-server pod that is not in a running state, indicated by '0/1' in the READY column. This is a symptom of the 'Metrics-server pod failed to reach running status' issue.

```text
NAME                                           READY   STATUS    RESTARTS   AGE
metrics-server-dbf765b9b-mhqm7                 0/1     Running   0          11m
```

--------------------------------

### Install Latest Metrics Server HA (Kubernetes v1.21+)

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md

Use this command to install the latest Metrics Server release in high availability mode for Kubernetes versions 1.21 and newer.

```shell
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml
```

--------------------------------

### Install Latest Metrics Server HA (Kubernetes v1.19-1.21)

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md

Use this command to install the latest Metrics Server release in high availability mode for Kubernetes versions 1.19 to 1.21.

```shell
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability.yaml
```

--------------------------------

### Metrics Server Log Example for Certificate Error

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

An example log entry from the metrics-server indicating a problem with authenticating a client certificate, specifically an 'unknown authority' error.

```text
E0524 01:37:36.055326       1 authentication.go:65] Unable to authenticate the request due to an error: x509: certificate signed by unknown authority
```

--------------------------------

### Example Metrics Server Log for Missing Pod Metrics

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

This log line indicates that the Metrics Server could not find metrics for a specific pod. It helps in diagnosing why `kubectl top pods` might not be returning data.

```text
W1106 20:50:15.238493 73592 top_pod.go:265] Metrics not available for pod default/example, age: 22h29m11.238478174s
error: Metrics not available for pod default/example, age: 22h29m11.238478174s
```

--------------------------------

### Example Invalid Kubelet Resource Metrics

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

This JSON output illustrates an invalid response from the Kubelet Summary API where CPU and memory usage values are zero. This indicates a problem with Kubelet configuration or reporting.

```json
{
  "cpu": {
    "time": "2022-01-19T13:12:56Z",
    "usageNanoCores": 0,
    "usageCoreNanoSeconds": 0
  },
  "memory": {
    "time": "2022-01-19T13:12:56Z",
    "availableBytes": 16769261568,
    "usageBytes": 0,
    "workingSetBytes": 0,
    "rssBytes": 0,
    "pageFaults": 0,
    "majorPageFaults": 0
  }
}
```

--------------------------------

### Add Metrics Server Helm Repository

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/charts/metrics-server/README.md

Adds the official metrics-server Helm repository to your local Helm configuration. This is a prerequisite for installing the chart.

```shell
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
```

--------------------------------

### Count Pod Metrics on First Node (with jq)

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

This command uses `jq` to count the number of pods for which metrics are reported by the first node in the cluster. It requires `jq` to be installed.

```sh
kubectl get --raw /api/v1/nodes/$(kubectl get nodes -o json  | jq -r '.items[0].metadata.name')/proxy/stats/summary | jq '.pods | length'
```

--------------------------------

### Helm Chart Values for cert-manager Integration

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/charts/metrics-server/README.md

Configure the Helm chart to use cert-manager for certificate issuance. Requires cert-manager to be installed beforehand.

```yaml
apiService:
  insecureSkipTLSVerify: false
tls:
  type: cert-manager
```

--------------------------------

### Example Metrics Server Scrape Errors

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

These log messages indicate that the Metrics Server is failing to scrape metrics from the Kubelet, often due to network timeouts or connectivity issues. They are crucial for diagnosing why the metrics-server pod might be failing.

```text
"Failed to scrape node" err="Get \"https://192.168.65.4:10250/metrics/resource\": context deadline exceeded" node="docker-desktop"
"Failed probe" probe="metric-storage-ready" err="no metrics to serve"
```

--------------------------------

### Check Kubelet Resource Metrics (v0.6+)

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

For versions 0.6.x and later, use this command to directly query Kubelet for resource metrics. This helps determine if the issue lies with Kubelet or Metrics Server.

```sh
NODE_NAME=<Name of node in your cluster>
kubectl get --raw /api/v1/nodes/$NODE_NAME/proxy/metrics/resource
```

--------------------------------

### Check Kubelet Summary API (v0.5.x-)

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

This command queries the Kubelet's Summary API to retrieve pod statistics. An empty pod list indicates a Kubelet issue rather than a Metrics Server problem.

```sh
NODE_NAME=<Name of node where pod runs>
kubectl get --raw /api/v1/nodes/$NODE_NAME/proxy/stats/summary
```

--------------------------------

### Check Kubelet Summary API (v0.5-)

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

For versions 0.5.x and earlier, query the Kubelet Summary API to check node resource usage. This helps isolate problems to Kubelet if metrics are zero or timestamps are missing.

```sh
NODE_NAME=<Name of node in your cluster>
kubectl get --raw /api/v1/nodes/$NODE_NAME/proxy/stats/summary
```

--------------------------------

### Run Unit Tests

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/CONTRIBUTING.md

Execute unit tests to verify the correctness of individual components. This is a fundamental step in ensuring code stability.

```sh
make test-unit
```

--------------------------------

### Run Version Tests

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/CONTRIBUTING.md

Execute tests related to versioning to ensure compatibility and correct version handling. This is important for release management.

```sh
make test-version
```

--------------------------------

### Check Kubelet Summary API with jq (v0.5-)

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

An alternative method for versions 0.5.x and earlier, using 'jq' to parse the Kubelet Summary API response and extract CPU and memory fields. This is useful for quickly identifying zero usage values.

```sh
NODE_NAME=<Name of node in your cluster>
kubectl get --raw /api/v1/nodes/$NODE_NAME/proxy/stats/summary | jq '{cpu: .node.cpu, memory: .node.memory}'
```

--------------------------------

### Execute End-to-End Tests with Go

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/CONTRIBUTING.md

Run end-to-end tests using the Go testing framework. This command is used for detailed testing of the system's integration points.

```go
go test test/e2e_test.go -v -count=1
```

--------------------------------

### Create Front-Proxy CA ConfigMap

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

Create a Kubernetes ConfigMap named `front-proxy-ca` in the `kube-system` namespace containing the front-proxy CA certificate. This is a step to resolve front-proxy certificate issues.

```sh
kubectl -nkube-system create configmap front-proxy-ca --from-file=front-proxy-ca.crt=/etc/kubernetes/pki/front-proxy-ca.crt -o yaml | kubectl -nkube-system replace configmap front-proxy-ca -f -
```

--------------------------------

### Run End-to-End Tests

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/CONTRIBUTING.md

Execute end-to-end tests to validate the system's behavior in a production-like environment. This ensures all components work together as expected.

```sh
make test-e2e
```

--------------------------------

### Display Node Metrics

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

Use this command to check if metrics are being reported for all nodes. Look for '<unknown>' values indicating a problem.

```sh
$ kubectl top nodes
NAME      CPU(cores)  CPU%       MEMORY(bytes)  MEMORY%
master-1  192m        2%         10874Mi        68%
node-1    582m        7%         9792Mi         61%
node-2    <unknown>   <unknown>  <unknown>      <unknown>
```

--------------------------------

### Mount ConfigMap and Add Flag to Metrics Server Deployment

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

Modify the Metrics Server deployment to mount the `front-proxy-ca` ConfigMap and add the `--requestheader-client-ca-file` flag. This ensures Metrics Server uses the correct CA for front-proxy authentication.

```yaml
- args:
  - --requestheader-client-ca-file=/ca/front-proxy-ca.crt # ADD THIS!
  - --cert-dir=/tmp
  - --secure-port=10250
  volumeMounts:
  - mountPath: /tmp
    name: tmp-dir
  - mountPath: /ca # ADD THIS!
    name: ca-dir

volumes:
- emptyDir: {}
  name: tmp-dir
- configMap: # ADD THIS!
    defaultMode: 420
    name: front-proxy-ca
  name: ca-dir
```

--------------------------------

### APIService with insecureSkipTLSVerify enabled

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/charts/metrics-server/README.md

Shows the default APIService configuration where TLS verification is skipped. This is typically used with self-signed certificates.

```yaml
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v1beta1.metrics.k8s.io
spec:
  #..
  insecureSkipTLSVerify: true # <-- see here
  service:
    name: metrics-server
  #..
```

--------------------------------

### Check Metrics Server Logs

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

Retrieve logs from the metrics-server pods to diagnose authentication or certificate issues. This command targets pods with the label `k8s-app=metrics-server` in the `kube-system` namespace.

```sh
kubectl logs -n kube-system -l k8s-app=metrics-server --container metrics-server
```

--------------------------------

### Metrics Server Pod Metrics Request Flow

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md

Illustrates the sequence of interactions when a user requests pod metrics via kubectl top pods. It shows how Metrics Server fetches and aggregates data.

```mermaid
sequenceDiagram
    participant User
    participant APIServer
    participant MS as Metrics-server


    User->>APIServer: GET /apis/metrics.k8s.io/v1beta1/pods
    APIServer->>MS: GET /apis/metrics.k8s.io/v1beta1/pods
    MS->>MS: use Pod Informer to get a list of pods
    MS->>MS: lookup each pod's memory and cpu from its in-memory cache
    MS->>APIServer: metrics.PodMetricsList
    APIServer->>User: Response
```

--------------------------------

### Metrics Server Node Metrics Collection Flow

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/README.md

Details how Metrics Server periodically collects resource metrics (CPU and memory) from Kubelets for nodes and their pods. It highlights the use of the Node informer and direct Kubelet requests.

```mermaid
sequenceDiagram
    participant MS as Metrics-server
    participant KL as Kubelet

    MS->>MS: use Node informer to get a list of nodes and their IPs periodically 
    MS->>KL: GET /metrics/resource
    KL->>MS: returns memory and cpu data for each pod
    MS->>MS: update its in-memory cache to store memory and cpu data for each pod
```

--------------------------------

### Describe aws-auth ConfigMap

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

This command describes the aws-auth ConfigMap in the kube-system namespace. It is used to verify authentication configurations when running Metrics Server in Amazon EKS.

```sh
kubectl describe -n kube-system configmap aws-auth
```

--------------------------------

### Run Static Code Validation

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/CONTRIBUTING.md

Execute the linting process to ensure code quality and adherence to project standards. This command checks for common code issues.

```sh
make lint
```

--------------------------------

### Helm Chart Values for Helm-generated Certificate

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/charts/metrics-server/README.md

Configure the Helm chart to generate its own self-signed certificate and manage the APIService CA bundle. This is the easiest option but not GitOps friendly.

```yaml
apiService:
  insecureSkipTLSVerify: false
tls:
  type: helm
```

--------------------------------

### Helm Chart Values for Existing Secret

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/charts/metrics-server/README.md

Configure the Helm chart to use a pre-existing Kubernetes Secret for TLS. The Secret must contain 'tls.key' and 'tls.crt' keys, and 'apiService.caBundle' must be provided.

```yaml
apiService:
  insecureSkipTLSVerify: false
  caBundle: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

tls:
  type: existingSecret
  existingSecret:
    name: metrics-server-existing
```

--------------------------------

### Describe HPA Status

Source: https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md

Use this command to check the status of a Horizontal Pod Autoscaler and identify issues related to resource utilization.

```sh
kubectl describe hpa
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.