In the context of the CKA exam and Kubernetes Networking, configuring how Services handle incoming traffic is vital for performance, observability, and application logic. Two primary mechanisms control this behavior: External Traffic Policy and Session Affinity.
**External Traffic Policy (`externa…In the context of the CKA exam and Kubernetes Networking, configuring how Services handle incoming traffic is vital for performance, observability, and application logic. Two primary mechanisms control this behavior: External Traffic Policy and Session Affinity.
**External Traffic Policy (`externalTrafficPolicy`)** defines how traffic arriving at a NodePort or LoadBalancer is routed to the actual Pods.
1. **`Cluster` (Default):** Traffic arriving at any node is forwarded to any ready Pod matching the service selector, regardless of which node the Pod is actually running on. This often involves Source Network Address Translation (SNAT), meaning the Pod sees the Node's IP rather than the client's real IP. It creates an extra network hop (latency) but ensures even load balancing across the cluster.
2. **`Local`:** Traffic is only forwarded to Pods running on the specific node that received the request. If the receiving node has no relevant Pods, the traffic is dropped. This setting preserves the client's original Source IP and reduces latency by eliminating the cross-node hop. However, it can result in uneven load distribution if Pods are not spread evenly across nodes.
**Session Affinity (`sessionAffinity`)** controls how consecutive requests from a single client are distributed among available Pods.
1. **`None` (Default):** Requests are distributed using a standard round-robin or random algorithm. There is no guarantee a client will hit the same Pod twice. This is ideal for stateless applications.
2. **`ClientIP`:** This enables "sticky sessions." The Service uses the client's IP address to ensure that all requests from that specific IP are routed to the same Pod for a configurable duration. This is critical for stateful applications where the server stores session data locally and requires continuity.
Mastering External Traffic Policy and Session Affinity in Kubernetes Services
Why is this Important? In a production Kubernetes environment, controlling how network traffic reaches your Pods is critical for performance, security, and application stability. Specifically, you may need to preserve the client's original source IP address for security auditing or allow lists, or you may need to ensure that a specific user connects to the same Pod repeatedly to maintain application state (sticky sessions). The CKA exam tests your ability to manipulate these traffic behaviors using Service specifications.
1. External Traffic Policy (externalTrafficPolicy) This field in the Service spec controls how traffic from external sources (outside the cluster) is routed to the Pods. It is relevant primarily for Services of type NodePort and LoadBalancer.
Modes: Cluster (Default): When traffic hits a Node, kube-proxy distributes it to any Pod in the cluster matching the service selector, regardless of which Node the Pod is on. Pros: Balanced traffic distribution. Cons: Causes extra network hops (Node-to-Node) and obscures the Source IP (SNAT is applied, so the Pod sees the Node's IP, not the client's).
Local: Traffic is only routed to a Pod if it exists on the local Node that received the traffic. If the Node has no local Pod, the connection is dropped (or the Load Balancer health check fails for that Node). Pros: No extra network hops (lower latency) and preserves the Client Source IP. Cons: Potential for uneven traffic distribution if Pods are not evenly spread across Nodes.
2. Session Affinity (sessionAffinity) By default, Kubernetes Services use standard round-robin load balancing. However, stateful applications often require that a client's requests stick to the same specific Pod for a duration.
Modes: None (Default): Requests are distributed using round-robin; no stickiness. ClientIP: Kubernetes uses the client's IP address to direct traffic to the same Pod. This is often referred to as 'Sticky Sessions'. You can further configure the duration using sessionAffinityConfig (default is 10800 seconds / 3 hours).
How to Answer Questions in the Exam When faced with networking questions, look for specific requirements regarding IP visibility and state.
Scenario A: "The application needs to see the real IP address of the client." Answer: Edit the Service and set externalTrafficPolicy: Local.
Scenario B: "Users are getting logged out when refreshing the page because they hit a different backend Pod." Answer: Edit the Service and set sessionAffinity: ClientIP.
Exam Tips: Answering Questions on External traffic policy and session affinity 1. Identify the Service Type:externalTrafficPolicy is only effective for NodePort or LoadBalancer types. It does not apply to ClusterIP. 2. Check the Defaults: If a question asks why a Pod sees a Node IP instead of a Client IP, the answer is likely because the default policy is Cluster. 3. YAML Location: Both configurations belong under the spec section of the Service object. 4. Troubleshooting: If you set externalTrafficPolicy: Local and traffic fails, check if the Node actually has a Pod running on it. If the Node has no Pods, it cannot route the traffic.