更新部署(滚动更新)是不是会使新旧共存副本同时接收流量?
Posted
技术标签:
【中文标题】更新部署(滚动更新)是不是会使新旧共存副本同时接收流量?【英文标题】:Does updating a Deployment (rolling update) keep both new and old coexisting replicas receiving traffic at the same time?更新部署(滚动更新)是否会使新旧共存副本同时接收流量? 【发布时间】:2018-01-09 16:38:46 【问题描述】:我只是想知道我是否正确理解了文档:
假设我有一个配置了 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 启动?
【问题讨论】:
【参考方案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 工作;祝您好运)
【讨论】:
嗨,马修,还有一件事,除了 Spinakker,你能给我一些我可以使用的交通管理器的名字吗?谢谢。 抱歉耽搁了; Envoy、fabio、haproxy、kong(尽管它确实面向 API 流量)、traefik、voyager,可能还有很多其他的。该名单上的许多人也可以成为Ingress controllers,这有望用一块石头杀死 2 只鸟 感谢马修的建议! "Kubernetes 认为这是一个特性,而不是一个错误。"当有人称他的 bug 为功能时,总是很难过。以上是关于更新部署(滚动更新)是不是会使新旧共存副本同时接收流量?的主要内容,如果未能解决你的问题,请参考以下文章
在自动缩放条件下重新部署时,Kubernetes 滚动更新不遵守“maxUnavailable”副本
Rolling Update - 每天5分钟玩转 Docker 容器技术(140)
Kubernetes - 滚动更新杀死旧 pod 而不启动新 pod