CKA Services & Networking Practice Question
A Kubernetes cluster uses kube-proxy in IPVS mode. A Service named 'api-svc' of type ClusterIP has three endpoints: 10.244.1.5:8080, 10.244.2.6:8080, and 10.244.3.7:8080. A client pod repeatedly connects to 'api-svc' and observes that all connections are routed to the same endpoint, 10.244.1.5:8080. The client pod and the endpoints are on different nodes. What is the most likely cause?
⚠ Common exam trap
It's easy for candidates to confuse connection-level load balancing with per-request load balancing; IPVS source hashing can pin a client to one endpoint even without session affinity.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The IPVS scheduler is set to 'sh' (source hashing), which consistently maps the same client IP to the same endpoint.
In IPVS mode, kube-proxy can use different schedulers. The default is round-robin, but if configured to source hashing ('sh'), IPVS selects the real server based on a hash of the source IP. This causes all connections from the same client IP to consistently go to the same endpoint. Since the client pod always reaches the same endpoint across multiple connections, the most likely cause is that the IPVS scheduler is set to 'sh'.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The IPVS scheduler is set to 'rr' (round-robin), but session affinity is enabled on the Service.
Why it's wrong here
If session affinity were enabled on the Service, the client's connections would indeed stick to one endpoint, but session affinity is a Service-level setting (sessionAffinity: ClientIP) that works with any kube-proxy mode. The question states kube-proxy is in IPVS mode, and the symptom is consistent with session affinity, but the option says the scheduler is 'rr' and session affinity is enabled. That combination would cause the observed behavior, but it is not the most likely cause because session affinity must be explicitly configured, whereas the default IPVS scheduler behavior can cause this without session affinity.
- ✓
The IPVS scheduler is set to 'sh' (source hashing), which consistently maps the same client IP to the same endpoint.
Why this is correct
In IPVS mode, the default scheduler is 'rr' (round-robin), but if the scheduler is changed to 'sh' (source hashing), IPVS uses a hash of the source IP to select a real server. This ensures that all connections from the same client IP go to the same endpoint, explaining why the client pod always reaches 10.244.1.5. This is the most likely cause given the consistent routing without session affinity.
- ✗
The Service has 'externalTrafficPolicy: Local' set, causing traffic to be routed only to endpoints on the same node as the client.
Why it's wrong here
externalTrafficPolicy: Local is relevant for NodePort and LoadBalancer Services, not for ClusterIP Services. It controls whether traffic received on a node is routed only to local endpoints, but it does not apply to internal ClusterIP traffic. Moreover, the client pod and endpoints are on different nodes, so if it were Local, the client might not reach any endpoint. This setting is not the cause here.
- ✗
The client pod is using a persistent HTTP connection, and the Service's load balancing only applies to new TCP connections.
Why it's wrong here
While it is true that kube-proxy load balancing occurs at the connection level, meaning a persistent HTTP connection will stick to one endpoint, the scenario says the client 'repeatedly connects' and observes all connections going to the same endpoint. If it were merely a persistent connection, new connections would be load-balanced. The consistent routing across multiple connections points to a scheduler or affinity issue, not just connection reuse.
Go deeper
Related to this question
Learn chapter
Kubernetes Architecture Overview
Key term
Ingress Resources
Ingress Resources are Kubernetes API objects that manage external access to services inside a cluster, typically HTTP and HTTPS traffic, by defining rules for routing requests based on hostnames and paths.
Key term
ClusterIP NodePort LoadBalancer
ClusterIP, NodePort, and LoadBalancer are three types of Kubernetes Services that control how traffic reaches your application pods inside the cluster or from outside.
About these practice questions
One of 726 original CKA practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CNCF exam blueprint
This CKA practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKA exam.