Question

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

假设我有一个配置了部署的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都启动？

Answer 1

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

关于流向旧Pod的流量的答案可以通过两种方式得到解答：或许Deployments不适合您推出新Pod的风格，因为这是他们运营的方式。另一个答案是您可以更新服务中的Pod选择器以更准确地描述“此服务适用于Pod 1.7.9”，这将把服务固定到“旧”容器，然后甚至只有1.9之一.1 Pods已启动且已准备就绪，您可以更新选择器以说“此服务适用于Pods 1.9.1”

如果您发现所有这些都是过多的手工劳动，那么有一大堆中间流量管理器比使用pod选择器具有更细粒度的控制，或者您可以考虑使用Spinnaker这样的正式部署产品自动化我刚刚描述的内容（当然，假设您可以让Spinnaker工作;我祝你好运）

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

1 个答案: