🏠 Home Page

CKA Service Troubleshooting Practice

Goal: Learn to diagnose Service issues quickly by following the same workflow every time. 

kubectl get svc
kubectl get endpoints
kubectl describe svc 
kubectl get pods --show-labels
kubectl describe pod
Remember: Deployment → Creates Pods Service → Finds Pods using a selector Endpoints → Healthy Pods attached to the Service Traffic → Flows through the Service to Endpoints

Scenario 1: Wrong Selector

Symptoms

kubectl get endpoints

NAME
webapp-svc

ENDPOINTS

Investigation

kubectl describe svc webapp-svc

Selector: app=banana

kubectl get pods --show-labels

webapp-pod
app=webapp
Question: Why are there no endpoints?
Answer: The Service selector does not match the Pod labels. Service wants: app=banana Pod has: app=webapp

Scenario 2: Wrong Target Port

Goal

Practice troubleshooting a Service that exists, has endpoints, but forwards traffic to the wrong container port.

Create the Scenario

# Create an nginx pod
kubectl run nginx --image=nginx --port=80

# Create a Service with the WRONG target port
kubectl expose pod nginx \
  --name=nginx-svc \
  --port=80 \
  --target-port=9999

# Create a temporary test pod
kubectl run test \
  --image=busybox:1.35 \
  --restart=Never \
  -- sleep 3600

Verify the Problem

kubectl exec test -- wget -qO- nginx-svc

Connection refused
OR
Request times out
OR
No output is returned

The test pod acts as a client inside the cluster. It attempts to access the Service using Kubernetes DNS.

Investigation

kubectl get svc nginx-svc

kubectl describe svc nginx-svc

kubectl get endpoints nginx-svc

Notice the Service is forwarding traffic to port 9999.

Port:       80/TCP
TargetPort: 9999/TCP

kubectl get endpoints nginx-svc

nginx-svc   10.244.0.5:9999

Question

Question: Endpoints exist. Why doesn't traffic work?

Answer

Answer: The Service selector is correct and endpoints exist, but the Service forwards traffic to the wrong port. Requests arrive at the pod on port 9999, while the nginx container only listens on port 80. As a result, the Service cannot reach the application even though the endpoint is present.

Fix

kubectl edit svc nginx-svc

Change:

targetPort: 9999

To:

targetPort: 80

Verify the Fix

kubectl get endpoints nginx-svc

nginx-svc   10.244.0.5:80

kubectl exec test -- wget -qO- nginx-svc

The nginx welcome page should now be returned.

CKA Troubleshooting Pattern

kubectl get svc
kubectl describe svc
kubectl get endpoints
kubectl get pods --show-labels
kubectl describe pod
kubectl exec test -- wget -qO-

Scenario 4: CrashLoopBackOff

Objective

Learn how to troubleshoot a Service that has no endpoints because the backing Pod is repeatedly crashing and never becomes Ready.

Break It

Create a Deployment:

kubectl create deployment web --image=busybox

Edit the Deployment:

kubectl edit deployment web

Modify the container definition so it immediately exits:

containers:
- image: busybox
  name: busybox
  command:
  - /bin/sh
  - -c
  - exit 1

Create a Service:

kubectl expose deployment web \
  --port=80 \
  --target-port=80

Symptoms

Check the Service endpoints:

kubectl get endpoints web

Expected output:

NAME   ENDPOINTS   AGE
web    <none>      ...

Check the Pods:

kubectl get pods

Expected output:

NAME                     READY   STATUS             RESTARTS
web-xxxxxxxxxx-xxxxx     0/1     CrashLoopBackOff   ...

Investigation

View the container logs:

kubectl logs <pod-name>

Example output:

container exited with code 1

Inspect Pod events:

kubectl describe pod <pod-name>

Look for messages similar to:

Back-off restarting failed container

Troubleshooting Question

Question: Why are there no endpoints?
Answer: The Service selector is correct and the Pod exists. However, the application inside the container immediately crashes. Kubernetes keeps restarting the container, causing a CrashLoopBackOff state. Because the Pod never becomes Ready, Kubernetes does not add it to the Service endpoint list. As a result, the Service shows: <none>.

Exam Tip

Service
   ↓
Selector matches Pod
   ↓
Pod exists
   ↓
Pod Ready?
   ↓
NO
   ↓
No Endpoints

Remember: Services only send traffic to Ready Pods. A Pod in CrashLoopBackOff never becomes healthy enough to join the endpoint list.

ImagePullBackOff vs CrashLoopBackOff

Status Container Started? Most Likely Cause
ImagePullBackOff No Image cannot be downloaded.
CrashLoopBackOff Yes Application starts and then crashes.

CKA Troubleshooting Checklist

  1. Verify the Service selector.
  2. Verify Pod labels.
  3. Check Pod status.
  4. Check endpoint list.
  5. Inspect logs.
  6. Inspect Pod events with kubectl describe pod.
  7. Confirm the Pod reaches Ready status.

Scenario 5: Bad Deployment Update

Lab Setup

kubectl create deployment web --image=nginx

kubectl expose deployment web --port=80

kubectl set image deployment/web \
nginx=nginx:doesnotexist

Symptoms

kubectl get pods

web-oldpod    Running
web-newpod    ImagePullBackOff

kubectl get endpoints web

192.168.x.x:80
Question: Why do endpoints still exist?
Answer: A healthy old Pod is still running. The Service continues sending traffic to the healthy Pod while the new Pod fails.

Fast Exam Checklist

1. kubectl get svc

2. kubectl get endpoints

3. kubectl describe svc 

4. kubectl get pods --show-labels

5. kubectl describe pod 

6. kubectl logs

Mental Flow Chart

Service
   ↓
Selector
   ↓
Ready Pods
   ↓
Endpoints
   ↓
Traffic

Endpoints: 
     ↓
Check Selector

Selector Correct?
     ↓
Check Pod Health

ImagePullBackOff?
CrashLoopBackOff?
Pending?
NotReady?

Endpoints Exist
     ↓
Check TargetPort

TargetPort Correct?
     ↓
Check Application