Kubernetes组件
集群架构概述
Kubernetes采用分布式架构，整个系统由控制平面（Control Plane）和工作节点（Worker Nodes）两大部分组成。控制平面负责整个集群的管理和控制决策，工作节点负责实际运行容器化应用。
可以这样理解：如果把Kubernetes集群比作一个公司，控制平面就是公司的管理层，负责制定策略和决策；工作节点就是一线员工，负责执行具体的任务。管理层下达命令，员工执行任务并汇报结果。
控制平面组件
控制平面是Kubernetes的大脑，负责整个集群的管理和控制。它通常由多个组件组成，这些组件可以运行在同一个节点上（学习和小规模部署时），也可以分布在多个节点上（生产环境）。
API Server
API Server是Kubernetes控制平面的核心组件，提供RESTful API接口，是整个Kubernetes集群的统一入口。所有与Kubernetes集群的交互都通过API Server进行，无论是使用kubectl命令行工具，还是通过编程方式（client-go、fabric8等客户端库），或者是其他组件（如Scheduler、Controller Manager），都需要通过API Server的API来操作集群资源。
API Server的主要功能包括：
认证和授权：验证请求的身份（Authentication），并检查该身份是否有权限执行请求的操作（Authorization）。Kubernetes支持多种认证方式，包括X509证书、Bearer Token、Basic Auth等。
API注册和发现：Kubernetes的所有资源类型都通过API暴露，API Server负责维护这些API的注册和版本管理。
数据持久化：将集群的状态数据存储到etcd中，保证数据的持久化。
准入控制：在数据写入之前执行一些额外的检查或修改（通过Admission Webhook）。
API Server的设计是水平可扩展的，可以通过部署多个API Server实例来提高吞吐量。多个API Server之间通过负载均衡器来分发请求，但在数据层面需要保证一致性，这就是etcd的作用。
etcd
etcd是一个分布式键值存储系统，Kubernetes使用它来存储集群的所有状态数据。从某种意义上看，etcd就是Kubernetes的"数据库"，所有资源对象的状态都保存在这里。
etcd的特点：
强一致性：etcd使用Raft共识算法，保证在分布式环境下的强一致性。即使在集群出现网络分区的情况下，也能保证数据的一致性。
高可用：etcd通常以集群方式运行（生产环境建议3或5个节点），即使部分节点故障，只要集群可用的节点数超过半数，仍能正常提供服务。
高效：etcd被设计为非常高效的键值存储，能够处理大量的读写请求。
在Kubernetes集群中，etcd通常运行在控制平面节点上。对于大型生产环境，建议将etcd部署在专用的节点上，以保证性能和稳定性。
Scheduler
Scheduler负责容器的调度，即决定将新创建的Pod放到哪个节点上运行。这个"调度"过程看起来简单，实际上需要考虑很多因素：
资源需求：Pod请求的CPU、内存、存储等资源是否能在目标节点上满足。不能将一个需要4核CPU的Pod调度到只有2核可用CPU的节点上。
资源约束：Pod上定义的nodeSelector、nodeAffinity、podAffinity、podAntiAffinity、tolerations等调度约束条件。
资源平衡：尽量保持所有节点的资源使用率平衡，避免某些节点过载而其他节点空闲。
服务质量：尽量将同一应用的多个副本调度到不同节点，提高可用性。
Scheduler的调度过程分为两个阶段：
过滤阶段（Predicates）：筛选出所有满足Pod调度约束的节点。如果没有任何节点满足条件，Pod会一直处于Pending状态。
排序阶段（Priorities）：对满足条件的节点进行排序，选择"最优"的节点。排序时会考虑诸如节点资源使用率、亲和性等因素。
Controller Manager
Controller Manager是Kubernetes中各种控制器的集合。这些控制器是Kubernetes实现自动化管理的核心，它们不断监控集群的状态，并确保当前状态与期望状态一致。
主要的控制器包括：
ReplicaSet Controller：确保指定数量的Pod副本正在运行。如果某个Pod被意外删除或终止，会创建新的Pod来补充。
Deployment Controller：管理Deployment，handleDeployment的滚动更新和回滚。
Node Controller：监控节点状态，当节点出现故障时进行处理。
Service Controller：管理Service，创建和更新服务的端点（Endpoints）。
Endpoint Controller：管理Service和Pod之间的关联关系。
Namespace Controller：管理Namespace的生命周期。
PV Controller：管理PersistentVolume。
PVC Controller：管理PersistentVolumeClaim。
每个控制器都是独立运行的 goroutine，它们通过API Server监控资源的变化，并做出相应的调整。这种设计使得系统非常灵活，可以方便地添加新的控制器类型。
工作节点组件
工作节点是实际运行容器的地方。Kubernetes的每个工作节点上都会运行以下组件：
Kubelet
Kubelet是运行在每个节点上的agent，是节点与控制平面通信的桥梁。它需要确保容器按照Pod的规范运行。
Kubelet的主要职责包括：
与API Server通信：定期从API Server获取分配到本节点的Pod，并通过API Server汇报本节点和Pod的状态。
容器管理：根据Pod的规范，使用容器运行时（Docker、containerd等）创建和管理容器。
健康检查：执行Pod中定义的健康检查探针（livenessProbe、readinessProbe、startupProbe），根据检查结果采取相应行动。
资源监控：收集容器的资源使用情况，并报告给API Server。
日志收集：收集容器的标准输出和标准错误日志。
值得注意的是，Kubelet只管理通过Kubernetes API创建的容器。如果直接在节点上通过docker run等命令创建的容器，Kubelet不会管理它们。
Kube Proxy
Kube Proxy运行在每个节点上，负责为Service提供网络代理和负载均衡。它是实现Kubernetes Service功能的关键组件。
Kube Proxy有三种工作模式：
userspace模式：最早的模式，代理进程运行在用户空间。现在已经很少使用。
iptables模式（默认）：通过iptables规则实现代理和负载均衡。性能较好，配置简单。
ipvs模式：使用Linux内核的IPVS（IP Virtual Server）实现代理和负载均衡。支持更多的负载均衡算法，性能更高。
无论哪种模式，Kube Proxy的目标都是实现Service的负载均衡：将请求分发到后端的多个Pod上。同时，它还负责Service的域名解析（通过修改节点的DNS配置）。
Container Runtime
容器运行时是实际运行容器的组件。Kubernetes通过 CRI（Container Runtime Interface）接口与容器运行时交互，支持多种容器运行时：
Docker：最常用的容器运行时，Kubernetes早期版本默认使用。
containerd：从Docker中分离出来的容器运行时，Kubernetes 1.11+ 版本支持。
cri-o：轻量级的容器运行时，专为Kubernetes设计。
其他：通过CRI接口，还可以支持其他容器运行时，如Frakti（支持runV虚拟机）等。
Addons（插件）
Addons是扩展Kubernetes功能的组件，它们通常运行在kube-system命名空间中：
| 插件 | 功能 |
|---|---|
| CoreDNS | 集群群内部的DNS服务器，为Service提供域名解析 |
| Kubernetes Dashboard | Web UI管理界面 |
| Ingress Controller | HTTP/HTTPS路由，实现基于域名和路径的访问分发 |
| Prometheus | 监控系统，收集和存储指标数据 |
| Metrics Server | 资源指标收集，为HPA和kubectl top提供数据 |
| Network Policy | 网络策略，控制Pod之间的网络访问 |
这些插件使得Kubernetes的功能更加丰富，可以根据需要选择性安装。
值得注意的是，虽然控制平面组件主要运行在Master节点上，但在学习环境中，为了简化部署，通常会在所有节点（包括Master）上运行Kubelet和Kube Proxy，使得Master节点也可以运行Pod。