2.3 规划集群规模

在本节中，你将部署一个多节点的OpenShift集群。有一些注意事项，其中最重要的是规划集群的大小和容量。

2.3.1 实例大小的建议

OpenShift文档中有一些关于如何扩展集群实例的指导意见。让我们来看看，如果你的规模太小，你会遇到哪些潜在的问题。你可以有把握地认为，除了成本之外，扩展过大并不是一个问题。在下面的章节中，你也会发现有关这方面的评论。

实例大小与你的工作负载直接相关，master节点和node节点的行为在某种程度上是相似的。你计划运行的工作负载越多，你的实例就必须变得越大。然而，它们的扩展方式在根本上是不同的。node节点直接与工作负载几乎呈线性关系，而master节点则不然。这意味着，一个集群的容量可以扩展到一定程度，而不需要对控制面进行任何调整。

2.3.2 node节点大小的建议

为了更好地说明节点的扩展行为，让我们看一个例子。

想一想一个由三个node节点组成的集群，暂时不考虑master节点。每个节点都是AWS的m5.xlarge，所以有4个vCPU和8GB的内存。这使你的集群总容量为12个vCPU和24GB内存。在这个虚拟场景中，你可以尝试以完美的分布运行工作负载，并使用所有的资源，然后你将需要将节点扩展到更大的实例（水平扩展）或更多的实例（垂直扩展）。再增加一个实例，集群的容量就会线性增长。现在你有16个vCPU和32GB，用于我们的工作负载。

上述情况忽略了一个小而重要的细节：系统保留和kube保留的容量。从OpenShift 4.8版本开始，OpenShift可以自动处理这个问题。要启用这个功能，请在KubeletConfig中添加以下内容：

可以在安装后以及创建集群前调整KubeletConfig。强制OpenShift占用系统相关的资源是确保集群功能的一个推荐设置，除非有明确的原因，否则不应省略。

设想一下：10个运行在一个m5.xlarge node的pod，每个pod都有一组0.4个CPU的请求的资源，而且它们实际使用了这个资源。自然，你的系统进程会遇到麻烦，该节点变得不稳定。在最坏的情况下，该节点变得没有反应并崩溃，其上的工作负载被重新分配到其他节点，使这些节点超载，你最终会发生连锁反应：你的整个集群变得不稳定。从这个角度来看，牺牲一些宝贵的容量来确保集群的稳定性，是一个很小的代价。

因此，我们知道，节点的规模与工作负载呈线性关系，我们需要在此基础上增加一些保留容量。那么，你的节点应该有多大？我们必须考虑三个问题：

•你的单一最大工作负载有多大？

•你能在多大程度上利用一个大节点？

•你能以多快的速度部署更多的节点？

单一最大的工作负载决定了一个节点的最小尺寸。解释是，如果你不能在一个节点上运行工作负载，那么你就有问题了，因为你希望能够将所有的工作负载部署到集群上。

这一点的反面是你想要实现的效率。让一个节点一直在50%的使用率下闲置，实际上只是在烧钱。你想在能够适应所有工作负载，同时又能充分利用你的节点之间找到一个平衡点。这两点共同导致了我们希望使用尽可能小的节点，如果你需要更多的节点，就再部署一个，这样即使在集群中增加一个额外的节点，每个节点的利用率仍然很高。

能使你选择不同路径的因素是时间：在你遇到容量问题时，部署另一个节点所需的时间。某些部署方式比其他方式要快。例如，设置自动化可以允许你在5分钟内将另一个节点部署到集群中，这与在数据中心手动配置一个新的刀片并等待一天直到数据中心团队安装和连接它有很大区别。

这里的规则是，你配置新节点的速度越慢，单个节点需要越大，你就必须越早配置新节点。提供新节点的时间直接影响到你想达到的每个节点的最大利用率。

2.3.3 master节点大小的建议

node节点对于给你的工作负载提供一个运行环境很重要，但master是OpenShift的核心。

master，即控制面节点，是保持集群运行的原因，因为它们运行着：

•etcd

