k8s滚动更新也翻车
滚动更新也翻车:为什么 Kubernetes 看似无缝的更新也会影响服务
在 Kubernetes 中,滚动更新被视为一种无缝升级服务的理想方式。
然而,实际操作中,即便是看似完美的滚动更新,也可能暗藏影响服务可用性的风险,在我们的生产环境中也碰到了这种实际问题,我们的开发人者反馈说在发布版本的过程中有请求失败的情况。
为什么会这样?本节将探讨滚动更新的工作原理,揭示其中潜在的问题,并提供解决方案,帮助你在 Kubernetes 中实现真正无缝的服务升级。01
滚动更新原理
-
创建一个新的 Pod 以运行新的应用版本
-
等待新的 Pod 变为就绪状态
-
终止一个旧的 Pod
-
重复上述步骤,直到所有旧的 Pod 都被替换为新的版本
看起来,这个过程应该是无缝的,对吧?但事实并非总是如此。
02
潜在的问题- 旧的副本很快销毁:当 Kubernetes 终止一个 Pod 时,它会发送一个 TERM 信号,应用程序需要在接收到这个信号后,完成当前处理的请求并拒绝新的请求。然而,如果应用程序没有正确处理这个信号,Pod 可能会立即退出,导致未完成的请求被中断
- 新副本启动太慢:在 Kubernetes 中进行滚动更新时,新副本启动太慢可能会导致新连接被调度到尚未完全启动的新副本上,从而影响服务的可用性
- 资源竞争:在滚动更新过程中,新的 Pod 和旧的 Pod 会同时运行一段时间,这可能会导致资源竞争。如果集群资源不足,可能会导致新的 Pod 无法成功启动,或者旧的 Pod 无法正常终止,从而影响服务的可用性
03
哪些解决方案-
合理设置 terminationGracePeriodSeconds 和 preStop 钩子:通过配置 terminationGracePeriodSeconds 和 preStop 钩子,可以确保旧 Pod 在终止前有足够的时间完成清理工作,并确保新 Pod 准备就绪
spec:
terminationGracePeriodSeconds: 60
containers:
- name: example-container
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "sleep 30"]
- 使用 Readiness Probe:Readiness Probe 用于检测 Pod 是否已经准备好接收流量。通过配置 Readiness Probe,可以确保只有在 Pod 完全准备好后,才会接收流量,从而避免服务中断
readinessProbe:
httpGet:
path: /health
port: 80
initialDelaySeconds: 5
periodSeconds: 10
- 资源规划:在进行滚动更新前,确保集群有足够的资源来同时运行新旧两个版本的 Pod,确保资源充足
虽然 Kubernetes 提供了强大的滚动更新机制,但在实际操作中,仍然需要考虑各种潜在问题,以确保服务的高可用性通过优化应用程序启动时间、正确配置 Readiness Probe、合理规划资源、以及使用 preStop 钩子,可以有效减少新副本启动太慢导致的新连接被调度到未完全启动副本上的问题。这些措施不仅能够提高服务的可用性和稳定性,还能确保在滚动更新过程中实现平滑过渡,为用户提供更可靠的服务体验。往期精彩回顾
分类:
k8s维护篇
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· NetPad:一个.NET开源、跨平台的C#编辑器
2021-09-29 linux的msl
2018-09-29 Python(3)---从迭代器到异步IO