库伯奈特斯支持绿色-蓝色部署吗？
我想问一下在库伯奈特停止吊舱的机制。
问这个问题之前，我读过https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods。
显然，我们有一个具有优雅关闭支持的应用程序(例如，我们在Go https://play.golang.org/p/5tmkPPMiSSt上使用简单的http服务器)。
服务器有两个端点：
- /fast，始终发送200个http状态代码。
- /slow，等待10秒，发送200个http状态代码。
具有该配置的部署/服务资源如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 1
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app/name: test
template:
metadata:
labels:
app/name: test
spec:
terminationGracePeriodSeconds: 120
containers:
- name: service
image: host.org/images/grace:v0.1
livenessProbe:
httpGet:
path: /health
port: 10002
failureThreshold: 1
initialDelaySeconds: 1
readinessProbe:
httpGet:
path: /health
port: 10002
failureThreshold: 1
initialDelaySeconds: 1
---
apiVersion: v1
kind: Service
metadata:
name: test
spec:
type: NodePort
ports:
- name: http
port: 10002
targetPort: 10002
selector:
app/name: test为了确保这些吊舱被优雅地删除，我进行了两个测试选项。
第一个选项(慢端点)流：
- 创建副本值等于1的部署。
- 等待吊舱的准备。
- 在/slow端点(curl http://ip-of-some-node:nodePort/slow)上发送请求并删除pod (同时，不同步1秒)。
期望
在http服务器完成我的请求之前，Pod不能结束。
得到了
是的，http服务器在10秒内处理，并为我返回响应。(如果我们将-宽限期=1选项传递给kubectl，则curl将写- curl：(52)服务器的空回复)
一切都如期而至。
第二个选项(快速端点)流：
- 创建副本值等于10的部署。
- 等待豆荚的准备。
- 使用"Connection: close“标题启动。
- 随机删除一个或两个荚(kubectl删除荚/xxx)。
期望
没有套接字错误。
得到了
$ wrk -d 2m --header "Connection: Close" http://ip-of-some-node:nodePort/fast
Running 2m test @ http://ip-of-some-node:nodePort/fast
Thread Stats Avg Stdev Max +/- Stdev
Latency 122.35ms 177.30ms 1.98s 91.33%
Req/Sec 66.98 33.93 160.00 65.83%
15890 requests in 2.00m, 1.83MB read
Socket errors: connect 0, read 15, write 0, timeout 0
Requests/sec: 132.34
Transfer/sec: 15.64KB读取时出现15个套接字错误，即在处理所有请求(可能)之前，一些端口被断开与服务的连接。
当应用新部署版本、缩小规模和推出撤消时，会出现此问题。
问题
- 这种行为的原因是什么？
- 怎么修呢？
Kubernetes版本: v1.16.2
编辑1。
每次错误的次数都会发生变化，但在两分钟内移除2-5个吊舱时，错误的数量将保持在10-20之间。
如果我们不删除一个吊舱，我们就没有错误。
回答 1
Stack Overflow用户
发布于 2019-11-22 12:01:28
库伯奈特斯支持绿色-蓝色部署吗？
是的，确实如此。你可以在与Jenkins一起在Kubernetes部署零停机时间上读到
蓝色/绿色部署是发布软件代码的更改管理策略。蓝色/绿色部署(也称为A/B部署)需要两个完全相同的硬件环境，它们的配置方式完全相同。当一个环境处于活动状态并为最终用户服务时，另一个环境仍然处于空闲状态。容器技术提供了一个独立的环境来运行所需的服务，这使得在蓝色/绿色部署中创建相同的环境变得非常容易。松散耦合的服务- ReplicaSets以及Kubernetes中基于标签/选择器的服务路由使得在不同的后端环境之间切换变得非常容易。
我还建议您阅读Kubernetes基础设施-蓝色/绿色部署。
这里是一个存储库，包含来自codefresh.io的有关蓝绿色部署的示例。
这个存储库包含一个bash脚本，它允许您在Kubernetes集群上执行蓝色/绿色部署。还请参见相应的博客帖子 先决条件 作为一个惯例，脚本希望
- 部署的名称为
$APP_NAME-$VERSION - 您的部署应该有一个标签，显示它的版本。
- 您的服务应该通过使用
version选择器指向部署中的相应标签来指向部署。
注意，脚本创建的新颜色部署将遵循相同的约定。这样，您运行的每个后续管道都将以相同的方式工作。
您可以看到示例应用程序中的标记示例：
您也可能对加那利部署感兴趣
另一种部署策略是使用金丝雀 (a.k.a )。递增推出)。使用金丝雀，应用程序的新版本将逐步部署到Kubernetes集群中，同时获得非常少量的实时通信量(即一部分活动用户连接到新版本，而其余用户仍在使用以前的版本)。..。 新版本的一小部分实时通信可以作为对新代码中可能出现的潜在问题的早期警告。随着我们信心的增强，更多的金丝雀被创建，更多的用户正在连接到更新的版本。最后，所有的直播流量都会流向金丝雀，因此金丝雀版本成为了新的“制作版本”。
编辑
问答：
- 这种行为的原因是什么？
当新的部署被应用时，旧的豆荚被移除，新的豆荚被调度。这是通过控制计划来完成的。
例如，当您使用Kubernetes API创建部署时，您为系统提供了一个新的所需状态。Kubernetes控制平面记录该对象的创建，并通过启动所需的应用程序并将它们调度到集群节点来执行您的指令--从而使集群的实际状态与所需的状态匹配。
您只设置了一个readinessProbe，它告诉您的service是否应该发送流量到吊舱。这不是一个很好的解决方案，就像你在你的例子中看到的那样，如果你有10个豆荚，去掉一个或两个，就会有一个缺口，你会收到套接字错误。
- 怎么修呢？
你必须明白这不是坏的，所以它不需要修复。
这可以通过在应用程序中实现检查来缓解，以确保它向工作地址发送请求，或者利用负载平衡(如ingress )等其他功能。
另外，在更新部署时，您可以在删除pod之前进行检查，以检查它是否有传入/传出的通信量，并将更新滚到仅未使用的吊舱中。
https://stackoverflow.com/questions/58932219
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号