Kubernetes架构-原理-组件学习总结
Kubernetes（简称 K8s）是一款开源的容器编排平台，核心目标是实现容器化应用的自动化部署、扩展、故障恢复和运维管理。其设计遵循 “主从架构”（Control Plane + Node），组件分工明确，通过 “声明式 API” 和 “控制器模式” 实现集群状态的自动调谐。
一、Kubernetes 整体架构
K8s 集群由两部分组成：控制平面（Control Plane） 和工作节点（Node）。控制平面是集群的 “大脑”，负责决策；工作节点是 “手脚”，负责运行容器化应用。
| 角色 | 核心作用 | 部署建议 |
|---|---|---|
| 控制平面（CP） | 管理集群状态（如 Pod 调度、副本数量、故障恢复） | 生产环境需多节点高可用部署 |
| 工作节点（Node） | 运行容器化应用，执行控制平面下发的任务 | 数量根据业务负载扩展 |
二、核心组件
K8s 的功能依赖于多个组件的协同工作，组件分为 “控制平面组件” 和 “工作节点组件” 两类，部分组件还需依赖外部插件（如容器运行时、网络插件）。
1. 控制平面组件（Control Plane Components）
控制平面组件通常部署在专用的控制节点上，负责集群的 “决策与管理”。
| 组件名称 | 核心功能 | 关键特性 |
|---|---|---|
| kube-apiserver | 集群的 “统一入口”，所有操作（如创建 Pod、查询状态）都通过它执行 | - 唯一与 etcd 交互的组件（读写集群状态） - 提供 RESTful API，支持认证 / 授权 - 是组件间通信的 “中枢”（其他组件不直接交互，均通过 apiserver） |
| etcd | 分布式键值（Key-Value）数据库，存储集群的所有状态信息（如 Pod 配置、Service 规则） | - 强一致性（基于 Raft 协议），确保集群状态可靠 - 生产环境需 3/5 节点集群部署（高可用） - 仅 kube-apiserver 可直接读写 etcd |
| kube-scheduler | 负责将 “未调度的 Pod” 分配到合适的工作节点（Node） | - 调度依据：资源需求（CPU / 内存）、亲和性 / 反亲和性、污点 / 容忍、节点负载等 - 仅负责 “调度决策”，不执行 Pod 启动（由 kubelet 执行） |
| kube-controller-manager | 运行各类 “控制器”，监控集群状态，确保 “实际状态” 向 “期望状态” 对齐（调谐） | 内置核心控制器： - 副本控制器（ReplicaSet）：维持 Pod 副本数 - 节点控制器（NodeController）：监控节点健康 - 部署控制器（Deployment）：管理 Pod 升级 - 服务控制器（ServiceController）：关联 Pod 与 Service |
| cloud-controller-manager | （可选）对接云服务商 API（如 AWS、阿里云），实现云资源联动（如负载均衡、存储） | 仅在 “云环境” 中部署，物理机 / 私有集群无需此组件 |
2. 工作节点组件（Node Components）
每个工作节点（Node）都必须部署以下组件，负责 “执行控制平面的任务” 和 “管理本地容器”。
| 组件名称 | 核心功能 | 依赖关系 |
|---|---|---|
| kubelet | 监控本节点的 Pod，确保 Pod 内的容器正常运行（启动、重启、停止） | - 从 apiserver 获取 Pod 的 “期望状态”（如容器镜像、资源限制） - 调用 “容器运行时”（如 containerd）执行容器操作 - 定期向 apiserver 上报本节点和 Pod 的状态 |
| kube-proxy | 实现 K8s 的 “服务（Service）” 网络功能，维护节点的网络规则 | - 为 Service 分配 “虚拟 IP（ClusterIP）”，并将流量转发到后端 Pod - 支持两种模式： 1. iptables 模式（默认，轻量）：通过 iptables 规则实现转发 2. ipvs 模式（高性能）：适合大规模集群 - 确保 Pod 间、Pod 与外部的网络连通性 |
| 容器运行时（CRI） | 实际运行容器的软件，需符合 K8s 的 “容器运行时接口（CRI）” | 常用选项： - containerd（目前主流，Docker 已弃用直接支持，需通过 containerd） - CRI-O（专为 K8s 设计，轻量） - Docker（需额外安装 cri-dockerd 适配器，逐步淘汰） |
3. 必备插件（Add-ons）
部分核心功能需通过插件实现，控制平面和节点均需依赖：
网络插件（CNI）：实现 Pod 间跨节点通信（K8s 本身不提供网络功能），常用插件如 Calico、Flannel、Weave Net。
DNS 插件（CoreDNS）：为集群内的 Pod 和 Service 提供 DNS 解析（如通过 Service 名称访问 Pod），是集群默认组件。
存储插件（CSI）：对接持久化存储（如云硬盘、NAS），实现 Pod 存储持久化（容器存储默认临时，删除 Pod 后数据丢失），常用插件如 AWS EBS CSI、阿里云 CSI。
三、Kubernetes 核心工作原理
K8s 的核心逻辑是 “声明式调谐”：用户通过 API 声明 “期望的集群状态”（如 “部署 3 个 Nginx 副本”），K8s 自动将 “实际状态” 调整为 “期望状态”，无需用户手动操作。
1. 核心模式：声明式 API + 控制器模式
这是 K8s 与传统 “命令式工具”（如 Docker Compose）的本质区别：
声明式 API：用户只需定义 “最终要什么”（如
kubectl apply -f nginx-deploy.yaml），无需关心 “如何实现”；K8s 会记录这个 “期望状态” 到 etcd。控制器模式：每个控制器（如 Deployment 控制器）通过 apiserver “监听” 集群状态，对比 “期望状态” 和 “实际状态”：
若实际状态 ≠ 期望状态（如 Pod 副本数不足 3 个），控制器会触发 “调谐操作”（如创建新 Pod）；
若实际状态 = 期望状态，控制器则 “静默监控”，不做操作。
2. 典型工作流程：部署一个 Nginx 应用
以 “通过 Deployment 部署 3 个 Nginx 副本” 为例，理解 K8s 组件的协同逻辑：
用户提交请求：通过
kubectl apply -f nginx-deploy.yaml向 apiserver 发送 “创建 Deployment” 的请求，指定 “3 个副本”。apiserver 处理：验证请求合法性后，将 Deployment 的 “期望状态”（3 副本）存入 etcd，并返回 “创建成功” 给用户。
控制器调谐：Deployment 控制器通过 apiserver 监听 Deployment 资源，发现 “期望 3 副本” 但 “实际 0 副本”，于是自动创建一个 ReplicaSet（负责维护副本数），并将 ReplicaSet 的状态存入 etcd。
调度 Pod：ReplicaSet 控制器监听 ReplicaSet 资源，发现 “期望 3 副本”，向 apiserver 请求创建 3 个 Pod。kube-scheduler 监听 “未调度的 Pod”，根据节点资源、亲和性等规则，将 3 个 Pod 分别调度到 3 个不同的 Node 上，并将 Pod 的 “调度结果”（绑定到某个 Node）存入 etcd。
启动容器：每个 Node 上的 kubelet 通过 apiserver 监听 “分配给本节点的 Pod”，调用 containerd 拉取 Nginx 镜像，启动容器，并定期向 apiserver 上报 Pod 状态（如 “Running”）。
网络访问：用户创建 Service（
kubectl expose deployment nginx-deploy --port=80），kube-proxy 在每个 Node 上维护 iptables 规则，为 Service 分配 ClusterIP（如 10.96.0.10），并将访问 ClusterIP 的流量转发到 3 个 Nginx Pod，实现负载均衡。故障自愈：若其中一个 Nginx Pod 意外崩溃（状态变为 “CrashLoopBackOff”），ReplicaSet 控制器通过 apiserver 发现 “实际 2 副本 < 期望 3 副本”，立即请求创建 1 个新 Pod，kube-scheduler 重新调度，kubelet 启动新容器，最终恢复 3 副本状态。
3. 核心概念：Pod 与 Service 的关系
- Pod：K8s 的最小部署单元，一个 Pod 可包含 1 个或多个容器（如 “应用容器 + 日志收集容器”），容器间共享网络和存储。
❗ 注意：Pod 是 “临时的”，会因节点故障、调度更新等原因销毁重建，IP 地址会变化，无法直接作为固定访问入口。 - Service：为 “一组相同功能的 Pod” 提供固定访问入口（如 ClusterIP、NodePort），通过 “标签选择器”（Label Selector）关联 Pod。即使 Pod 销毁重建，Service 的 IP 和端口不变，确保外部访问不中断。
四、关键辅助概念
理解以下概念能更好地掌握 K8s 的使用场景：
Namespace：实现 “资源隔离”，将集群划分为多个虚拟子集群（如 “开发环境”“测试环境”“生产环境”），避免不同环境的资源冲突。
ConfigMap/Secret：管理应用配置：
ConfigMap：存储明文配置（如数据库地址、端口）；
Secret：存储敏感信息（如密码、Token），会进行 Base64 编码（非加密，需配合外部加密工具如 Vault 实现安全存储）。
Volume：解决 “容器存储临时化” 问题，将外部存储（如本地磁盘、云硬盘、NAS）挂载到 Pod 内，实现数据持久化（Pod 删除后数据不丢失）。
五、总结
K8s 的架构和原理围绕 “自动化、高可用、可扩展” 设计：
架构层面：控制平面决策，工作节点执行，组件间通过 apiserver 通信，etcd 保障状态可靠；
原理层面：通过 “声明式 API + 控制器模式” 实现自愈，无需人工干预；
核心价值：屏蔽容器底层的复杂性，让用户专注于应用本身，而非基础设施运维，支撑大规模容器集群的稳定运行。