KubernetesXLV · Kubernetes Networking TroubleshootingNetwork troubleshooting
Systematic network troubleshooting — the methodology
What you'll learn
- Apply the systematic network troubleshooting methodology
- Trace the network path from the application to the cluster
- Identify the failure modes at each layer
- Apply the operational discipline of running network troubleshooting
Prerequisites
Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16
The systematic network troubleshooting methodology starts from the application and moves down the stack: application, Pod, CNI, Service, EndpointSlice, DNS, NetworkPolicy, kube-proxy. This lesson walks the methodology, the diagnostic tools, and the operational discipline.
The systematic methodology
The systematic methodology:
flowchart TD
A[Application] --> B[Pod]
B --> C[CNI]
C --> D[Node network]
D --> E[Cluster network]
E --> F[External network]
A1[Application failure?] -->|Yes| G[Check logs]
B1[Pod has IP?] -->|No| H[Check CNI]
C1[CNI configured?] -->|No| I[Check CNI logs]
D1[Node routes correct?] -->|No| J[Check routes]
E1[Cluster routes correct?] -->|No| K[Check BGP/overlay]
F1[External access OK?] -->|No| L[Check LB/Ingress]
The methodology starts from the application and moves down the stack. The fix is to investigate the first layer that fails.
The seven layers
The seven layers of the network path:
- Application: the application itself.
- Pod: the Pod’s network namespace.
- CNI: the CNI plugin’s configuration.
- Service: the Service’s configuration.
- EndpointSlice: the EndpointSlice’s backends.
- DNS: the cluster’s DNS service.
- NetworkPolicy: the NetworkPolicy’s rules.
- kube-proxy: the kube-proxy’s data plane.
Each layer has a failure mode. The methodology isolates the layer.
The diagnostic tools
The diagnostic tools:
| Layer | Tool | Command |
|---|---|---|
| Application | kubectl logs | kubectl logs <pod> |
| Pod | kubectl exec | kubectl exec <pod> -- ip addr show |
| CNI | kubectl logs | kubectl logs -n kube-system <cni-pod> |
| Service | kubectl describe | kubectl describe svc <svc> |
| EndpointSlice | kubectl get | kubectl get endpointslices |
| DNS | nslookup | kubectl exec <pod> -- nslookup billing |
| NetworkPolicy | kubectl get | kubectl get networkpolicy -A |
| kube-proxy | iptables-save | iptables-save | grep KUBE |
| Network | tcpdump | kubectl exec <pod> -- tcpdump -i eth0 |
The tools are the operator’s primary tools for network troubleshooting.
The layer-by-layer checklist
The layer-by-layer checklist:
flowchart LR
A[Application] --> B{Pod Ready?}
B -->|No| C[Check probes]
B -->|Yes| D{Logs OK?}
D -->|No| E[Check app]
D -->|Yes| F{Pod has IP?}
F -->|No| G[Check CNI]
F -->|Yes| H{NetworkPolicy?}
H -->|Yes| I[Check rules]
H -->|No| J{Service?}
J -->|No| K[Check DNS]
J -->|Yes| L[Check endpoints]
L --> M[Check kube-proxy]
M --> N[Check routes]
The checklist is the operator’s guide. The cluster operator must follow the checklist.
The failure modes
The seven layers’ failure modes:
- Application: the application is buggy, the configuration is wrong, the resource is exhausted.
- Pod: the CNI is not configured, the namespace is wrong, the readiness probe is failing.
- CNI: the CNI plugin is not running, the conflist is wrong, the IPAM is exhausted.
- Service: the selector is wrong, the port is mismatched, the EndpointSlice is empty.
- EndpointSlice: the Pods are not Ready, the labels are wrong, the controller is not running.
- DNS: the CoreDNS is not running, the records are stale, the upstream is unreachable.
- NetworkPolicy: the policy is wrong, the selector is wrong, the CNI does not enforce.
- kube-proxy: the kube-proxy is not running, the dataplane is wrong, the rules are corrupted.
The operational discipline
The network troubleshooting’s operational discipline:
- Document the methodology. The methodology is the cluster’s operational reference.
- Use the diagnostic tools. The tools are the operator’s primary tools.
- Follow the checklist. The checklist is the operator’s guide.
- Document the troubleshooting. The troubleshooting is the cluster’s operational reference.
- Train the operations team on the methodology. The methodology is the team’s tools.
- Plan the methodology’s evolution. The methodology can be updated over time.
Quiz
Knowledge check · 4 questions
Q1. What is the first step in the systematic network troubleshooting methodology?
Q2. The network troubleshooting methodology is systematic, not random.
Q3. An application cannot reach a Service. The Pods are Running. The methodology is applied. What is the diagnostic flow?
The application cannot reach the billing Service. The Pods are Running. The cluster operator must apply the methodology.
Q4. Name two layers in the network troubleshooting methodology and the diagnostic tool for each.
Passing score: 75%. Answers are checked in this browser.
Production discipline
- The methodology is systematic, not random. The cluster operator must follow the methodology.
- Document the methodology. The methodology is the cluster’s operational reference.
- Use the diagnostic tools. The tools are the operator’s primary tools.
- Follow the checklist. The checklist is the operator’s guide.
- Document the troubleshooting. The troubleshooting is the cluster’s operational reference.
- Train the operations team on the methodology. The methodology is the team’s tools.
- Plan the methodology’s evolution. The methodology can be updated over time.
- Set up alerts on the network metrics. The alerts are the leading indicator of outages.