基于 Kubernetes 的云原生 DevOps 第 3 章 获取 Kubernetes

🏷️ Kubernetes 《基于 Kubernetes 的云原生 DevOps》

---

Perplexity is the beginning of knowledge.

-- Kahlil Gibran

---

Kubernetes 是云原生世界的操作系统，为运行容器化工作负载提供了可靠且可扩展的平台。

3.1 集群架构

Kubernetes 将多个服务器连接到一起组成一个集群。

控制平面

集群的大脑被称作控制平面，它负责运行 Kubernetes 完成工作所需的所有任务：调度容器、管理服务、服务 API 请求等。

控制平面由如下几个组件组成：

• kube-apiserver ：控制平面的前端服务器，负责处理 API 请求。
• etcd ：Kubernetes 的数据库，用于存储所有信息：有哪些节点，集群上存在哪些资源等。
• kube-scheduler ：决定在何处运行新创建的 Pod。
• kube-controller-manager ：负责运行资源控制器，例如部署等。
• cloud-controller-manager ：负责与云提供商（在基于云的集群中）进行交互，管理负载均衡器以及磁盘卷之类的资源。

运行控制平面组件的集群成员称为主节点。

节点组件

负责运行工作负载的集群成员称为工作节点。

Kubernetes 集群中的每个工作节点会运行以下组件：

• kubelet ：负责容器的运行时，启动调度到某个节点上的工作负载，并监视其状态。
• kube-proxy ：网络代理，负责将请求路由到不同节点的 Pod 上，以及将请求从 Pod 路由到互联网上。
• 容器运行时 ：负责启动和停止容器，并处理容器通信。通常是由 Docker 负责，但 Kubernetes 也支持其它容器运行，例如 rkt 和 CRI-O 。

除了运行不同的软件组件之外，主节点和工作节点之间没有本质的区别。但是，通常主节点不负责运行工作负载，除非是在非常小的集群中。

高可用性

配置得当的 Kubernetes 控制平面拥有多个主节点，因此具有很高的可用性。对于生产集群而言，最少应该保证 3 个主节点。

相比之下，某一个工作节点的故障就没有那么重要了。只要控制平面仍在工作，Kubernetes 就会在检测到故障时，将节点上的 Pod 重新安排到其它地方。

你应该假定随时可能会出现某个节点故障，尤其是在云中，而且两个节点同时发生故障的情况也不是没有先例。

最好不要将所有工作节点都放在同一个区域中，分布在两个或者三个区域中更为妥当。

尽管高可用性可以让你的集群在失去一个主节点或几个工作节点的情况下仍然正常工作，但最好还是实际测试一下。在计划好的维护时段内或高峰时段外，尝试重新启动某个工作节点，然后看看会发生什么情况。

3.2 自托管 Kubernetes 的成本

所谓“自托管”指的是由你本人或组织中的团队在自家拥有或控制的计算机上安装和配置 Kubernetes，就像使用 Redis、PostgreSQL 或 Nginx 等其它软件一样。

这种方式可以为你提供最大的灵活性和控制力。

自托管方式所需的资源最多，包括人员、技术、工程时间、维护和故障排除等。你至少需要考虑以下几个问题：

• 控制平面是否具备高可用性？如果主节点出现故障或无法响应，你的集群是否仍能正常工作？你是否仍然可以部署或更新应用程序？如果没有控制平面，正在运行的应用程序是否仍然可以容错？
• 工作节点池是否具备高可用性？如果断电导致多个工作节点中断，甚至整个云可用区中断，你的工作负载是否会停止运行？你的集群会继续工作吗？它是否能够自动配置新节点以完成自我修复，还是需要手动干预？
• 集群的设置是否安全？内部组件之间是否使用 TLS 加密和信赖的证书进行通信？用户和应用程序是否拥有最低限度的集群操作权限？容器的安全默认值设置是否正确？节点是否拥有不必要的访问控制平面组件的权限？底层 etcd 数据库的访问是否得到了正确的控制和认证？
• 集群中的所有服务是否都很安全？如果可以通过互联网访问这些服务，那么是否建立了正确的验证和授权？集群 API 的访问是否有严格的限制？
• 你的集群是否符合规范？是否符合云原生计算基金会定义的 Kubernetes 集群标准。
• 集群节点是否完全通过配置进行管理，而不是通过命令式的 shell 脚本手动设置好后就无人问津？每个节点的操作系统和内核都需要更新、打安全补丁等。
• 集群的数据（包括所有持久性数据）是否进行了正确备份？你的恢复流程是什么？你多久测试一次恢复流程？
• 在建立好集群后，如何对其进行长期的维护？如何添加新节点？如何将配置变更推到现有节点上？如何推出 Kubernetes 更新？如何根据需求扩展规模？如何执行策略？

根据分布式系统工程师兼作家 Cindy Sridharan 的估计，从头开始建立 Kubernetes，并在生产配置中运行集群，大约需要花费一百万美元的工程师费用（“而且可能仍然无法顺利实现”）。

结合我们的经验，并结合本书采访的许多人的经验，托管服务是运行 Kubernetes 的最佳方法，没有之一。

3.3 托管 Kubernetes 服务

主要是讲国外的云供应商，国内基本上用不到。其中作者最推荐 Google 的 GKE。

• Google Kubernetes Engine （GKE）
• Elastic Container Service for Kubernetes（EKS）
• Azure Kubernetes Service（AKS）
• OpenShift
• IBM Cloud Kubernetes Service

3.4 一站式 Kubernetes 解决方案

在某些无法选择使用托管服务的情况下使用。

• Containership Kubernetes Engine（CKE）

3.5 Kubernetes 安装程序

自己搭建 Kubernetes 时可使用的工具或服务：

• kops
• Kubespray
• TK8
• kubeadm
• Tarmak
• Rancher Kubernetes Engine（RKE）
• Puppet Kubernetes
• Kubeformation

3.6 购买还是构建：我们的建议

运行更少软件（run less software）

1. 选择标准的技术。
2. 外包千篇一律的繁重工作。
3. 创造持久的竞争优势。

根据“运行更少软件”的理念，我们建议你将 Kubernetes 集群运维外包给托管服务。

只有当你有特殊的需求，Kubernetes 的托管产品不适合时，才应该考虑自己运行 Kubernetes。

如果遇到这种情况，那么应该选择最成熟、功能最强大且使用最广泛的工具。我们建议使用 Kops 或 Kubespray，不过你应该根据自己的需求来选择。

如果你确定会长期使用某个云提供商的产品，特别是在使用 AWS 的情况下，请使用 Kops 。

相反，如果你需要跨越多个云或平台（包括罗金属服务器）的集群，而且你愿意尝试多种选择，则应使用 Kubespray 。

当你的云提供商不提供 Kubernetes 托管服务时，可以使用一站式解决方案。这些选择提供 Kubernetes 主节点托管服务，你只需将它们连接到运行工作节点的基础设施之上。

你也可以在自己的硬件机器上运行 Kubernetes。如果预算有限，甚至可以在树莓派上运行 Kubernetes。

3.7 无集群容器服务

如 Azure Container Instances 或 Amazon Fargate。尽管底层确实有一个集群，但你无法通过 kubectl 之类的工具访问。你只需提供一个运行的容器镜像，以及一些参数，其余全部交由服务完成。

• Amazon Fargate：以秒为单位按照任务消耗的 CPU 和内存资源量计费。适用于简单、自包含、运行时间较长，且不需要大量定制或与其它服务集成的计算任务或批处理任务（例如数据处理）。此外，在构建寿命很短的容器，以及任何不值得对工作节点进行管理的情况下，Fargate 是理想之选。
• Azure Container Instances：类似于 Fargate，但它还提供与 Azure Kubernetes Service（AKS）的集成。ACI 还集成了 Azure Event Grid（微软的托管事件路由服务）。可以使用 Azure Functions 创建或运行 ACI 容器，也可以将数据传递给 ACI 容器。

3.8 小结

我们的基本观点是：如果服务提供商提供了更好更便宜的服务，那么就不值得自行管理 Kubernetes 集群。

• Kubernetes 集群由运行托管控制平面的主节点和运行工作负载的工作节点组成。
• 生产集群必须具有高可用性，也就是说即便主节点发生故障也不应该丢失数据或影响集群的运行。
• 简单的演示集群远不足以运行关键的生产工作负载。需要解决的问题很多，高可用性、安全性和节点管理只是其中的一部分。
• 管理自己的集群需要付出大量的时间、精力和专业知识投资。即便你做到了，也仍然有可能做错。
• Google Kubernetes Engine 等托管服务可以承担所有的繁重工作，而成本却远低于自托管。
• 一站式服务是自我托管与完全托管的 Kubernetes 之间的折中。你可以一面在自己的计算机上运行工作程序节点，一面利用一站式服务管理主节点。
• 如果必须托管自己的集群，那么 kops 是一款成熟且使用广泛的工具，可以利用它在 AWS 和 Google 云上配置和管理生产级集群。
• 尽可能使用托管的 Kubernetes。从成本、开销和质量的角度来看，这是大多数企业的最佳选择。
• 如果不能选择托管服务，则可以考虑使用一站式服务。
• 如果没有合理的业务原因，则不用自托管集群。如果你决定自托管，请不用低估初始设置和持续维护所需要付出的开销及时间。