troubleshooting-kubernetes

Inspect the Pod with kubectl describe, then read current logs and previous container logs with kubectl logs --previous. Check the exit code, probes, command/args, and resource limits to distinguish application startup failure from probe or resource issues before restarting anything.

Compare the Service selector and ports against Pod labels using kubectl get pods --show-labels, then inspect EndpointSlices for the Service. Confirm at least one ready Pod matches the selector before investigating DNS, kube-proxy, or NetworkPolicies.

Pending Pods usually indicate scheduling failure. Check Pod events for FailedScheduling messages, then review node selectors, affinity rules, taints and tolerations, resource requests, and namespace quotas to identify the blocking constraint.

No. Removing or weakening a NetworkPolicy as a diagnostic shortcut risks exposing unrelated traffic, and policy behavior depends on the installed CNI plugin. Instead, map source and destination labels, ports, namespaces, and ingress/egress rules to identify the blocking policy.

Review rollout history with kubectl rollout history and preview the change using rollout undo --dry-run=server. Before any live rollback, confirm the target context and namespace, exact revision, success signal, rollback method, and observation window with explicit approval.

Use read-only Helm commands: helm status, helm history, helm get values --all, and helm get manifest in the target namespace. Capture chart version, effective values, and events before proposing any uninstall, reinstall, or rollback, since those are production mutations.