Debugging service connectivity in Kubernetes - Commands & Configuration

Introduction

Sometimes your app cannot talk to another app inside Kubernetes. Debugging service connectivity helps find why the connection fails and fix it quickly.

When your frontend app cannot reach the backend service inside the cluster.

When a pod cannot connect to a database service running in Kubernetes.

When you want to check if a service is exposing the right ports and endpoints.

When network policies might be blocking traffic between pods.

When you want to verify DNS resolution of service names inside the cluster.

Commands

Check which pods are running to confirm your app and service pods are up.

Terminal

kubectl get pods

Expected Output

NAME                        READY   STATUS    RESTARTS   AGE

frontend-5d8f7c9d7f-abc12  1/1     Running   0          10m

backend-6f7d8c9d7f-def34   1/1     Running   0          10m

List services to verify the backend service is created and exposing the correct ports.

Terminal

kubectl get svc

Expected Output

NAME       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE

backend    ClusterIP   10.96.123.45    <none>        8080/TCP   10m

kubernetes ClusterIP   10.96.0.1       <none>        443/TCP    1d

From the frontend pod, try to connect to the backend service using curl to test connectivity.

Terminal

kubectl exec frontend-5d8f7c9d7f-abc12 -- curl -sS backend:8080

Expected Output

Hello from backend!

→

-- - Separates kubectl exec options from the command to run inside the pod

Show detailed info about the backend service to check endpoints and ports.

Terminal

kubectl describe svc backend

Expected Output

Name:              backend

Namespace:         default

Labels:            <none>

Annotations:       <none>

Selector:          app=backend

Type:              ClusterIP

IP:                10.96.123.45

Port:              8080/TCP

Endpoints:         10.244.1.5:8080

Session Affinity:  None

Events:            <none>

Check the IP addresses of pods behind the backend service to ensure they are ready.

Terminal

kubectl get endpoints backend

Expected Output

NAME      ENDPOINTS         AGE

backend   10.244.1.5:8080   10m

Key Concept

If you remember nothing else from this pattern, remember: test connectivity from inside the pod using service names and verify service endpoints.

Common Mistakes

Trying to curl the service from outside the cluster without port forwarding or ingress.

Services of type ClusterIP are only reachable inside the cluster, so external curl will fail.

Use kubectl exec to run curl inside a pod or use port forwarding to access the service externally.

Assuming the service IP is the pod IP and trying to connect directly to pod IPs.

Pods can change IPs and are not stable endpoints; services provide stable access.

Always use the service name or ClusterIP to connect to pods.

Not checking if the backend pods are ready before testing connectivity.

If pods are not ready or crashed, the service will have no endpoints and connections fail.

Use kubectl get pods and kubectl describe pods to confirm pod readiness.

Summary

Check pods and services to confirm your apps are running and exposed.

Use kubectl exec with curl inside a pod to test service connectivity by name and port.

Describe the service and check endpoints to verify backend pods are correctly linked.

Practice

1. What is the primary command to check if a Kubernetes service has endpoints assigned?

easy

A. kubectl describe nodes

B. kubectl get pods

C. kubectl get endpoints

D. kubectl get configmaps

Solution

1. Step 1: Understand service connectivity basics

   Services route traffic to endpoints, so checking endpoints shows if pods are linked.

2. Step 2: Use the correct command to list endpoints

   kubectl get endpoints lists endpoints for services, showing if pods are ready.

3. Final Answer:

   kubectl get endpoints -> Option C

4. Quick Check:

   Check endpoints = kubectl get endpoints [OK]

Hint: Use 'kubectl get endpoints' to verify service pod connections [OK]

Common Mistakes:

• Using 'kubectl get pods' which shows pods but not service endpoints
• Checking nodes or configmaps which are unrelated to service endpoints
• Confusing 'kubectl describe svc' with listing endpoints

2. Which of the following commands correctly tests DNS resolution inside a Kubernetes pod named web-123?

easy

A. kubectl exec web-123 -- nslookup myservice

B. kubectl exec web-123 nslookup myservice

C. kubectl exec -it web-123 nslookup myservice

D. kubectl exec web-123 -- curl myservice

