metrics-server

Metrics Server collects resource usage metrics specifically for autoscaling. It exposes:

• CPU: Reported as the average core usage in CPU units (e.g., 1 vCPU/Core or 1 hyperthread). It is derived from a rate over a cumulative CPU counter provided by the kernel. The time window used for this calculation is available in the window field of the Metrics API.
• Memory: Reported as the working set at the instant of collection, measured in bytes. This includes all anonymous (non-file-backed) memory and typically some cached (file-backed) memory.

Metrics use standard Kubernetes Metric System prefixes (e.g., n for $10^{-9}$ and Ki for $2^{10}$).

Note: Metrics Server does not calculate these values; it aggregates values exposed by Kubelet. It does not provide utilization percentages (e.g., % CPU used); those are calculated client-side by tools like kubectl top or HPA.

To install the latest Metrics Server release using a single YAML manifest, use the kubectl apply command pointing to the official release URL.

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

Once the repository has been added, you can install or upgrade the metrics-server chart using the helm upgrade --install command. This command ensures the chart is installed if it is not already present.

helm upgrade --install metrics-server metrics-server/metrics-server

This is the simplest hardening method. Helm generates a self-signed certificate during deployment and automatically injects the apiService.caBundle.

Note: This method is not GitOps friendly (e.g., Argo CD) because Helm generates new certificates on every deploy, which will trigger drift detection. It is suitable for deployments via Terraform or Flux.

apiService:
  insecureSkipTLSVerify: false
tls:
  type: helm

To run metrics-server following security best practices, implement the following:

1. Enable RBAC: Ensure the cluster has Role-Based Access Control enabled.
2. Disable Kubelet Read-Only Port: Ensure the Kubelet read-only port is disabled.
3. Validate Kubelet Certificates: Mount your CA file and use the --kubelet-certificate-authority flag to validate certificates.
4. Use Custom Certificates: Instead of insecure flags, consider providing your own certificates using --tls-cert-file and --tls-private-key-file.
5. Avoid Insecure Flags: Do not use --deprecated-kubelet-completely-insecure or --kubelet-insecure-tls in production environments.

Use this option to reuse an existing Kubernetes Secret (e.g., one created via Terraform or synced from AWS Secrets Manager/HashiCorp Vault).

Requirements:

1. The Secret must contain the keys tls.key and tls.crt in its data field.
2. You must provide the issuing CA certificate (or the certificate itself) via apiService.caBundle to allow apiService.insecureSkipTLSVerify to be set to false.

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

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

You can run multiple instances of metrics-server for High Availability. Each instance scrapes all nodes, but only one instance actively serves the Metrics API.

To ensure requests are properly load balanced across your instances, it is recommended to enable aggregator routing on your kube-apiserver using the following flag:

--enable-aggregator-routing=true

Metrics Server provides default resource requests (100m CPU, 200MiB memory) suitable for clusters up to 100 nodes. For clusters exceeding 100 nodes, you should scale resources proportionally by allocating an additional:

• 1m core of CPU per node
• 2MiB of memory per node

You can use cert-manager to manage certificates for metrics-server.

Requirement: cert-manager must be installed in the cluster before installing the metrics-server Helm chart.

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

Metrics Server can be deployed in high availability mode by using specific manifests based on your Kubernetes version. This requires a cluster with at least 2 nodes available for scheduling.

To maximize efficiency in HA mode, it is recommended to add the --enable-aggregator-routing=true CLI flag to the kube-apiserver so that requests are load balanced between instances.