跳转至

在 Kubernetes 环境中，以下是关于 Deployment 在初始副本数为 5 以及使用 HPA 后的情况分析及解决方案：

一、初始副本数为 5 时 Deployment 的正常更新过程和结果

  1. 滚动更新过程
  2. 当进行滚动更新时，Deployment 首先会创建新的 Pod 副本。假设滚动更新策略设置如下：
    • type: RollingUpdate（默认的滚动更新策略）。
    • rollingUpdate:maxUnavailable: 1（最多允许 1 个 Pod 不可用）。
    • rollingUpdate:maxSurge: 1（允许超过当前副本数的 25%，这里副本数为 5，所以最多可额外创建 1 个 Pod）。
  3. 更新开始时，Deployment 会先创建 1 个新的 Pod 副本，当这个新 Pod 进入就绪状态（Ready）后，才会逐步标记旧的 Pod 副本为终止（Terminating）状态，等待旧 Pod 中的业务处理完成并正常关闭后，将其从集群中删除，如此循环，直到所有旧 Pod 都被替换为新的版本。
  4. 整个过程中，始终会确保至少有 4 个 Pod 处于可用状态（因为最多允许 1 个 Pod 不可用），通过这种方式来尽量减少服务中断时间，实现平滑的滚动更新。

二、使用 HPA 后的情况

  1. HPA 自动扩容后的影响
  2. 初始 Deployment 的副本数为 5，但由于 HPA 根据设定的监控指标（如 CPU 使用率等）自动将当前副本的数量进行扩容，例如扩到了 10 个副本。
  3. 当此时需要进行滚动更新且新的 Deployment 资源文件中 replicas 仍然设置为 5 时（可能由于开发者疏忽或未考虑 HPA 动态调整副本数的情况），在滚动更新的第一步，Deployment 就会试图将运行数量的副本数缩放为 5。
  4. 但此时实际运行的副本数已经为 10，这就意味着会有 5 个 Pod（10 - 5 = 5）被直接删除。这种突然的副本数减少会对线上服务的访问造成明显波动，可能导致部分用户在这个短暂的时间段内遇到服务响应变慢、请求失败等问题。

三、解决方案

  1. 遵循官方建议
  2. 根据 Kubernetes 官方文档中关于 Deployment 的概念说明（https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#replicas），当使用 HPA 时，应该省略副本字段。
  3. 这样做的原因是 HPA 旨在根据实际的资源使用情况动态调整副本数，如果在 Deployment 资源文件中固定设置了副本数，就可能与 HPA 的自动扩缩容机制产生冲突。
  4. 优化配置策略
  5. 在实际应用中，应该更加注重 HPA 的动态调整能力，让 HPA 根据实时的资源需求和服务负载来管理副本数量。
  6. 同时，在进行滚动更新时，要充分考虑 HPA 已经调整的副本数情况，避免因 Deployment 资源文件中的副本数设置不当而导致服务波动。可以通过在滚动更新前检查当前 HPA 调整后的副本数，并根据实际情况调整更新策略，确保更新过程更加平稳。
  7. 另外，还需要对 HPA 的监控指标和阈值进行合理设置，以准确反映应用的实际资源需求，避免不必要的扩缩容操作对服务稳定性造成影响。

通过以上措施，可以更好地协调 Deployment 与 HPA 的工作，提高应用在更新过程中的稳定性和服务质量。

image-20240809113419349