Course contentsShow
← Docker, Kubernetes & CI/CD
Lesson 292 of 8024. Kubernetes Architecture and Core ObjectsFree lesson

Troubleshooting Service Connectivity and Network Policies

Learners will diagnose common networking failures by inspecting Service definitions, DNS resolution, and the status of backend Pod endpoints.

In this lesson, you will learn how to diagnose and resolve common connectivity issues by verifying the relationship between Services, Pods, and the cluster DNS.

When you cannot reach your application, the failure usually stems from one of three areas: a mismatch in label selectors, missing endpoints, or DNS resolution errors. Because Pod IPs are ephemeral, we rely on the Service to act as a stable bridge. If that bridge breaks, traffic hits a dead end.

Step 1: Verify Endpoint Availability

The most common mistake is a mismatch between your Service label selector and your Pod labels. If the Service cannot find any Pods, it cannot route traffic. Use this command to see if your Service has found any backends:

kubectl get endpoints <service-name>

If the subsets section is empty, your Service’s selector field does not match the labels assigned to your Pods. Even if the Pod is running, the Service ignores it if the labels don't align perfectly.

Step 2: Check DNS Resolution

If your endpoints are correctly populated, the issue might be DNS. Your cluster uses a core service (typically CoreDNS) to resolve your Service names to a ClusterIP. You can test this from a debug pod:

kubectl run busybox --rm -it --image=busybox -- nslookup <service-name>

If nslookup fails to return an IP, the service name is unreachable within your namespace, or there is a configuration error with the cluster DNS.

Step 3: Inspecting Network Policies

Finally, remember that NetworkPolicies act as a firewall. Even if your Service, Endpoints, and DNS are perfectly configured, a NetworkPolicy might be explicitly blocking traffic from other namespaces or specific Pod labels. If you have connectivity issues despite the Service being healthy, check if a policy is configured to "Deny All" or if it lacks an "Allow" rule for your specific source Pods.

By verifying that your Service has endpoints, your DNS resolves, and your traffic isn't being dropped by a policy, you can systematically pinpoint where the "missing link" in your network path exists.

Key Takeaway: Troubleshooting connectivity starts by verifying that the Service's label selector matches Pod labels, ensuring Endpoints exist, and checking that no NetworkPolicies are silently dropping the traffic.