How do you make a Kubernetes Service send repeated requests from the same client to the same backing pod, and what are the limitations of that mechanism?

## The mechanism ```yaml spec: sessionAffinity: ClientIP sessionAffinityConfig: clientIP: timeoutSeconds: 10800 ``` With `sessionAffinity: None` (the default) each new connection to the Service's virtual IP is load-balanced independently. With `ClientIP`, the per-node dataplane records that source IP X was sent to pod P, and sends subsequent connections from X to P until the mapping idles out after `timeoutSeconds` (default 10800 seconds = 3 hours; the maximum is 86400). That is the entire feature: there is no other affinity mode on a Service. ## Why it usually disappoints **It hashes the address it sees, not the user.** Several layers can make that address meaningless: - *Source NAT on external traffic.* With the default `externalTrafficPolicy: Cluster`, packets that a node forwards to a pod on another node are source-NATed to the node's IP. Every client behind that node hashes to the same value, so affinity degenerates: one pod receives everything routed through that node. Setting `externalTrafficPolicy: Local` preserves the client IP and makes affinity meaningful again - at the cost of the load-distribution tradeoffs that policy brings. - *Fronting proxies.* If an ingress or gateway terminates connections and then calls the Service, the Service sees the *proxy's* pod IP. Every user shares one source, so all traffic pins to one backend. In that topology, affinity has to be configured on the proxy (typically cookie-based), not on the Service. - *Client-side NAT.* Mobile carriers, corporate egress and CDNs put thousands of users behind one address; affinity then hands them all to a single pod, creating a hotspot. **It is per-node, in-memory state.** Two nodes handling traffic for the same Service maintain independent mappings, so which pod you get depends on where you entered. Restart the dataplane, reschedule the pod, or scale the Deployment, and the mapping is discarded - the client silently lands somewhere else. That is fatal if your application stored the session only in the pod's memory. **It does nothing for multiplexed protocols.** With HTTP/2 or gRPC, one connection already carries all requests to one pod; affinity adds nothing. And for a single long-lived WebSocket connection there is nothing to re-balance in the first place. ## What it is legitimately good for Affinity is a **performance** hint, not a correctness guarantee. Real uses: - Warm per-pod caches: repeat requests from the same client hit a pod that already has their data loaded. - Expensive per-client setup (a connection pool, a compiled model) that you would rather not repeat per pod. - Reducing cross-pod chatter for workloads that shard state by client. In every case the system must remain correct when the mapping breaks, because it will. ## The right answers for real session state If you actually need a user's session to survive, choose one of these instead: 1. **Externalise the session** into Redis, a database, or a signed cookie/token. Then any pod can serve any request and affinity becomes irrelevant. This is the default correct answer in an interview. 2. **L7 cookie affinity at the ingress or mesh layer**, where the proxy sets its own cookie identifying the chosen backend. It survives NAT because it identifies the *session* rather than the network path, and typically has better draining behaviour on scale-down. It is still a performance tool, not a durability guarantee. 3. **Stable identity via a StatefulSet plus a headless Service**, where the client addresses a specific pod by name. That is sharding, not affinity, and it is the right shape when a particular pod genuinely owns particular state. ## Interview framing The strong answer names `sessionAffinity: ClientIP` and its timeout, immediately qualifies it as L4 IP hashing with per-node non-durable state, points out that SNAT and fronting proxies commonly render it useless, and finishes by saying that sticky sessions are a cache optimisation while session correctness belongs in shared storage.