[Kubernetes]

执行本机 HA 队列管理器的滚动更新的注意事项

对本机 HA 队列管理器的 IBM® MQ 版本或 Pod 规范的任何更新都将要求您对队列管理器实例执行滚动更新。 IBM MQ Operator 会自动处理此问题，但如果您正在构建自己的部署代码，那么存在一些重要注意事项。

注意： Helm包含一个用于执行滚动更新的shell脚本，但该脚本不适合用于生产环境，因为它没有考虑本主题中的注意事项。

在 Kubernetes中， StatefulSet 资源用于管理有序启动和滚动更新。 启动过程的一部分是单独启动每个 Pod ，等待它准备就绪，然后移至下一个 Pod。 这对本机 HA 不起作用，因为所有 Pod 都需要启动，才能进行领导者选举。 因此， StatefulSet 上的 .spec.podManagementPolicy 字段需要设置为 Parallel。 这也意味着所有 Pod 也会并行更新，这是特别不可取的。 因此， StatefulSet 还应该使用 OnDelete 更新策略。

无法使用 StatefulSet 滚动更新代码会导致需要定制滚动更新代码，这应考虑以下内容:
  • 常规滚动更新过程
  • 通过以最佳顺序更新 Pod ，最大限度缩短停机时间
  • 处理集群状态中的更改
  • 处理错误
  • 处理计时问题

常规滚动更新过程

滚动更新代码应等待每个实例显示来自 dspmq的状态 REPLICA 。 这意味着实例已执行某种级别的启动 (例如，容器已启动， MQ 进程正在运行) ，但它还不一定能够与其他实例进行对话。 例如: Pod A 将重新启动，一旦处于 REPLICA 状态， Pod B 将重新启动。 一旦 Pod B 从新配置开始，它应该能够与 Pod A 对话，并且可以构成定额，并且 A 或 B 将成为新的活动实例。

作为此过程的一部分，在每个 Pod 达到 REPLICA 状态后有一个延迟很有用，以允许它连接到其同级并建立定额。

通过以最佳顺序更新 Pod ，最大限度缩短停机时间

滚动更新代码应该一次删除一个 Pod ，从处于已知错误状态的 Pod 开始，然后是尚未成功启动的任何 Pod。 通常应该最后更新活动队列管理器 Pod。

如果上次更新导致 Pod 进入已知错误状态，那么暂停删除 Pod 也很重要。 这将阻止在所有 Pod 中推出中断的更新。 例如，如果 Pod 更新为使用不可访问 (或包含 typo) 的新容器映像，那么可能会发生此情况。

处理集群状态中的更改

滚动更新代码需要对集群状态的实时更改做出相应的反应。 例如，某个队列管理器的 Pod 可能由于 Node 重新引导或 Node 压力而被逐出。 如果集群繁忙，那么可能不会立即重新调度已逐出的 Pod。 在这种情况下，滚动更新代码需要在重新启动任何其他 Pod 之前适当等待。

处理错误

在调用 Kubernetes API 和其他意外集群行为时，滚动更新代码需要稳健以避免失败。

此外，滚动更新代码本身需要容忍被重新启动。 滚动更新可以长时间运行，并且可能需要重新启动代码。

处理计时问题

滚动更新代码需要检查 Pod 的更新修订版，这样可以确保 Pod 已重新启动。 这避免了 Pod 可能指示它 "已启动" 但实际上尚未终止的计时问题。