Solution

1. Step 1: Understand kubectl exec syntax

   The correct syntax to run a command inside a pod is kubectl exec [pod] -- [command].

2. Step 2: Identify the command to test DNS

   nslookup tests DNS resolution, so kubectl exec web-123 -- nslookup myservice is correct.

3. Final Answer:

   kubectl exec web-123 -- nslookup myservice -> Option A

4. Quick Check:

   Correct exec syntax + nslookup = kubectl exec web-123 -- nslookup myservice [OK]

Hint: Use '--' before command in kubectl exec to run inside pod [OK]

Common Mistakes:

• Omitting '--' which causes command to fail
• Using '-it' without need for interactive shell
• Using curl instead of nslookup for DNS test

3. You run kubectl describe svc myservice and see no endpoints listed. What will be the output of kubectl get endpoints myservice?

medium

A. Error from server (NotFound): endpoints "myservice" not found

B. NAME ENDPOINTS AGE
myservice 10.0.0.5:80,10.0.0.6:80 10m

C. NAME ENDPOINTS AGE
myservice 127.0.0.1:80 10m

D. NAME ENDPOINTS AGE
myservice <none> 10m

Solution

1. Step 1: Interpret service describe output

   No endpoints means no pods are linked to the service, so endpoints list is empty.

2. Step 2: Predict endpoints output

   kubectl get endpoints myservice will show the service name with <none> under ENDPOINTS.

3. Final Answer:

   NAME ENDPOINTS AGE myservice <none> 10m -> Option D

4. Quick Check:

   No endpoints = <none> shown [OK]

Hint: No endpoints in describe means endpoints show <none> [OK]

Common Mistakes:

• Assuming endpoints will list IPs even if none exist
• Expecting an error when endpoints exist but are empty
• Confusing endpoints with pod IPs

4. A pod cannot reach a service by its DNS name. You run kubectl exec pod1 -- nslookup myservice and get a timeout. What is the most likely cause?

medium

A. The pod is missing the DNS policy or DNS is misconfigured

B. The service has no endpoints, so DNS resolves but no response

C. The service selector labels do not match any pods

D. The pod is running in a different namespace without DNS search path

Solution

1. Step 1: Analyze DNS timeout symptom

   A DNS timeout means the pod cannot resolve the service name, indicating DNS issues.

2. Step 2: Identify DNS misconfiguration causes

   Missing DNS policy or broken DNS config in pod causes nslookup timeout, unlike no endpoints which still resolve DNS.

3. Final Answer:

   The pod is missing the DNS policy or DNS is misconfigured -> Option A

4. Quick Check:

   DNS timeout = DNS config issue [OK]

Hint: DNS timeout means DNS config or policy problem, not endpoints [OK]

Common Mistakes:

• Confusing DNS resolution failure with no endpoints
• Assuming label mismatch causes DNS timeout instead of no response
• Ignoring namespace DNS search path issues

5. You have a service myservice in namespace prod. A pod in namespace dev tries to connect using curl myservice but fails. Which is the best way to debug this connectivity issue?

hard

A. Run kubectl describe pod -n prod myservice to check pod details

B. Run kubectl exec -n dev pod -- curl myservice.prod.svc.cluster.local to test full DNS name

C. Run kubectl get svc -n dev myservice to check service in dev namespace

D. Run kubectl exec -n prod pod -- curl myservice to test from the service namespace

Solution

1. Step 1: Understand cross-namespace service access

   Pods in different namespaces must use the full DNS name including namespace to reach a service.

2. Step 2: Test connectivity using full DNS name from the pod in dev namespace

   Running kubectl exec -n dev pod -- curl myservice.prod.svc.cluster.local tests correct DNS and connectivity.

3. Final Answer:

   Run kubectl exec -n dev pod -- curl myservice.prod.svc.cluster.local to test full DNS name -> Option B

4. Quick Check:

   Cross-namespace access needs full DNS name [OK]

Hint: Use full DNS name with namespace for cross-namespace service access [OK]

Common Mistakes:

• Trying to curl service without namespace from another namespace
• Checking service in wrong namespace
• Describing pod instead of testing connectivity