A legacy municipal UI keeps server-side session state in memory on one Pod. Which Service setting improves sticky routing by client IP?
Select an answer to reveal the explanation.
Short Explanation
Sticky sessions are like always sending a citizen back to the same clerk window. sessionAffinity: ClientIP tells the Service to prefer the same backend for that client IP. It’s a band-aid for sticky legacy UIs—not a reason to skip proper shared session stores forever.
Full Explanation
A legacy municipal UI that keeps server-side session state in memory on one Pod benefits from Service sessionAffinity: ClientIP, which improves sticky routing by client IP so a citizen tends to return to the same backend Pod. Sticky sessions are like always sending a citizen back to the same clerk window. ClientIP affinity instructs the Service proxying behavior to prefer the same endpoint for that client IP within the affinity timeout, reducing broken sessions for sticky legacy apps that were never designed for random load balancing.
publishNotReadyAddresses: true publishes NotReady Pods into Endpoints and does not implement sticky sessions. Switching the Service type to ExternalName changes DNS aliasing to an external hostname; it does not provide kube-proxy session affinity across Pod backends. Deleting Endpoints periodically so kube-proxy supposedly pins the next client is destructive and is not a stickiness mechanism.
Exam caveat: ClientIP affinity is best-effort and can behave poorly behind NATs where many users share one IP; the durable fix is an external session store—but the Service-level knob CKAD expects is sessionAffinity: ClientIP. Operational check: set sessionAffinity: ClientIP on the Service, observe more stable endpoint selection for a repeated test client, and kubectl describe svc to confirm Session Affinity: ClientIP. Document the legacy constraint and migration plan in the city UI’s architecture notes.