Kubernetes - 实战：基本架构、工作机制简述、Master 组件、Node 组件

Kubernetes 基本架构

Kubernetes 架构主要包括两个核心部分：控制平面（Control Plane）和工作节点（Worker Nodes）。

控制平面（Master Components）

控制平面是 Kubernetes 集群的大脑，负责管理和协调集群中所有活动的部分。它通常部署在高可用的环境中，包括以下关键组件：

1. kube-apiserver：这是集群的主要入口点，处理所有的 RESTful API 请求，提供了资源操作的统一接口，并负责认证、授权和访问控制。

2. etcd：高度一致性的键值存储系统，用于存储集群的所有重要数据，包括集群的配置信息和状态信息。

3. kube-scheduler：负责调度新创建的 Pods 到适当的 Worker Node 上，基于预定义的调度策略和资源可用性。

4. kube-controller-manager：运行多个控制器进程，这些控制器负责执行集群级别的功能，比如副本集控制器（Replication Controller）保证指定数量的 Pod 正常运行，节点控制器（Node Controller）负责节点健康检查和节点脱离集群后的清理工作。

5. cloud-controller-manager（可选）：如果在云环境下部署，这个组件负责与底层云基础设施交互，管理云提供商特定的服务，如负载均衡器、存储卷等。

工作节点（Worker Nodes / Nodes）

每个工作节点都是 Kubernetes 集群中的一个实体机器（物理机或虚拟机），上面运行着以下组件：

1. kubelet：作为节点代理，kubelet 负责与控制平面通信，确保容器在节点上的正确运行。它监听来自 API server 的指令，管理 Pod 和容器的生命周期。

2. container runtime（如 Docker 或 containerd）：实际执行和管理容器的运行，kubelet 通过 CRI（Container Runtime Interface）与容器运行时进行交互。

3. kube-proxy：每个节点上的网络代理服务，实现 Kubernetes Service 的负载均衡和服务发现功能。

4. runtime plugins（如 CSI、CNI）：分别用于支持持久化存储卷挂载（Container Storage Interface, CSI）和容器网络插件（Container Network Interface, CNI），使得 Kubernetes 能够对接不同的存储和网络解决方案。

工作机制简述

1. 当用户通过 kubectl 向 Kubernetes API 发出创建资源（如 Deployment 或 StatefulSet）的请求时，请求首先到达 kube-apiserver。

2. kube-scheduler 根据集群资源状况，决定将新 Pod 分配到哪个节点上，并将调度决策写入 etcd。

3. kubelet 通过监听 API server 更新，在节点上创建对应的 Pod 及其容器，并通过 container runtime 来启动容器。

4. kube-proxy 依据 Service 的定义动态配置网络规则，使得服务能够被集群内部其他 Pod 访问，并可能实现外部流量的负载均衡。

5. 控制器组件持续监控集群状态，并采取行动确保实际状态与期望状态保持一致，比如当 Pod 意外终止时，副本集控制器会重新调度新的 Pod 来替代。

综上所述，Kubernetes 的各组件协同工作，共同实现了容器集群的自动化部署、管理和运维。