k8s容器入门（6）Kubernetes的典型架构

Kubernetes（简称 K8s）的架构由 控制平面（Control Plane） 和 工作节点（Worker Nodes） 两大部分组成，各组件通过 API Server 协同工作，实现容器化应用的自动化部署、扩缩容和运维。以下是详细的组成和典型架构说明：

一、控制平面（Control Plane）

控制平面负责集群的全局决策（如调度、资源分配）、事件检测和响应，通常运行在 Master 节点上。

1. API Server

• 作用：
  • 提供 RESTful API 接口，是所有操作的入口（如 kubectl 命令、Helm 部署）。
  • 验证请求合法性（认证/鉴权），协调集群状态变更。
• 特点：
  • 无状态设计，仅处理请求而不持久化数据（依赖 etcd）。
  • 支持 Watcher 机制，实时推送状态变化给其他组件（如 Controller Manager、Scheduler）。

2. etcd

• 作用：
  • 分布式键值存储，保存集群的 全局状态信息（节点、Pod、配置、密钥等）。
  • 所有组件通过 API Server 读写 etcd 数据。
• 特性：
  • 高可用（基于 Raft 协议，建议至少 3 节点集群）。
  • 安全性：支持 TLS 加密通信和访问控制。
• 最佳实践：定期备份 etcd 数据，防止灾难性故障导致集群元数据丢失。

3. Controller Manager（控制器管理器）

• 作用：运行一系列控制器（Controller），确保集群的 实际状态 与用户定义的 期望状态 一致。
• 核心控制器：
  • ReplicaSet Controller：确保 Pod 副本数符合预期（如 Deployment 中定义的 replicas）。
  • Node Controller：监控节点健康状态，标记不可用节点并触发 Pod 重新调度。
  • Deployment Controller：管理滚动更新和回滚。
  • Service Account Controller：自动创建命名空间下的默认 ServiceAccount。
  • Persistent Volume Controller：管理存储卷生命周期（绑定 PVC 到 PV）。

4. Scheduler（调度器）

• 作用：
  • 将新创建的 Pod 分配到合适的 Worker Node 上运行。
  • 基于资源需求（CPU/内存）、亲和性策略（nodeAffinity）、污点容忍度（Taint/Toleration）等条件决策。
• 流程：
  1. 监听 API Server 新建的 Pod 请求。
  2. 过滤符合条件的节点（如资源充足）。
  3. 对候选节点打分，选择最优节点绑定 Pod。

5. Cloud Controller Manager（云控制器管理器）

• 作用：
  • 与云服务商（AWS/Azure/阿里云等）交互，管理负载均衡、存储卷等云资源。
  • 解耦 Kubernetes 核心代码与云厂商逻辑，支持灵活扩展。
• 常见功能：
  • 自动创建外部 LoadBalancer 类型的 Service。
  • 动态挂载云盘（如 AWS EBS）。

---

二、工作节点（Worker Nodes）

工作节点承载容器化应用，接受控制平面指令并执行具体任务。

1. Kubelet

• 作用：
  • 监听 API Server 的指令（如创建 Pod）。
  • 管理本机容器生命周期（调用容器运行时，如 containerd）。
  • 报告节点状态（CPU/内存使用率、Pod 状态）。
• 限制：
  • 仅能处理 API Server 发来的指令（不处理 DaemonSet 以外的 Pod 请求）。
  • 无法直接修改 Pod 状态（需通过 API Server 更新 etcd）。

2. Kube Proxy

• 作用：
  • 维护节点上的网络规则，实现 Service 的负载均衡与流量转发。
  • 确保跨节点 Pod 可互通，外部访问能路由到正确容器。
• 实现模式：
  • iptables/ipvs：传统模式，通过内核态规则转发流量。
  • eBPF（部分方案）：更高效的网络代理（如 Cilium）。

3. Container Runtime（容器运行时）

• 主流选择：
  • containerd：CNCF 项目，轻量级运行时，默认被 Docker 使用。
  • CRI-O：专为 Kubernetes 设计的轻量运行时，兼容 OCI 标准。
• 职责：
  • 拉取镜像、启动/停止容器。
  • 通过 CRI（Container Runtime Interface）与 Kubelet 通信。

4. Pod 网络插件（CNI）

• 作用：
  • 为 Pod 分配唯一 IP，实现 Pod 间直接通信。
  • 支持跨节点 Pod 网络互通。
• 常见插件：
  • Calico：基于 BGP 协议的高性能网络方案。
  • Flannel：简单易用的覆盖网络（Overlay Network）。
  • Cilium：基于 eBPF 的安全高效网络方案。

---

三、附加组件（Addons）

非核心组件，但常用于增强功能或提供默认能力。

1. CoreDNS

• 替代旧版 kube-dns，为集群内服务提供 DNS 解析（如 my-service.namespace 解析为 ClusterIP）。

2. Ingress Controller

• 作用：对外暴露 HTTP/HTTPS 服务，提供基于路径或域名的路由规则。
• 常见实现：Nginx Ingress Controller、Traefik、Istio Gateway。

3. Metrics Server

• 收集集群资源使用数据（CPU/内存），供 HPA（Horizontal Pod Autoscaler）进行自动扩缩容。

4. Dashboard（可选）

• 提供 Web UI 界面，可视化管理集群资源（需单独安装）。

---

四、典型架构示意图

[客户端] → kubectl / Helm / Operator → [API Server]
          ↘ Controller Mgr → etcd（存储集群状态）
          ↘ Scheduler → Node（调度 Pod）

[Worker Node]
├── Kubelet → 与 API Server 通信，管理容器
├── Kube Proxy → 网络规则（如 iptables/IPVS）
└── Container Runtime → 运行容器（containerd/CRI-O）
    └── Pod（包含多个容器）

---

五、关键设计原则

1. 声明式 API：用户定义“期望状态”（如 YAML 文件），系统自动同步实际状态。
2. 自愈能力：若 Pod 异常，Controller Manager 会自动重启或替换。
3. 松耦合架构：组件间通过 API 或消息队列通信，支持模块化替换（如替换 kube-dns 为 CoreDNS）。
4. 可扩展性：通过 CRD（自定义资源）和 Operator 模式支持第三方功能扩展。

---

六、高可用架构示例

生产环境中，控制平面组件通常以多副本部署：

• API Server：多实例 + 负载均衡（如 Nginx）。
• etcd：独立集群（3/5 节点），避免与 Master 节点混合部署。
• Controller Manager/Scheduler：多实例运行，通过 Leader Election 选举主节点。

---

如果需要更深入某个组件（如 etcd 备份恢复、kube-proxy 的 ipvs 实现原理），或特定场景（如边缘计算节点的优化），可以进一步提问！