Introduction

Checking whether a Kubernetes cluster is running fine is not one command. A healthy cluster means the control plane is reachable, nodes are ready, core system pods are stable, and normal workloads can schedule and serve traffic. A practical health check is therefore a short sequence of targeted checks rather than a vague "cluster looks up" assumption.

Start with API Reachability and Node Health

First confirm that kubectl can talk to the cluster and that nodes are ready.

kubectl cluster-info
kubectl get nodes

A good initial result shows the API server reachable and nodes in Ready state. If the API server is unreachable, there is no point debugging application pods yet because the control plane itself is already the primary issue.

Inspect Core System Pods

Next, look at the Kubernetes system namespace.

kubectl get pods -n kube-system

You want core components and add-ons to be running or completed as expected. Repeated restarts, pending pods, or crash loops in kube-system often point to infrastructure-level trouble rather than app-level trouble.

Pay attention to:

• DNS pods
• network plugin pods
• metrics or ingress components if your platform depends on them
• control-plane static pods in self-managed clusters

Check Recent Cluster Events

Events often reveal issues faster than reading many individual pod specs.

kubectl get events -A --sort-by=.lastTimestamp

This can expose repeated image-pull failures, scheduling failures, node-pressure events, volume mount issues, or readiness probe failures. A cluster may look "mostly up" while events clearly show widespread trouble.

Validate Workload Scheduling

A cluster is not healthy just because the system pods are alive. It must also schedule real workloads. Check a representative deployment or run a small smoke-test pod.

kubectl run smoke-test --image=nginx --restart=Never
kubectl get pod smoke-test -w

If the pod schedules, pulls, starts, and reaches Running, the cluster is at least capable of basic workload execution. Clean up afterward:

kubectl delete pod smoke-test

Look at Resource Pressure

Clusters often fail gradually because of CPU, memory, or disk pressure. When metrics are available, inspect node usage.

kubectl top nodes
kubectl top pods -A

If kubectl top is unavailable, confirm whether metrics-server is installed rather than assuming the command itself is the problem.

Distinguish Cluster Health from Application Health

A healthy cluster can still host a broken application, and a broken cluster can make healthy applications look broken. Separate the questions:

• is the control plane working
• are nodes ready
• can pods schedule and start
• is this specific application behaving correctly

That separation prevents circular debugging.

One-Time Checks Versus Continuous Monitoring

Manual health checks are useful during debugging, but production clusters also need continuous monitoring and alerting. A cluster can pass a quick smoke test now and still degrade minutes later under load, disk pressure, or control-plane instability. Use the manual checks as diagnosis tools, not as the entire monitoring strategy.

Common Pitfalls

• Treating kubectl cluster-info success as proof that the whole cluster is healthy.
• Looking only at application namespaces and ignoring kube-system.
• Ignoring events, which often reveal the actual cluster-wide problem quickly.
• Declaring the cluster healthy without verifying workload scheduling.
• Confusing application bugs with cluster infrastructure problems.

Summary

• A healthy Kubernetes cluster is reachable, has ready nodes, stable system pods, and working workload scheduling.
• Start with API and node checks, then inspect kube-system and recent events.
• Use a small smoke-test workload to prove real scheduling and startup behavior.
• Check resource pressure when nodes or pods behave unpredictably.
• Always separate cluster health from application health when troubleshooting.