Dedicated servers · Question & answer

How do I check Kubernetes health on dedicated servers safely?

Check the Kubernetes control plane, worker nodes and workloads as separate layers. A reachable API or a Ready node does not prove every application is healthy. Always confirm the cluster context before querying a dedicated-server deployment.

AdvancedDedicated-server Kubernetes clustersCommands run from an authorised Linux administration shell with kubectl
Go to the answer

Before you start

  • A trusted kubeconfig and permissions to read the target nodes, system pods and API health endpoint.

Instructions

1. Confirm the context explicitly

Review context names without printing credential data. Replace app-cluster in every later command with the verified context for this server cluster.

Remote Linux shell
kubectl config get-contexts

Lists configured context identities; it does not change the current context.

2. Read API and node health

Query the intended cluster directly. API readiness checks cover the contacted endpoint; node status needs separate review.

Remote Linux shell
kubectl --context app-cluster get --raw='/readyz?verbose'
kubectl --context app-cluster get nodes

Reads API readiness and node conditions for the explicitly selected context. No resource is changed.

3. Inspect control-plane evidence

Review the expected system pods for this deployment. Managed or external control-plane components may not appear as local pods. If etcd is used, its voting-member quorum is separate from worker count; adding workers does not repair lost etcd quorum.

Remote Linux shell
kubectl --context app-cluster --namespace kube-system get pods

Lists system-namespace pods in the selected cluster. Confirm their intended deployment and current state.

Check the result

  • The intended API endpoint is ready, expected nodes are healthy and required system components are running.
  • Application checks and the documented etcd/quorum status support the wider health conclusion.

Troubleshooting

A query returns Forbidden
Use the approved read role or ask the cluster owner for the required evidence. Do not grant blanket cluster-admin access to bypass an inspection permission boundary.

Official references

Use the documentation for your installed version when a flag, service name or platform feature differs.