k8s基础

主要功能

• 自我修复：k8s可以监控容器的运行状况，并在发现容器出现异常时自动重启故障实例
• 弹性伸缩：k8s可以根据资源的使用情况自动地调整容器的副本数。例如，在高峰时段，k8s可以自动增加容器的副本数以应对更多的流量；而在低峰时段，k8s可以减少应用的副本数，节省资源
• 资源限额：k8s允许指定每个容器所需的CPU和内存资源，能够更好的管理容器的资源使用量；
• 滚动升级：k8s可以在不中断服务的情况下滚动升级应用版本，确保在整个过程中仍有足够的实例在提供服务
• 负载均衡：k8s可以根据应用的负载情况自动分配流量，确保各个实例之间的负载均衡，避免某些实例过载导致的性能下降
• 服务发现：k8s可以自动发现应用的实例，并为它们分配一个统一的访问地址。这样，用户只需要知道这个统一的地址，就可以访问到应用的任意实例，而无需关心具体的实例信息；
• 存储管理：k8s可以自动管理应用的存储资源，为应用提供持久化的数据存储。这样，在应用实例发生变化时，用户数据仍能保持一致，确保数据的持久性
• 密钥与配置管理：Kubernetes 允许你存储和管理敏感信息，例如：密码、令牌、证书、ssh密钥等信息进行统一管理，并共享给多个容器复用

集群类型

类型	适用范围
一主多从集群	由一台Master管理节点和多台Node工作节点组成，生产环境下Master节点存在单点故障的风险，适合学习和测试环境使用
多主多从集群	由多台Master管理节点和多Node工作节点组成，安全性高，适合生产环境使用

集群角色

• k8s集群需要建⽴在多个节点上，将多个节点组建成一个集群，然后进⾏统⼀管理

节点	角色
管理节点(master)	负责集群的所有管理工作
⼯作节点(node)	负责运行集群中所有用户的容器应用

master节点组件

组件	描述
API Server	为集群的管理入口，处理外部和内部通信，接收用户请求并处理集群内部组件之间的通信
Scheduler	作为集群资源调度计算，根据调度策略，负责将待部署的 Pods 分配到合适的 Node 节点上
Controller Manager	管理集群中的各种控制器，例如 Deployment、ReplicaSet、DaemonSet等，管理集群中的各种资源
etcd	作为集群的数据存储，保存集群的配置信息和状态信息

node节点组件

组件	描述
Kubelet	负责与 Master 节点通信，并根据 Master 节点的调度决策来创建、更新和删除 Pod，同时维护 Node 节点上的容器状态
容器运行时（如 Docker、containerd）等	负责运行和管理容器，提供容器生命周期管理功能。例如：创建、更新、删除容器等
Kube-proxy	负责为集群内的服务实现网络代理和负载均衡，确保服务的访问性

问：k8s中master节点为什么必须是奇数台？
答：K8s 中 Master 节点必须是奇数台(在讨论“奇数台”时，通常特指 etcd 集群)，其根本原因是为了保证在节点故障时，分布式的共识算法能够正常、无歧义地选举出一个领导者，从而保持集群的决策能力

核心原理：Raft 共识算法与“多数派”

　- Kubernetes 的核心控制组件（如 kube-apiserver、kube-scheduler、kube-controller-manager）为了高可用，会以多副本方式部署。其中，保存集群所有关键状态（如 Pod、Service、ConfigMap 等资源对象）的 etcd 集群，是实现高可用和一致性的基石。etcd 使用 Raft 这样的共识算法来确保多个节点间的数据强一致性。Raft 算法的核心运作机制依赖于 “多数派” 原则

1. 领导者选举和决策：集群中任何时候只能有一个领导者节点来负责处理写请求和决策。所有决定（如写入数据）都需要得到集群中超过半数节点的同意才能生效。这个“超过半数”的群体就叫做“多数派”。
2. 故障容错：当发生网络分区或节点宕机时，Raft 算法允许集群在仍有“多数派”节点存活的情况下继续工作。

奇数的关键性就在这里体现：

• 假设有 3 个节点 (N=3)：
  半数就是 1.5，所以“多数派”需要至少 2 个节点同意。
  集群可以容忍的故障节点数是 1 （因为 3-1=2，剩余的 2 个节点仍能构成多数派）。
  容忍故障数： (N-1)/2 = 1
• 假设有 4 个节点 (N=4)：
  半数就是 2，所以“多数派”需要至少 3 个节点同意。
  集群可以容忍的故障节点数仍然是 1 （因为 4-1=3，剩余的 3 个节点能构成多数派；如果坏 2 个，剩下 2 个，无法达到 3 票，集群会挂）。
  容忍故障数： (N-1)/2 = 1.5，向下取整为 1。
  对比一下：
  3 节点集群：容忍 1 个故障，需要 2 个节点存活。
  4 节点集群：同样只容忍 1 个故障，却需要 3 个节点存活。

结论分析
相同的容错能力，更高的成本：4 节点集群相比 3 节点集群，并没有提高容错能力（都只能坏 1 台），但需要更多机器和网络通信开销。
更高的写请求延迟风险：因为需要获得 3 票而不是 2 票，在节点间网络延迟不稳定的情况下，写操作达成一致的延迟可能更高。
防止“脑裂”：在网络分区的情况下，奇数节点能更明确地确保只有一个分区能形成“多数派”，从而避免出现两个领导者同时工作的“脑裂”场景。偶数节点在特定分区下（例如 4 个节点分成 2-2）可能导致两个分区都无法形成多数派，整个集群会不可用。
因此，选择奇数台 Master（尤其是 etcd 节点）是在容错能力和系统效率之间取得的最佳平衡。你获得了最大化的故障容忍度（每增加2台才能多容忍1台故障），同时避免了偶数节点带来的潜在风险和资源浪费。

生产环境常见部署方案

节点数量	容错能力(可宕机数）	说明
1	0	单点，无高可用。仅用于测试。
3	1	生产环境最常见、最推荐的方案。平衡了可靠性与成本。
5	2	用于对可用性要求极高的大型关键集群。能同时容忍 2 个节点故障，但通信和协调开销更大。
7	3	非常罕见，通常只在超大规模或特殊需求的场景下使用。复杂度很高。

总结：Kubernetes Master 节点（核心是 etcd）采用奇数台部署，是分布式系统共识算法的内在要求。它确保了在节点故障时，集群仍能拥有明确的多数派来做出决策，在提供最佳容错能力的同时，避免了资源浪费和“脑裂”风险。对于绝大多数生产环境，3 节点 Master 集群是最佳实践。