标签：副本 滚动 Kubernetes 更新 翻车 服务 Pod k8s

滚动更新也翻车：为什么 Kubernetes 看似无缝的更新也会影响服务

原创 eshou 原生时光    2024年09月29日 08:45 湖南 听全文

在 Kubernetes 中，滚动更新被视为一种无缝升级服务的理想方式。

然而，实际操作中，即便是看似完美的滚动更新，也可能暗藏影响服务可用性的风险，在我们的生产环境中也碰到了这种实际问题，我们的开发人者反馈说在发布版本的过程中有请求失败的情况。

为什么会这样？本节将探讨滚动更新的工作原理，揭示其中潜在的问题，并提供解决方案，帮助你在 Kubernetes 中实现真正无缝的服务升级。

01

滚动更新原理首先，让我们简要回顾一下 Kubernetes 的滚动更新机制。滚动更新允许你逐步替换旧版本的 Pod，以实现应用的无缝升级，这个过程通常包括以下步骤：

• 创建一个新的 Pod 以运行新的应用版本

• 等待新的 Pod 变为就绪状态

• 终止一个旧的 Pod

• 重复上述步骤，直到所有旧的 Pod 都被替换为新的版本

看起来，这个过程应该是无缝的，对吧？但事实并非总是如此。

 

02

潜在的问题

1. 旧的副本很快销毁：当 Kubernetes 终止一个 Pod 时，它会发送一个 TERM 信号，应用程序需要在接收到这个信号后，完成当前处理的请求并拒绝新的请求。然而，如果应用程序没有正确处理这个信号，Pod 可能会立即退出，导致未完成的请求被中断
2. 新副本启动太慢：在 Kubernetes 中进行滚动更新时，新副本启动太慢可能会导致新连接被调度到尚未完全启动的新副本上，从而影响服务的可用性
3. 资源竞争：在滚动更新过程中，新的 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，确保资源充足

04结语

虽然 Kubernetes 提供了强大的滚动更新机制，但在实际操作中，仍然需要考虑各种潜在问题，以确保服务的高可用性通过优化应用程序启动时间、正确配置 Readiness Probe、合理规划资源、以及使用 preStop 钩子，可以有效减少新副本启动太慢导致的新连接被调度到未完全启动副本上的问题。这些措施不仅能够提高服务的可用性和稳定性，还能确保在滚动更新过程中实现平滑过渡，为用户提供更可靠的服务体验。往期精彩回顾

你是否正确使用了 VPA？一文带你全面了解如何充分发挥其优势

KEDA：解锁 Kubernetes 自动扩缩的无限可能

从容应对突发流量：HPA 如何为你的应用保驾护航

Kyverno：让 Kubernetes 集群合规性和一致性触手可及

阅读 6   ​

标签：副本,滚动,Kubernetes,更新,翻车,服务,Pod,k8s
From： https://www.cnblogs.com/cheyunhua/p/18440459