《使用 Kubernetes 实现云原生 DevOps（第二版）》

第 6 章 操作集群 操作集群

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

如果说俄罗斯方块教会了我什么，那就是错误堆积如山，成就消失殆尽。

安德鲁-克莱-谢弗

拥有 Kubernetes 集群后，如何知道它处于良好状态并正常运行？如何进行扩展以满足需求，同时将云成本降至最低？在本章中，我们将探讨为生产工作负载运行 Kubernetes 集群所涉及的问题，以及一些可以帮助你的工具。

正如我们在第 3 章中看到的，Kubernetes 集群有许多重要事项需要考虑：可用性、身份验证、升级等。如果你像我们推荐的那样，使用良好的 Kubernetes 托管服务，那么这些问题中的大部分都会为你解决。

不过，集群的实际用途取决于你自己。在本章中，您将学习如何确定集群的大小和规模、检查其一致性，以及使用Chaos Monkeys 测试基础架构的弹性。

集群规模和扩展

集群需要多大？对于自托管 Kubernetes 集群以及几乎所有托管服务，集群的持续成本直接取决于其节点的数量和规模。如果集群容量太小，您的工作负载将无法正常运行，或在大流量情况下出现故障。如果容量过大，则会造成资金浪费。

适当调整和扩展集群规模非常重要，让我们来看看其中涉及的一些决策。

容量规划

对所需容量进行初步估算的一种方法是，想想运行相同的应用需要多少台传统服务器。例如，如果您当前的架构运行在 10 个独立的 Cloud 虚拟机实例上，那么您的 Kubernetes 集群可能不需要超过 10 个类似大小的节点来运行相同的工作负载，另外再加上 1 或 2 个用于冗余。事实上，你可能根本不需要那么多，因为 Kubernetes 会在所有机器上平均平衡容器，因此可以实现比传统服务器更高的利用率。但这可能需要一些时间和实践经验来调整你的集群，使其达到最佳容量。

最小的群组

刚开始建立集群时，您可能会用它来玩玩，做做实验，看看如何运行您的应用程序。因此，在对所需容量有一定了解之前，您可能不需要在大型集群上烧钱。

最小的 Kubernetes 集群是单节点。这将允许你试用 Kubernetes 并运行小型工作负载进行开发，正如我们在第 2 章中看到的那样。不过，单节点集群无法抵御节点硬件、Kubernetes API 服务器或 kubelet（负责在每个节点上运行工作负载的代理守护进程）的故障。

如果你使用的是托管的 Kubernetes 服务，比如 GKE、EKS 或 AKS（请参阅"托管的 Kubernetes 服务"），那么你就不需要担心控制平面节点的调配问题：控制平面节点的调配已为你完成。另一方面，如果你正在构建自己的集群，就需要决定如何布局控制平面。

一个有弹性的 Kubernetes 集群至少需要三个控制平面节点。一个节点不会有弹性，而两个节点可能会在谁是领导者的问题上产生分歧，因此至少需要三个节点。

虽然你可以在这么小的 Kubernetes 集群上完成有用的工作，但并不推荐这样做。更好的办法是添加一些工作节点，这样你自己的工作负载就不会与 Kubernetes 控制平面争夺资源。

如果集群控制平面的可用性很高，单个工作节点也能胜任，但为了防止节点故障并让 Kubernetes 至少为每个 Pod 运行两个副本，两个节点是最合理的。节点越多越好，尤其是 Kubernetes 调度器无法始终确保工作负载在各可用节点之间完全平衡（参见"保持工作负载平衡"）。

K3S

说到轻量级集群，K3s这样的工具值得一试。它将所有 ...