Hands-on Lab·Certified Kubernetes Administrator
Service Session Affinity
What a ClusterIP does with repeated requests, what changes when you pin them, what happens when the pinned backend disappears, and the source-IP assumption that makes the whole feature fragile.
Services and Networking Guide 50 of 103 Intermediate
- Kubernetes1.36.4
- Cluster4 nodes
- Runtimecontainerd 2.2.6
- CNICalico v3.32.1
- TimeAbout 14 min
The three-hour default timeout is sessionAffinityConfig.clientIP.timeoutSeconds, read here from the live Service.
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA1001 | 192.168.0.175 | Ubuntu 26.04 LTS | Control Plane Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE01 | 192.168.0.176 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE02 | 192.168.0.177 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA1001-NODE03 | 192.168.0.178 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when repeated requests from one client have to land on the same backend. This matters because a ClusterIP chooses per connection by default, and the affinity that fixes that is keyed on source IP - so it fails the moment anything rewrites the address.
- watching a default ClusterIP spread repeated requests across three backends
- patching
sessionAffinity: ClientIPand pinning the client to one of them - deleting the backend the client was pinned to, and seeing what the mapping does next
- understanding the limit - the mapping is keyed on the client's source IP and nothing else
Before you start
- guide 47 - what is doing the balancing.
- guide 52 - the other setting that changes which source address the cluster sees.
-
Three backends, and how a ClusterIP spreads across them
-
Pin the client to one backend
-
What happens when the backend goes away
-
The limit worth knowing