•API服务器（kube和OpenShift）

•控制管理器（kube和OpenShift）

•OpenShift Oauth API服务器

•OpenShift Oauth服务器

•HA代理

master不直接运行工作负载，因此，当涉及可扩展性时，它们的行为是不同的。相对于node节点的线性可扩展性需求（取决于工作负载），master的容量必须与节点的数量一起扩展。

与node节点可扩展性相比，另一个区别是你需要关注垂直扩展而不是水平扩展。你不能简单地横向扩展master节点，因为一些在master节点上运行的组件需要一个法定人数以及复制。最突出的例子是etcd。状态、密钥等的中心存储只是其中一个组件。理论上，只要能形成一个法定人数，OpenShift集群中几乎可以有任意数量的master。这意味着需要进行领导选举，并获得多数票。这可能会变得相当棘手，比如说像4或2的偶数节点。在这些情况下，不能保证任何给定的节点会有多数票，领导选举可能会被卡住，或者更糟的是，可能会选出多个领导，这可能会破坏集群的稳定性。问题是：“为什么不是只有1个？”这个问题的答案是集群的弹性。你不能因为只有一个故障点而使你的整个集群面临风险，因为没有master节点，集群基本上是无法使用的。想象一下这样的情景：你有一个master实例，而它因为底层基础设施的故障而崩溃。这时，整个集群完全没有用处，从这种故障中恢复是很难的。接下来最小的选项是3，这也是我们的建议。事实上，官方文件指出，所有的生产部署必须使用正好三个master节点（https://oreil.ly/Izxdc）。

设置好master节点的数量后，我们就可以选择垂直扩展了。然而，由于master节点是集群的核心，当你调整已经运行的master节点的大小时，你必须考虑到集群的脆弱状态，因为它需要被关闭以调整大小。

请确保为增长做计划。如果你计划在一开始就有20个节点，以便为你的工作负载提供空间，那就选择下一个更大尺寸的master节点实例。这样做的代价不大，但会因为避免了主实例的扩展操作而为你节省大量的工作和风险。

2.3.4 infra节点

infra节点是带有额外标签的工作节点。除此以外，它们只是普通的OpenShift节点。那么，如果它们只是节点，为什么它们会有额外的标签？有两个原因：成本和集群的弹性。

第一个且最简单的原因是成本。某些基础设施的工作负载不会触发红帽的订阅费用。这意味着，如果你有一个专门运行基础设施工作负载的节点，你不必为该节点支付订阅费用。这似乎是一个省钱的简单方法。为了完整起见，不需要节点订阅的组件的完整列表可以在最新的文档（https://oreil.ly/ef1Ea）中找到。有些组件在master上运行，也需要在那里，比如OCP控制面。其他的则可以随意移动。因此，你创建了一组新的节点，带有infra标签。

第二个原因是集群的弹性。当常规工作负载和infra工作负载在同一个节点上时，对OpenShift来说并没有什么区别。想象一下，一个只有master和worker节点的常规集群。你把所有的应用程序以及开箱即用的infra工作负载部署到节点上。现在，当不幸的情况发生时，你的资源用完了，infra工作负载可能会像常规应用程序工作负载一样被杀死。当然，这不是最好的情况。另外，当所有与基础设施相关的工作负载被安全地放在自己的一组节点上时，常规应用程序根本不会影响它们，从而创造出更好的弹性和更好的性能。适合移动到infra节点的有：

•集群内监控（configmap）

•路由器（IngressController）

•默认镜像注册表（Config）

通过向括号内标注的相应元素添加标签来移动它们。下面的示例展示了如何在集群内监控解决方案中执行此操作。

将它添加到已经存在的configmap中，或者用它创建一个新的configmap。对于后一个选项，我们将创建前面的文件，并按如下方式应用它：

接下来执行下面的命令：

关于infra节点的扩展的最后一个注意事项：它们的扩展方式几乎与master节点相同。首先，它们需要垂直扩展的原因是Prometheus作为集群内监控解决方案的一部分，需要更多的内存和存储更多的指标。