Most Kubernetes outages are not mysterious.
They are just scattered.
The Service exists, but the selector misses the Pods. The EndpointSlice is empty. DNS works in one namespace and not another. The Pods are restarting. The ingress points to the wrong Service port. The readiness probe is failing. The cloud load balancer is healthy while the app is not. Everyone opens three terminals and starts rebuilding the same context.
That is why Kubernetes service debugging is a strong fit for AI-assisted operations, as long as the agent reads real cluster state and stops before making changes.
The Official Debug Order Is Still The Right Order
Kubernetes documentation for debugging Services walks through a practical sequence:
- Does the Service exist?
- Are NetworkPolicy rules affecting target Pods?
- Does DNS work?
- Does the Service IP work?
- Is the Service defined correctly?
- Does the Service have EndpointSlices?
- Are the Pods working?
- Is kube-proxy working?
That order matters because it prevents guesswork.
Clanker Cloud should not replace that mental model. It should make the model faster to run across EKS, GKE, AKS, and any kubeconfig context.
The Local Runbook
1. Confirm The User-Facing Symptom
Write down the exact failure:
- 502 from ingress.
- Timeout from another service.
- DNS resolution failure.
- Connection refused.
- Intermittent failures.
- Only one region or cluster affected.
- Only one namespace affected.
The symptom tells you where to start. A 502 and an NXDOMAIN are different problems.
2. Inspect Service, Selector, And EndpointSlices
The boring bug is common:
Service selector: app=api
Pod labels: app=api-v2
EndpointSlice: <none>
If the Service has no endpoints, the load balancer and ingress can be perfectly healthy while traffic still has nowhere useful to go.
Ask Clanker Cloud:
Why is this Kubernetes Service not routing traffic? Check selectors, EndpointSlices, Pods, readiness, ingress, and recent rollouts.
The answer should include the commands or API objects used, not just the conclusion.
3. Check Pod Health And Restarts
A Service with endpoints can still fail if the Pods are unhealthy.
Look for:
CrashLoopBackOff.- High restart count.
- Readiness failures.
- OOMKilled.
- Failed mounts.
- Image pull errors.
- ConfigMap or Secret changes.
- Liveness probe loops.
Kubernetes supports kubectl debug patterns for copying or inspecting Pods when containers are crashing. In GKE, Google also documents CrashLoopBackOff troubleshooting paths around app misconfigurations, resource exhaustion, and probe failures.
AI helps when it correlates those signals in order. AI hurts when it invents the root cause from a single log line.
4. Bring In Cloud Provider Context
EKS, GKE, and AKS add provider-specific layers:
- Cloud load balancers.
- Security groups or firewall rules.
- Network policies.
- Identity and service accounts.
- Node health.
- Managed ingress controllers.
- Logging pipelines.
This is where the context layer matters. A developer debugging a 502 should not need to know every cloud console path by memory. They need a local workspace that can collect the cluster objects, provider context, and recent changes.
5. Produce A Reviewable Fix
Good output:
Finding: Service api-prod selects app=api, but the rollout changed Pods to app=api-v2.
Evidence: Service selector, Pod labels, empty EndpointSlice, rollout timestamp.
Fix: update Service selector or restore labels in Deployment.
Risk: selector change affects all traffic for api-prod.
Rollback: restore previous selector.
Review: application owner approval required.
Bad output:
Run kubectl apply.
Production Kubernetes changes need a review boundary, especially when an AI agent produced the plan.
Startup Version
For small teams:
- Keep namespaces simple.
- Use consistent labels.
- Add readiness probes before traffic matters.
- Keep one ingress path per service until there is a reason not to.
- Save known-good commands in runbooks.
- Use Clanker Cloud to ask the cluster question and get the evidence in one place.
The win is speed without losing control.
Enterprise Version
For platform teams:
- Standardize labels.
- Enforce service ownership.
- Track rollout history.
- Include EndpointSlice and NetworkPolicy checks in incident automation.
- Keep AI-generated remediations in review mode.
- Attach evidence to incidents and PRs.
The win is consistency across clusters, providers, and teams.
The Takeaway
Kubernetes service debugging is not about memorizing more commands. It is about following a reliable path through DNS, Service definitions, EndpointSlices, Pod health, kube-proxy, ingress, and cloud provider context.
Clanker Cloud should make that path available to humans and agents from a local workspace, while keeping the fix reviewed before apply.
Sources
Ask Clanker Cloud what your cluster is doing
Install the local app, connect your kubeconfig, and turn cluster state, workload health, cost context, and safe next steps into one readable answer.