Service資源還支援Session affinity（粘性會話活會話粘性）機制，它能夠將來自同一個客戶端的請求始終轉發至同一個後端的Pod物件，這意味著它會影響排程演算法的流量分發功能，進而降低其負載均衡的效果。因此，當客戶端訪問Pod中的應用程式時，如果有基於客戶端身份儲存某些私有資訊，並基於這些私有資訊追蹤使用者的活動等一類的需求時，那麼應該啟用session affinity機制。

Session affinity的效果僅會在一定時間期限內生效，預設值為10800秒，超出此時長之後，客戶端的再次訪問會被排程演算法重新排程。另外，Service資源的Session affinity僅能基於客戶端IP地址識別客戶端身份，它會把經由同一NAT伺服器進行源地址轉換的所有客戶端識別為同一個客戶端，排程顆粒度粗糙且效果不佳，因此，實踐中並不推薦使用此種方法實現粘性會話。此節僅用於讀者介紹其功能及實現。

Service資源通過.spec.sessionAffinity和.spec.sessionAffinityConfig兩個欄位配置粘性會話。.spec.sessionAffinity欄位用於定義要使用的粘性會話的型別，它僅支援使用“None”和“ClientIP”兩種屬性值。

• None：不使用sessionAffinity，預設值。
• ClientIP：基於客戶端IP地址識別客戶端身份，把來自同一源IP地址的請求始終排程至同一個Pod物件。

在啟用粘性會話機制時，.spec.sessionAffinityConfig用於配置其會話保持的時長，它是一個巢狀欄位，使用格式如下所示，其可用的時長範圍為“1～86400”，預設為10800秒：

spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    ClientIP:
        timeoutSeconds: <integer>

例如，基於預設的10800秒的超時時長，使用下面的命令修改此前的myapp-svc使用Session affinity機制：

$ kubectl patch services myapp-svc -p '{"spec": {"sessionAffinity": "ClientIP"}}'
service/myapp-svc patched

而後再次於互動式客戶端內測試其訪問效果即可驗證其會話粘性效果。

/ # for loop in 1 2 3 4; do curl http://10.233.16.105:80/hostname.html; done
myapp-deploy-5cbd66595b-2lhds
myapp-deploy-5cbd66595b-2lhds
myapp-deploy-5cbd66595b-2lhds
myapp-deploy-5cbd66595b-2lhds

測試完成後，為了保證本章後續的其他使用效果測試不受其影響，建議將其關閉。當然，使用者也可以使用“kubectl edit”命令直接編輯活動Service物件的配置清單。