更新部署（滚动更新）是否会使新旧共存副本同时接收流量？

Question

我只是想知道我是否正确理解了文档：

假设我有一个配置了 Deployment 的 nginx 服务器，版本为 1.7.9，有 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

1.9.1 的 2 个新实例（c4fwg、vp23q）已开始与 1.7.9 版本的 3 个实例共存一段时间。

此时向服务发出的请求会发生什么情况？在所有新的 Pod 可用之前，所有的请求都会转到旧的 Pod 吗？还是新旧 pod 之间的请求负载均衡？

在最后一种情况下，有没有办法修改此行为并确保所有流量都流向旧版本，直到所有新 pod 启动？

Answer 1

“请求会发生什么”的答案是，它们将在与服务中的选择器匹配的所有 Pod 中循环，所以是的，它们都将接收流量。我相信 kubernetes 认为这是一个特性，而不是一个错误。

关于流向旧 Pod 的流量的答案可以通过两种方式来回答：也许 Deployment 不适合您推出新 Pod 的方式，因为这是它们的操作方式。另一个答案是，您可以更新 Service 中的 Pod 选择器，以更准确地描述“此 Service 适用于 Pod 1.7.9”，这会将 Service 固定到“旧”Pod，然后甚至只在 1.9 之一之后.1 Pods 已启动并准备就绪，您可以更新选择器以显示“此服务适用于 Pods 1.9.1”

如果您发现所有这些都需要过多的体力劳动，那么有一大堆中间流量管理器可以进行更细粒度的控制，而不仅仅是使用 pod 选择器，或者您可以考虑使用正式推出的产品，例如 Spinnaker，它将自动化我刚刚描述的内容（当然，假设您可以让 Spinnaker 工作；祝您好运）