Metrics Server

Learn Metrics Server for Kubernetes resource metrics, kubectl top, HPA support, and its limits compared with full observability systems.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: Metrics Server collects CPU and memory metrics for Pods and nodes and feeds features such as kubectl top and HPA.

🔍 What Is It?

Metrics Server is a lightweight cluster add-on that exposes resource metrics through the Kubernetes metrics API.

🎯 Why Do We Need It?

Kubernetes needs current CPU and memory metrics for autoscaling and basic operational inspection.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

A platform team installs Metrics Server so developers can run kubectl top pods and HPA can scale Deployments based on CPU utilization.

⚙️ How It Works

Metrics Server scrapes kubelet summary metrics from nodes and exposes aggregated metrics through the metrics.k8s.io API. It is not a long-term metrics store.

💻 Example

Metrics Server usage — Commands and autoscaling dependency.

text
kubectl top nodes
kubectl top pods -n orders-prod

HPA dependency:
  CPU/memory resource metrics
  -> metrics.k8s.io
  -> Horizontal Pod Autoscaler
  -> Deployment replica changes

🤔 Common Confusions

❓ Is Metrics Server Prometheus?

No. Metrics Server is for current resource metrics. Prometheus stores and queries broader time-series metrics.

❓ Does Metrics Server store historical data?

No. Use Prometheus or another monitoring platform for history.

❓ Can HPA use Metrics Server?

Yes, for CPU and memory resource metrics.

🚨 Common Production Issues

**Metrics Server missing** breaks kubectl top and resource-based HPA.

**TLS/kubelet access issues** prevent metrics collection.

**Expecting history** from Metrics Server leads to poor incident analysis.

**No resource requests** weakens HPA usefulness.

✅ Best Practices

Install and monitor Metrics Server in production clusters

Use Prometheus for historical and custom metrics

Set resource requests for HPA calculations

Validate metrics during cluster upgrades

🏛️ Architect's Note

Senior Architect's Perspective

Metrics Server is plumbing for autoscaling, not your observability platform. Keep that distinction clear during architecture discussions.

💬 Frequently Asked Questions

Interview: How would you explain Metrics Server in a real Kubernetes project?

Metrics Server should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Metrics Server?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1Metrics Server provides current CPU/memory metrics
2It supports kubectl top and HPA
3It is not a historical metrics store
4Prometheus complements it

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages