本文主要是介绍Kubernetes 高可用性入门：初学者指南，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Kubernetes 高可用性解释
- 引言
- 一、需要 Kubernetes 高可用性
- 二、Kubernetes 控制平面的高可用性
- 2.1、etcd
- 2.2、API 服务器
- 2.3、Kube 调度器
- 2.4、Kube 控制器管理器
- 2.5、云控制器管理器
- 三、工作节点的高可用性
- 四、Kubernetes 集群可用性度量
- 五、Kubernetes 可用性常见问题
- 六、总结
引言
在本文中将研究 Kubernetes 的高可用性。以及研究每个 Kubernetes 组件的弹性和容错能力。
Kubernetes 高可用性对于确保应用程序始终可用至关重要。本文提供了 Kubernetes 高可用性的全面的初学者指南，涵盖了基本概念、组件和最佳实践。
文章首先介绍了高可用性的重要性，并概述了 Kubernetes 中实现高可用性的方法。然后，它深入探讨了 Kubernetes 的核心高可用性组件。
实现 Kubernetes 高可用性的最佳实践，例如：
- 使用多主控制平面： 避免单点故障。
- 部署高可用节点： 使用多个节点来运行工作负载。
- 使用自动 Pod 重新调度： 在节点故障时重新启动 Pod。
- 监控和告警： 主动监控集群并对问题发出警报。
一、需要 Kubernetes 高可用性
Kubernetes 是一个分布式系统，它容易受到多种故障的影响。对于公司来说，拥有高可用性的 Kubernetes 以提供良好的客户体验至关重要。在发生意外中断时，如果集群在一个或多个组件发生故障后仍无法继续运行，则停机可能会导致收入损失、声誉问题等。
通过在 Kubernetes 中实施 HA，可以降低停机风险，在集群上运行的应用程序和服务仍然可用且可供用户访问，并且系统可以在没有人为干预的情况下快速从故障中恢复。在较高级别上，这可以通过部署具有跨多个可用区或区域的网络拓扑的控制平面组件的多个副本来实现。
二、Kubernetes 控制平面的高可用性
Kubernetes 控制平面具有以下核心组件。
- API 服务器
- Kube 控制器管理器
- Kube 调度器
- 云控制器管理器（可选）
运行单节点控制平面可能会导致所有控制平面组件出现单点故障。要拥有高度可用的 Kubernetes 控制平面，应至少有三个仲裁控制平面节点，并在所有三个节点上复制控制平面组件。
现在，了解跨节点部署为多个副本时每个控制平面组件的性质非常重要。因为很少有组件在部署为多个副本时使用 leader-election。
一起看一下每个控制位置组件的高可用性。
2.1、etcd
说到etcd HA架构，有两种模式。
- 堆叠式 etcd：与控制平面节点一起部署的 etcd。
- 外部 etcd 集群：运行专用节点的 etcd 集群。此模型具有管理良好的备份和还原选项的优点。
要具有容错能力至少应该有三个节点 etcd 集群。etcd 集群的容错能力如下表所示。
| 集群大小 | 大多数 | 容错能力 |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
在生产部署方面，定期备份 etcd 至关重要。
2.2、API 服务器
API 服务器是一个无状态应用程序，主要与 etcd 集互以存储和检索数据。即API 服务器的多个实例可以跨不同的控制平面节点运行。
为确保集群 API 始终可用，应将负载均衡器放置在 API 服务器副本的前面。工作线程节点、最终用户和外部系统使用此负载均衡器端点与集群进行交互。
2.3、Kube 调度器
当运行多个 kube 调度程序实例时，它遵循 leader-election 方法。这是因为，schedler 组件涉及 pod 调度活动，并且一次只能有一个实例做出决策。因此，当运行调度程序的多个副本时，一个实例将被选为领导者，其他实例将被标记为跟随者。
这确保了始终有一个活动的计划程序，用于制定计划决策，并避免冲突和不一致。如果是领导者，则追随者将被选为领导者并接管所有日程安排决定。这样就拥有了一个具有一致调度的高可用性调度程序。
2.4、Kube 控制器管理器
Kuber 控制器管理器也遵循相同的领导者选举方法。在许多副本中，选出一个控制器管理器，领导者和其他人被标记为追随者。领导控制器负责控制集群的状态。
2.5、云控制器管理器
云控制器管理器 （CCM） 是一个 Kubernetes 组件，它运行与特定于云提供商的 API 交互的控制器，以管理负载均衡器、持久卷和路由等资源。
就像调度程序和 kube-controller 一样，CCM 也使用领导者选举来确保一次只有一个活动副本做出决策并与云提供商 API 交互。
三、工作节点的高可用性
要使工作器节点高可用性，需要运行应用程序所需的多个工作器节点。当存在 Pod 扩展活动或节点故障时，其他工作节点上应有足够的容量来安排 Pod。
在云平台上可以使用自动缩放来缩放工作器节点。因此，当存在扩展活动或资源需求时，工作节点可以扩展到所需的容量。
四、Kubernetes 集群可用性度量
假设没有计划内停机时间，Google SRE 手册中的下表显示了根据不同可用性级别计算允许的停机时间：
每个组织都有用于群集可用性的 SLO。如果使用的是管理服务，则服务提供商的 SLA 将与 SLO 保持一致。
- AWS EKS SLA
- GKE SLA
- Azure AKS SLA\
五、Kubernetes 可用性常见问题
（1）控制平面故障期间会发生什么？
即使发生控制平面故障，工作器节点上的现有工作负载也会继续为请求提供服务器服务。但是，如果出现节点故障，则不会发生 Pod 调度活动或任何类型的更新活动
（2）如果 Kubernetes 集群中的 DNS 服务失败，会发生什么情况？
如果 DNS 服务（如核心 DNS）发生故障，可能会对群集中运行的应用程序的可用性和功能产生重大影响。它可能会中断服务发现、外部访问、负载均衡、监视和日志记录以及滚动更新，从而导致应用程序故障、错误和中断。
六、总结
Kubernetes 高可用性对于确保应用程序始终可用至关重要。通过了解 Kubernetes 的核心高可用性组件和最佳实践，初学者可以构建高可用且弹性的 Kubernetes 集群。本文提供了 Kubernetes 高可用性的全面概述，是初学者入门并开始使用 Kubernetes 的宝贵资源。
这篇关于Kubernetes 高可用性入门：初学者指南的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
