前面的章節已經實現了CI/CD，并且能成功登陸到管理后臺，但整個流程中deployment的都是一個節點，現在通過dashboard對TLH服務的deployment伸縮為兩個節點。
問題
-
登陸dashboard，擴容
擴容 -
查看Pod的IP地址
kubectl get pods -n tlh -o wide2.png -
重新打開瀏覽器訪問,http://dev.tlh.com/tlh，輸入正確的用戶名和密碼發現有的時候能登陸，有的時候不行，查看ingress的日志，發現請求到達ingress之后轉發到的IP(pod)不一致：
IP地址
熟悉nginx負載均衡的同學很清楚這個是什么問題導致的，而出現該問題的原因在于，擴容之后再ingress中會進行負載均衡，每次請求可能會被轉發到上游服務的不同的pod中，而該pod中的TLH服務再校驗cookie的時候，發現該用戶沒用登陸，所以就重新跳轉到登陸用戶，即ingress沒有保存住用戶登陸的會話，導致同一cookie也會被轉發到不同的pod中。 -
-
修改ingress配置文件
kind: Ingress metadata: name: tlh-ingress namespace: tlh annotations: kubernetes.io/ingress.class: "tlh-nginx-ingress" nginx.ingress.kubernetes.io/affinity: "cookie" # 設置依賴的依據，目前只能為這個值 nginx.ingress.kubernetes.io/affinity-mode: "persistent" # 設置會話持久化，不進行負載 -
重新配置
kubectl apply -f ingress.yaml -n tlh
-
重新登陸問題解決
總結
- 再使用負載均衡之后需要考慮會話保持的問題，解決這個問題的方式：
- 在ingress中保持會話
- 在服務端通過session共享的方式來處理，spring提供了spring-session的模塊可以很好的解決這個問題，通過服務端將session進行持久化(如：存儲到redis中)
