规划 Kubernetes Worker 节点数量？

概述 在规划k8s集群工作节点时，首先需要考虑的问题是：应该使用什么类型的服务器（Linux）实例节点，需要多少个节点？ 集群容量 通常k8s集群可以看作是把多个服务器（Linux）节点抽象成一个大的“超级服务器节点”。超级节点的总算力（如CPU、内存）是所有组成节点能力的总和。如果要在集群上运行一组应用程序，需要集群总容量为 8 个 CPU 核心和 32 GB 内存。两种可能的实例规格和数量配置如下： 方案一：使用2个4核16GB服务器实例作为k8s工作节点 方案二：使用4个2核8GB服务器实例作为k8s工作节点 哪个选项更好？相信大多数人此时都有些困惑。为了解决大家的疑问，下面我来分析一下这两种方案的优缺点。 选项一 使用两个4核16GB服务器实例作为k8s工作节点 优势 1. 减少管理开销 管理少量计算机比管理大量计算机所需的劳动力更少 2.降低每个节点的成本 虽然功能更强大的机器比低端机器更贵，但价格上涨不一定是线性的；例如，一台具有 10 个 CPU 内核和 10 GB RAM 的计算机可能比 10 台具有 1 个 CPU 内核和 1 GB RAM 的计算机要贵。电脑很便宜 3. 允许运行资源匮乏的应用程序 如果您有一个需要 8 GB 内存的机器学习应用程序，则无法在节点只有 1 GB 内存的集群上运行它；但您可以在节点具有 10 GB 内存的集群上运行它 缺点 1、每个节点都有大量的Pod 每个 Pod 都会给在该节点上运行的 Kubernetes 代理带来一些开销，例如容器运行时（例如 Docker）、kubelet 和 cAdvisor。 kubelet 对节点上的每个容器执行定期的活动和就绪探测 - 更多容器意味着 kubelet 在每次迭代中要做更多的工作。 cAdvisor 收集节点上所有容器的资源使用统计信息，而 kubelet 会定期查询这些信息并将其公开在其 API 上——同样，这意味着 cAdvisor 和 kubelet 都需要在每次迭代上做更多的工作。 如果 Pod 数量变大，这些事情可能会开始减慢系统速度，甚至使其变得不可靠。 2. 有限复制节点数量较少可能会限制应用程序的有效复制度，如果您有一个由 5 个副本组成的高可用性应用程序，但只有 2 个节点，则应用程序的有效复制度将降低为 2。 3、爆炸半径更大 如果您只有几个节点，则故障节点的影响将比有多个节点时更大。 4. 大变焦比 Kubernetes 为云基础设施提供了集群自动缩放器，可根据当前需求自动添加或删除节点。 选项二 使用4个2核8GB服务器实例作为k8s工作节点的情况；这种方法涉及由许多小节点而不是一些大节点形成集群。 这种方法的优点和缺点是什么？ 使用许多小节点的优点主要对应于使用少量大节点的缺点。 优势 1.爆炸半径减小 如果您有 100 个 Pod 和 10 个节点，则每个节点平均只包含 10 个 Pod。因此，如果其中一个节点发生故障，受影响的 Pod 数量就会较少。 很可能只有部分应用程序受到影响，并且可能只有少量副本受到影响，因此整个应用程序不会受到影响。 2.允许高复制并实现高可靠性 Kubernetes 调度程序可以将每个副本分配给更多不同的节点，这意味着如果一个节点发生故障，最多只有一个副本会受到影响，而您的应用程序仍然可用。 缺点 1、节点数量多 节点越小，自然需要更多的节点才能达到给定的集群容量，而大量的节点对于 Kubernetes 控制平面来说可能是一个挑战。 每个节点都需要能够与其他每个节点进行通信，这使得可能的通信路径的数量与节点数量的平方成比例增长，所有这些都必须由控制平面进行管理。 2.更多的系统开销 Kubernetes 在每个工作节点上运行一组系统守护进程，例如容器运行时 Docker、kube-proxy、kubelet 等。这些守护进程共同消耗固定数量的资源。如果使用很多小节点，这些系统组件使用的资源部分就会更大。 3、降低资源利用率 如果使用较小的节点，最终可能会产生大量的资源碎片，这些碎片太小而无法分配给任何工作负载，从而导致资源浪费。 4. Pod 对小节点的限制 在某些云基础设施上，小型节点上允许的最大 Pod 数量比您预期的更有限，例如 Amazon Elastic Kubernetes Service (EKS)，其中每个节点的最大 Pod 数量取决于实例类型。 综上所述那么你的集群中应该使用几个大节点还是多个小节点呢？一如既往，通常没有明确的答案！ 如果您的应用程序需要 10 GB 内存，您可能不应该使用小节点 - 集群中的节点应该至少有 10 GB 内存； 如果您的应用程序需要 10 倍复制来实现高可用性，那么您可能不应该仅使用 2 个节点 - 您的集群应至少包含 10 个节点