Deploy the Metrics Server

In this guide you will learn how to set up metrics-server.

Metrics Server enables use of the Horizontal Pod Autoscaler and Vertical Pod Autoscaler. It does this by gathering metrics data from the kubelets in a cluster. By default, metrics-server can’t verify the certificates the kubelets present: metrics-server connects to each kubelet by IP address, but the kubelet’s default certificate doesn’t list an IP address among its valid names.

You can solve this in two ways:

• Skip certificate validation: Simpler to set up, but metrics-server no longer verifies it’s actually talking to the kubelet it thinks it is.
• Rotate kubelet certificates: More setup, but metrics-server can verify them normally and certificate validation stays intact.

Option 1: Skip certificate validation

Metrics Server’s own documentation describes --kubelet-insecure-tls as “for testing purposes only.” This disables certificate verification between metrics-server and every kubelet in your cluster. Use Option 2 for anything production.

Step 1: Download the upstream metrics-server manifest:

curl -sL -o components.yaml https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Step 2: Edit components.yaml and add --kubelet-insecure-tls alongside the existing args in the metrics-server container spec.

Step 3: Apply it:

kubectl apply -f components.yaml

Option 2: Rotate kubelet certificates

This keeps certificate validation intact by requesting kubelet certificates that include the node’s IP address, instead of telling metrics-server to stop checking.

Step 1: Apply the following Machine Config snippet to all nodes, to enable kubelet certificate rotation:

apiVersion: v1alpha1
kind: KubeletConfig
extraArgs:
  rotate-server-certificates: true

On Talos versions 1.13 and earlier, use the older deprecated configuration field:

machine:
  kubelet:
    extraConfig:
      serverTLSBootstrap: true

An older form of this setting, machine.kubelet.extraArgs.rotate-server-certificates: true, still works but is deprecated by the kubelet in favor of the config-file field shown above.

Step 2: Install the Kubelet Serving Certificate Approver — which automatically approves the Certificate Signing Requests the kubelets generate — along with metrics-server itself.

During bootstrap

Add the following snippet to the Cluster Config of the node that will be handling the bootstrap process, so both are installed automatically as part of bootstrap:

On Talos versions 1.13 and earlier, use the deprecated cluster.extraManifests field instead — see inlineManifests and extraManifests for the older format.

apiVersion: v1alpha1
kind: KubeExternalManifestConfig
name: kubelet-serving-cert-approver
url: https://raw.githubusercontent.com/alex1989hu/kubelet-serving-cert-approver/main/deploy/standalone-install.yaml
---
apiVersion: v1alpha1
kind: KubeExternalManifestConfig
name: metrics-server
url: https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

After bootstrap

Once the cluster is online, install both with kubectl:

kubectl apply -f https://raw.githubusercontent.com/alex1989hu/kubelet-serving-cert-approver/main/deploy/standalone-install.yaml
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Verify metrics-server is working

Whichever option you chose, confirm metrics-server is running and actually returning data:

kubectl get deployment metrics-server -n kube-system
kubectl top nodes

kubectl top nodes should return CPU and memory usage for each node. If it returns an error instead, metrics-server is running but can’t reach or verify the kubelets, revisit whichever option you configured above.

If you’ve just switched from Option 1 to Option 2, or redeployed metrics-server for any other reason, check the pod count before trusting a working result:

kubectl get pods -n kube-system -l k8s-app=metrics-server

A rolling update doesn’t remove the previous pod until the new one passes its readiness check. If the new pod doesn’t become ready, the old pod can keep serving traffic — including a kubectl top nodes that still returns data — even though the configuration you just applied isn’t the one actually running.