Knowledgebase

Kubernetes networking issues can be genuinely tricky to diagnose given the multiple layers involved (pod networking, service discovery, Ingress). This guide provides a systematic troubleshooting approach.

Step 1 — Verify Pod-to-Pod Connectivity Directly

kubectl exec -it POD_A -- ping POD_B_IP

Establishes whether basic pod networking is functioning at all, before investigating higher-level abstractions (Services, Ingress) that build on top of it.

Step 2 — Check if a Service Resolves Correctly

kubectl exec -it POD_A -- nslookup my-service

Verifies Kubernetes' internal DNS (CoreDNS) is correctly resolving service names — a common failure point distinct from actual network connectivity.

Step 3 — Verify Service Endpoints Are Populated

kubectl get endpoints my-service

A Service with no endpoints means no pods currently match its selector — often caused by a label mismatch between the Service's selector and the actual pod labels; empty endpoints explain why traffic to the service fails despite the service itself existing.

Step 4 — Check for Network Policy Blocking

See How to Set Up Network Policies in Kubernetes for Pod-to-Pod Security — if Network Policies are in use, verify they're not inadvertently blocking legitimate traffic; temporarily removing a policy (in a test context) can help isolate whether it's the actual cause.

Step 5 — Check CoreDNS Health

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

If DNS resolution is failing cluster-wide (not just for one service), check the health of CoreDNS itself — a broader, cluster-level issue rather than something specific to your application.

Step 6 — Verify Ingress Configuration and Controller Health

kubectl get ingress
kubectl describe ingress my-ingress
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller

For external access issues specifically, verify both your Ingress resource definition and the health/logs of the Ingress controller itself (see How to Expose Applications with a Kubernetes Ingress Controller (Nginx Ingress)).

Step 7 — Check for CNI Plugin Issues

kubectl get pods -n kube-system | grep -E 'calico|flannel|cilium'

Verify your cluster's CNI (network plugin) pods are healthy — a genuinely broken CNI causes widespread networking dysfunction across the entire cluster, a more fundamental issue than application-specific misconfiguration.

Step 8 — Use a Debug Pod for Network Testing

kubectl run netdebug --image=nicolaka/netshoot -it --rm -- /bin/bash

A dedicated network debugging image with common diagnostic tools (curl, dig, tcpdump) pre-installed, useful when your application's own container image lacks these tools for direct investigation.

Step 9 — Check for MTU-Related Issues

See How to Troubleshoot MTU Issues and Fragmentation Problems — particularly relevant for overlay network CNI plugins that add encapsulation overhead; symptoms (connections that hang on larger data transfers) are similar to the general MTU troubleshooting pattern covered there.

Step 10 — Check Firewall Rules on the Underlying VPS/Nodes

Verify your VPS-level firewall (see How to Configure firewalld on AlmaLinux/Rocky Linux or ufw equivalents) isn't inadvertently blocking traffic between nodes that Kubernetes networking depends on — particularly relevant for multi-node clusters where inter-node communication is essential.

Common Errors

Everything appears correctly configured but connectivity still fails intermittently — check node resource pressure (see Kubernetes Resource Requests and Limits Explained); severe resource contention can manifest as apparent networking flakiness rather than an obvious resource error.

Continue Reading

• How to Set Up Network Policies in Kubernetes for Pod-to-Pod Security
• How to Expose Applications with a Kubernetes Ingress Controller (Nginx Ingress)
• How to Debug a Crashing Pod in Kubernetes

Browse more articles in Kubernetes & Container Orchestration.