4.6. 了解节点重新引导
若要在重新引导节点时不造成平台上应用程序中断运行，务必要先撤离（evacuate）相关的 pod。对于由路由层提供高可用性的 pod，不需要执行其他操作。对于需要存储的其他 pod（通常是数据库），务必要确保它们能够在一个 pod 临时下线时仍然保持运作。尽管为有状态 pod 实现可持续运行的方法会视不同应用程序而异，但在所有情形中，都要将调度程序配置为使用节点反关联性，从而确保 pod 在可用节点之间合理分布。
另一个挑战是如何处理运行关键基础架构的节点，比如路由器或 registry。相同的节点撤离过程同样适用于这类节点，但必须要了解某些边缘情况。
4.6.1. 了解基础架构节点重新引导
基础架构节点是标记为运行 OpenShift Container Platform 环境组成部分的节点。目前，管理节点重新引导的最简单方法是确保至少有三个节点可用于运行基础架构。运行基础结构的节点称为 master 节点。
以下情景演示了一个常见的错误，只有两个节点可用时，它可能会导致 OpenShift Container Platform 上运行的应用程序发生服务中断。
- 节点 A 标记为不可调度，所有 pod 都被撤离。
- 该节点上运行的 registry pod 现在重新部署到节点 B 上。也就是说，节点 B 现在同时运行两个 registry pod。
- 节点 B 现在标记为不可调度，并且被撤离。
- 在节点 B 上公开两个 pod 端点的服务在短时间内失去所有端点，直到它们被重新部署到节点 A。
如果使用三个 master 节点用于基础架构，则在出现同样的情况时不会导致服务中断。但由于 pod 调度的原因，最后一个节点在撤离并返回到轮转后，会保留为运行零个 registry。其他两个节点将分别运行两个 registry 和一个 registry。最好的解决方法是借助 pod 反关联性。
4.6.2. 使用 pod 反关联性重新引导节点
Pod 反关联性和节点反关联性稍有不同。如果没有其他适当的位置来部署 pod，则可以违反节点反关联性。Pod 反关联性可以设置为必要的或偏好的。
进行了这样的设置后，如果只有两个基础架构节点可用，并且一个节点发生重新引导，容器镜像 registry pod 会被禁止在另一节点上运行。oc get pods 会报告 pod 未就绪，直到有合适的节点可用为止。一旦某个节点可用，并且所有 pod 恢复到就绪状态，下一个节点就可以重启。
流程
使用 pod 反关联性重新引导节点：
编辑节点规格以配置 pod 反关联性：
apiVersion: v1 kind: Pod metadata: name: with-pod-antiaffinity spec: affinity: podAntiAffinity: 1 preferredDuringSchedulingIgnoredDuringExecution: 2 - weight: 100 3 podAffinityTerm: labelSelector: matchExpressions: - key: registry 4 operator: In 5 values: - default topologyKey: kubernetes.io/hostname本例假定容器镜像 registry pod 具有标签
registry=default。Pod 反关联性可以使用任何 Kubernetes 匹配表达式。-
在调度策略文件中启用
MatchInterPodAffinity调度程序 predicate。
4.6.3. 了解如何重新引导运行路由器的节点
在大多数情况下，运行 OpenShift Container Platform 路由器的 pod 会公开一个主机端口。
PodFitsPorts 调度程序 predicate 确保没有使用相同端口的其他路由器 pod 在同一节点上运行，并且达成 pod 反关联性。如果路由器依赖 IP 故障转移来实现高可用性，则不需要任何其他操作。
如果路由器 pod 依赖 AWS Elastic Load Balancing 等外部服务来实现高可用性，则由该服务负责响应路由器 pod 重启。
在极少见的情形中，路由器 pod 可能没有配置主机端口。这时，务必要按照推荐的基础架构节点重启流程来进行操作。
