<!-- 《基于 Kubernetes 的云原生 DevOps》第6章 集群运维 --> <!-- cloud-native-devops-with-kubernetes-ch-06 --> --- > If Tetris has taught me anything, it's that errors pile up and accomplishments disappear. > > -- Adnrew Clay Shafer --- [TOC] ## 6.1 集群的规模与伸缩 初步估算所需容量的一种方法是，想一想运行同一款应用程序需要多少传统服务器。 **最小集群** 最小的 Kubernetes 集群就是单节点集群。你可以通过最小集群尝试 Kubernetes ，并运行少量用于开发的工作负载。 一个健壮的 Kubernetes 集群至少需要 3 个主节点。更妥当的做法是添加一些工作节点，确保你自己的工作负载不会与 Kubernetes 控制平面争夺资源。 如果控制平面具备高可用性，那么你可以只使用一个工作节点，但是以防万一节点发生故障，至少应该准备两个工作节点，并允许 Kubernetes 至少为每个 Pod 运行两个副本。节点越多越好，尤其是因为 Kubernetes 调度器无法总是确保工作负载非常均匀地分布在各个节点之上。 > **最佳实践** > Kubernetes 集群至少需要三个主节点才具备高可用性，而且你可能还需要更多地主节点来处理大型集群地工作。最少需要连个工作节点，工作负载才能承受单个工作节点出错，而三个工作节点则更好。 **最大集群** Kubernetes 版本 1.12 支持最多 5000 个节点的集群。 由于集群需要节点之间的通信，因此通信路径数量以及底层数据库的负载会随着集群的增大呈指数增长。虽然 Kubernetes 可以在 5000 多个节点上运行，但不能保证正常工作，或者至少无法达到生产工作负载要求的响应速度。 Kubernetes 文档建议，官方支持的集群配置不能超过 5000 个节点，Pod 总量不能超过 150000 个，容器总量不能超过 300000 个，而且每个节点上 Pod 数不能超过 100 个。请注意，集群越大，主节点上的负载就越大。如果你自己负责运行主节点，则应对成千上万个节点的集群需要极其强大的机器。 > **最佳实践** > 为了最大化可靠性，请确保 Kubernetes 集群不超过 5000 个节点以及 150000 个 Pod （对于大多数用户而言这不是问题）。如果需要更多资源，请运行多个集群。 **联合集群** 联合能够保持两个或多个集群同步，运行完全相同的工作负载。你可以利用联合集群，通过多个云提供商的 Kubernetes 集群增强健壮性，或通过位于不同的地理位置的集群来减少用户的延迟。 有关联合集群请参见 [Kubernetes 文档](https://kubernetes.io/id/docs/concepts/cluster-administration/federation/)。 大多数 Kubernetes 用户可能并不需要关心联合，而且实际上，大多数大规模用户都可以使用多个无联合集群（每个集群有几百到几千个节点）来处理工作负载。 > **最佳实践** > 如果你需要跨多个集群复制工作负载，例如为了增加地理位置冗余或减少延迟等原因，则可以使用联合。但是，大多数用户不需要联合集群。 **我需要多个集群吗？** > **最佳实践** > 除非一组工作负载或团队确实需要与另一组完全隔离，否则一个生产集群和一个预发布集群就足够了。如果只是为了便于管理想对集群进行分区，那么请使用命名空间。 **选择正确的节点大小** Kubernetes 集群的节点大小没有统一的正确答案。这取决于你的云提供商或硬件提供商，以及工作负载的情况。 > **最佳实践** > 选用提供商提供的性价比最高的节点类型。通常，大型节点的价格更加便宜，但是如果你只有少数几个节点，则可能需要添加一些小节点来实现冗余。 **云实例类型** 小型集群（约 5 个节点以内）的主节点应该至少具备一个虚拟 CPU（vCPU） 和 3 ~ 4 GiB 内存，而大型集群的每个主节点则需要更多的内存和 CPU 。 最低限度的工作节点也应该拥有一个单 CPU 和 4 GiB 内存的实例，但是，有时配置大节点可能更划算。 对于只有几十个节点的大型集群而言，最好混合使用两种或三种不同大小的实例。 **异构节点** 有时也需要一些具有特殊属性的节点，例如图形处理单元（GPU）。 可以使用 Kubernetes 的资源约束功能来指定某个 Pod 至少需要一个 GPU。这可以确保这些 Pod 仅在启用了 GPU 的节点上运行。 如果你需要运行 Windows 容器，则必须提供 Windows 节点。 > **最佳实践** > 大多数容器都是面向 Linux 的，因此我们运行的节点主要也都是基于 Linux 。你可能需要添加一两种特殊类型的节点（例如 GPU 或 Windows）来满足特定的需求。 **裸金属服务器** Kubernetes 可以连接各种大小、体系结构和功能的机器，这也包括许多组织数据中的大量物理裸金属机器。 > **最佳实践** > 如果你的硬件服务器有空闲容量，或者尚未准备好完全迁移到云，则可以使用 Kubernetes 在现有的计算机上运行容器工作负载。 **伸缩集群** 将节点添加到 Kubernetes 集群很容易。如果你运行的是自托管集群，则可以使用 *kops* 之类的集群管理工具。 原则上，缩小 Kubernetes 集群的规模不会有任何问题。你只需告诉 Kubernetes 排空你想要删除的节点，就可以逐步关闭所有正在运行的 Pod ，或将它们移到其它节点上。 大多数集群管理工具会自动帮你排空节点，或者你也可以使用 `kubectl drain` 命令（前提是其余节点有足够的容量）。 排空操作可以让 Pod 优雅地关闭，清理并保存所有必要的状态。 > **最佳实践** > 当不再需要节点时，不能简单地关闭它们。应该首先排空节点，以确保工作负载已被迁移到其它节点，同时还要保证集群中有足够地备用容量。 **自动伸缩** 大多数云提供商都支持自动伸缩，即根据某些指标或计划，自动增加或减少组中的实例数。 - AWS 自动伸缩组（AWS Autoscaling Groups，ASG）可以维护最小以及最大数量的实例； - 可以计划在指定的时间点扩大或缩小规模； - 可以将伸缩组的配置改为根据需要动态扩展或收缩； Kubernetes 有一个名为 *Cluster Autoscaler* 的插件，*kops* 等集群管理工具可以利用这个插件来激活云自动伸缩。 > **最佳实践** > 不要因为集群有自动伸缩的功能就启用。除非工作负载或需求变化很大，否则不太需要这个功能。你应该手动管理集群的规模，至少等运行一段时间，掌握规模需求随着时间的变化规律之后再考虑自动伸缩。 ## 6.2 一致性检查 Kubernetes 本身包含一个测试套件，可验证某个 Kubernetes 集群是否满足某个 Kubernetes 版本的一系列核心要求。 如果你的集群没有通过测试，则说明你的配置存在问题，需要解决。 **Kubernetes 官方认证** 如果你使用托管或部分托管的 Kubernetes 服务，那么请检查它是否带有 Kubernetes 官方认证标识。该标识表明该提供商和服务符合 CNCF 规定的 Kubernetes 官方认证标准。 提供商可以通过运行 *Sonobuoy* 一致性检查工具对产品进行自我认证。 Kubernetes 官方认证的产品必须随时保持 Kubernetes 的最新版本，每年至少需要通过一次更新。 **Kubernetes 管理员认证（CKA）** 如果你想成为 Kubernetes 认证的管理员，你需要证明自己掌握了在生产中管理 Kubernetes 集群的关键技术，包括安装和配置、网络、维护，以及有关 API、安全性和故障排除的知识。 **Kubernetes 认证服务提供商（KCSP）** 提供商可以申请 Kubernetes 认证服务提供商（Kubernetes Certified Service Provider，KCSP）计划。 申请对象必须是 CNCF 成员，提供企业支持，对 Kubernetes 社区做出积极贡献，并雇用 3 名或 3 名以上拥有 CKA 认证的工程师。 > **最佳实践** > Kubernetes 官方认证标识可以确保产品符合 CNCF 标识。在寻找提供商时，请确认 KCSP 认证。如果你想招聘 Kubernetes 管理员，则请确认 CKA 资格。 **Sonobuoy 一致性测试** > **最佳实践** > 请在集群首次建立后运行 *Sonobuoy* ，已验证其是否符合标准且一切正常。之后要经常运行它，以确保没有一致性问题。 ## 6.3 验证和审计 - **K8Guard** 可以检查 Kubernetes 集群的常见问题，并采取纠正措施或只向你发送通知。 K8Guard 还可以导出指标供 Prometheus 等监控系统手机。 - **Copper** 可用于在部署 Kubernetes 清单之前对清单进行检查，并标记出常见的问题，或执行自定义的策略。 它支持一种领域特定语言（Domain-Specific Language，DSL），用于表示验证规则和策略。 还有一个相关工具叫 *kubeval* ，可以根据 Kubernetes API 规范验证清单文件。 - **kube-bench** 可以根据互联网安全中心（Center for Internet Security，CIS）制定的一组基准审核 Kubernetes 集群。 它可以验证你的集群是否根据最佳安全实践进行了设置。 - **Kubernetes 审计日志** 启用审计日志记录后，集群 API 的所有请求都会被记录，且带有时间戳，能够告诉你谁发送了这些请求（哪个服务账号），以及请求的详细信息（例如查询的资源以及响应是什么）。 审计事件可以发送到中央日志记录系统，你可以像处理其它日志数据一样，过滤日志并发出警告。 ## 6.4 混乱测试 **Chaos Monkey 测试**：针对生产服务的自动化随机干扰测试。这个名字来自 Netflix 开发的测试基础设施的同名工具。 生产环境是无法复制的。如果想了解生产环境，就必须在生产环境上测试。 混乱实验必须自动化且连续进行才能发挥最大的作用。只做一次无法确保系统永远可靠。 **混乱测试工具：** - **Chaoskube** chaoskube 会随机干掉集群中的 Pod 。在默认情况下，它会以演习的模式进行，只显示即将执行的操作，而不会实际终止任何东西。 可以通过配置 chaoskube ，根据标签、注释和命名空间包含或排除某些 Pod ，或避免某些时间或日期。 在默认情况下，它可能会干掉任何一个命名空间中的任何一个 Pod ，包括 Kubernetes 系统的 Pod，甚至是 chaoskube 本身。 在你满意 chaoskube 过滤器的配置后，就可以关掉演习模式，让它正常工作了。 - **kube-monkey** kube-monkey 会在预设时间运行，并制定日程计划，确定在其余时间内哪些部署会成为破坏的目标。 与其它工具不同，kube-monkey 采用了选择加入的方式，即只有通过注释专门启用了 *kube-monkey* 的 Pod 才会称为破坏的对象。 - **PowerfulSeal** 一款开源的 Kubernetes 混乱工程工具，它有两种工作模式：交互模式和自动模式。 交互模式下，你可以探索集群并手动搞破坏，然后看看后果会怎样。 自动模式使用一组你指定的策略。 > **最佳实践** > 如果你的应用程序需要高可用性，那么请定期运行 *chaoskube* 之类的混乱测试工具，以确保节点发生意外或 Pod 出现故障时不会引发问题。但要提前向负责运维集群以及测试目标应用程序的人员说明情况。 ## 6.5 小结 - 在配置生产 Kubernetes 集群之前，请思考你需要多少个节点以及各个节点的大小。 - 你至少需要 3 个主节点（如果使用托管服务则不需要）和至少 2 个（最好是 3 个）工作节点。刚开始时，你只需要运行少量的工作负载，这样的 Kubernetes 集群看似有点奢侈，但是请不要忘记集群的弹性和伸缩带来的优势。 - Kubernetes 集群可以扩展到几千个节点以及几十万个容器。 - 如果集群的扩展超过了上述规模，则请使用多个集群（有时出于安全或合规性原因也需要使用多个集群）。如果需要跨集群复制工作负载，则可以使用联合将集群连接在一起。 - 一般 Kubernetes 节点的实例大小为 1 CPU、4 GiB RAM。不过，最好混合使用多种不同大小的节点。 - Kubernetes 不仅仅使用于云。它也可以在裸金属服务器上运行。如果你有裸金属机器，又何必舍近求远呢？ - 手动伸缩集群不是很难，而且你不必频繁地执行该操作。自动伸缩非常好用，但并没有那么重要。 - Kubernetes 提供商和产品又明确的标准：CNCF 认证的 Kubernetes 标志。如果你的提供商和产品没有这个标识，那么应该问问为什么没有。 - 混乱测试可以随机关闭 Pod 并查看你的应用程序是否仍然正常工作。这种方式很有效，但是即便你不这样做，云也总会“给自己找麻烦”。 Loading... 版权声明：本文为博主「佳佳」的原创文章，遵循 CC 4.0 BY-NC-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://www.liujiajia.me/2022/5/13/cloud-native-devops-with-kubernetes-ch-06 提交
