2.10. 重新引导节点
要重新引导节点而不导致平台上运行的应用的中断，务必要先 撤离 pod。对于由路由层提供高可用性的 pod，不需要执行其他操作。对于需要存储的其他 pod（通常是数据库），务必要确保它们能够在一个 pod 临时下线时仍然保持运作。尽管为有状态 pod 实现可持续运行的方法会视不同应用程序而异，但在所有情形中，都要将调度程序配置为使用节点反关联性，从而确保 pod 在可用节点之间合理分布。
另一个挑战是如何处理运行关键基础架构的节点，比如路由器或 registry。相同的节点撤离过程同样适用于这类节点，但必须要了解某些边缘情况。
2.10.1. 基础架构节点
基础架构节点是标记为运行 OpenShift Container Platform 环境组成部分的节点。目前，管理节点重新引导的最简单方法是确保至少有三个节点可用于运行基础架构。以下情景演示了一个常见的错误，只有两个节点可用时，它可能会导致 OpenShift Container Platform 上运行的应用程序发生服务中断。
- 节点 A 标记为不可调度，所有 pod 都被撤离。
- 该节点上运行的 registry pod 现在重新部署到节点 B 上。也就是说，节点 B 现在同时运行两个 registry pod。
- 节点 B 现在标记为不可调度，并且被撤离。
- 在节点 B 上公开两个 pod 端点的服务在短时间内失去所有端点，直到它们被重新部署到节点 A。
使用三个基础架构节点的同一流程不会导致服务中断。但由于 pod 调度的原因，最后一个节点在撤离并返回到轮转后，会保留为运行零个 registry。其他两个节点将分别运行两个 registry 和一个 registry。最好的解决方法是借助 pod 反关联性。Kubernetes 中有一个 alpha 功能，现在可用于测试，但尚不支持用于生产环境工作负载。
