在执行常规K8维护过程（如迁移/升级群集）时，是否需要采取任何特殊的预防措施？
为了具体起见，我通过Flink K8s Operator运行我的作业，我发现当推出新节点并将我的作业迁移到它们时，在某些情况下，它们会卡住和/或无法正确重启，或者多次重启，导致停机时间比预期的要长。
到目前为止，我的迁移/推出过程如下：

• 创建新的K8s节点/示例
• 封锁旧的被替换（我的工作正在运行）
• 获取保存点
• 排出旧节点
• 等待，直到所有作业在新节点中显示为RUNNING和STABLE

我在这里没有什么特别的。但是，我想知道是否有任何专门针对Flink的最佳实践，可以帮助最大限度地减少这些维护窗口期间的停机时间/潜在故障。例如调整预算中断策略和/或pod亲和力，或者考虑使用多个jobmanager而不是一个jobmanager的HA设置。为了清楚起见，我所有的作业都是这样部署的（在应用程序模式下）：

apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
...
spec:
  ...
  mode: native

字符串
值得一提的是，他们的HA设置基于原生K8s模式（与Zookeeper相比）和单个作业管理器。