OpenShift 4 中的基础架构节点

Issue

通过基础架构节点（Infrastructure node），客户可以为了实现两个主要目的而隔离基础架构工作负载：

1. 避免因为订阅数量造成额外的费用
2. 分离维护和管理。

此文档是在 OpenShift 4 中创建基础架构节点的官方文档的补充。 另外，还有一个 OpenShift Commons 视频介绍了这个过程：OpenShift Commons:Everything about Infra nodes

要实现第一个目的，只需为一个特定节点、一组节点或集群和集群集添加一个节点标签。 红帽订阅 vCPU 计数会忽略标记为 node-role.kubernetes.io/infra: "" 的节点所报告的 vCPU，红帽不会对这些资源收取费用。 在根据本文档的内容进行了相关操作后，请参阅如何确认 OpenShift Cluster Manager 中的订阅成本没有包括 infra 节点？的内容来确定您的 vCPU 报告是正确的。

要实现第二个目的，我们需要专门将基础架构工作负载调度到基础架构节点，并防止将其他工作负载调度到基础架构节点上。 实现这一目标有两种方法，稍后我们会详细介绍。

您可能需要知道，为什么基础架构工作负载与在 control plane 上运行的工作负载不同。 作为最小的要求，OpenShift 集群需要至少包括2 个 worker 节点和 3 个 control plane 节点。虽然对集群的正常运行至关重要的 control plane 组件会被隔离在 master 上，但仍然有一些基础架构工作负载会默认在 worker 节点（集群用户在这些节点上部署应用程序）上运行。

备注： 要了解可在基础架构节点中执行的工作负载，请参阅 OpenShift sizing and subscription guide for enterprise Kubernetes 中的 "Red Hat OpenShift control plane and infrastructure nodes"部分。

对托管这些基础架构组件的任何节点进行改变都需要非常地小心。通常情况下，对它们的改变应该与对运行普通应用程序节点的改变分开来处理。