更新部署（滾動更新）是否使新舊共存副本同時接收流量？

Question

我只想知道我是否理解文檔的權利：

假設我有一個nginx服務器，配置了1.7.9版的Deployment，配置了4個副本。

apiVersion: apps/v1beta1 # for versions before 1.6.0 use extensions/v1beta1 
kind: Deployment 
metadata: 
    name: nginx-deployment 
spec: 
    replicas: 4 
    template: 
    metadata: 
     labels: 
     app: nginx 
    spec: 
     containers: 
     - name: nginx 
     image: nginx:1.7.9 
     ports: 
     - containerPort: 80 

現在我的圖像更新到1.9.1版本：

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

隨着kubectl get pods我看到以下內容：

> kubectl get pods 
NAME         READY  STATUS  RESTARTS AGE 
nginx-2100875782-c4fwg 1/1  Running  0   3s 
nginx-2100875782-vp23q 1/1  Running  0   3s 
nginx-390780338-bl97b 1/1  Terminating 0   17s 
nginx-390780338-kq4fl 1/1  Running  0   17s 
nginx-390780338-rx7sz 1/1  Running  0   17s 
nginx-390780338-wx0sf 1/1  Running  0   17s 

2的新實例（c4fwg，vp23q） 1.9.1已經開始與1.7.9版本的3個實例共存一段時間。

此時對服務的請求會發生什麼？是否所有的要求都去舊的豆莢，直到所有的新豆莢都可用？或者請求是否在新舊版豆莢之間進行了負載平衡？

在最後一種情況下，是否有方法可以修改此行爲並確保所有流量都轉到舊版本，直到所有新的pod啓動？

Answer 1

「請求發生了什麼」的答案是，它們將在所有與服務中的選擇器匹配的Pod上循環移動，所以是的，它們都將接收流量。我相信kubernetes認爲這是一個功能，而不是一個錯誤。

有關訪問舊Pod的流量的答案可以通過兩種方式來回答：可能部署不適合您推出新Pod的風格，因爲這是他們操作的方式。另一個答案是，您可以更新服務器內的Pod選擇器，以更準確地描述「此服務適用於Pods 1.7.9」，它將該服務固定到「舊」Pod，然後在1.9之後.1豆莢已經啓動並且準備就緒，您可以更新選擇器來說「此服務適用於豆莢1.9.1」

如果您發現所有這些手工勞動過多，那麼有一大堆中介交通管理人員擁有比使用pod選擇器更精細的控制權，或者您可以考慮一個正式推出的產品，例如Spinnaker，它可以自動執行我剛剛描述的任務（當然，假設您可以讓Spinnaker工作;祝您好運與它）