更新部署(滚动更新)是否同时保持新旧共存副本接收流量?

时间:2017-08-02 12:35:46

标签: kubernetes

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

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

1 个答案:

答案 0 :(得分:1)

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

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

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