k8s多节点集群架构图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
         +----------------------------------------------------------------+
         |                   Master 节点（控制平面）    	                  |
         |                                                                |
         |  +----------------+   +--------------+   +----------------+    |
         |  |  API Server    |<->| Scheduler    |<->| Controller Mgr |    |
         |  +----------------+   +--------------+   +----------------+    |
         |           |                                       |            |
         |           |                                       |            |
         |           v                                       v            |
         |      +--------------------+         +--------------------+     |
         |      |       etcd         |         |     监控等服务      |     |
         |      +--------------------+         +--------------------+     |
         +----------------------------------------------------------------+
                                     |
                                     | 控制、调度、状态同步
                                     v
+--------------------------+   +--------------------------+   +--------------------------+
| 🖥️ Node 1（工作节点）     |   | 🖥️ Node 2（工作节点）    |   | 🖥️ Node 3（工作节点）     |
| +----------------------+ |   | +----------------------+ |   | +----------------------+ |
| |       kubelet        | |   | |       kubelet        | |   | |       kubelet        | |
| |     kube-proxy       | |   | |     kube-proxy       | |   | |     kube-proxy       | |
| | containerd/Docker    | |   | | containerd/Docker    | |   | | containerd/Docker    | |
| | [Pod: App1, App2]    | |   | | [Pod: App3, CoreDNS] | |   | | [Pod: App4, AppX...] | |
| +----------------------+ |   | +----------------------+ |   | +----------------------+ |
+--------------------------+   +--------------------------+   +--------------------------+

动作下发流程示意

以部署一个新 Pod 为例

  1. 用户或系统发起请求
    • 通过 kubectl apply -f pod.yaml 提交创建 Pod 的请求。
  2. API Server 接收请求
    • API Server 校验请求合法性，将 Pod 资源写入 etcd，保存集群状态。
  3. Scheduler 调度 Pod
    • Scheduler 监听新 Pod 资源，选择一个合适的 Node 来运行该 Pod。（Scheduler 只“打标签”，不下发命令）
  4. 控制器管理器更新状态
    • Controller Manager 监控 Pod 状态，确保副本数和实际运行数一致。
  5. kubelet 接收指令
    • 被 Scheduler 选中的 Node 上的 kubelet 通过 API Server 获取 Pod 运行指令。
  6. kubelet 调用容器运行时
    • kubelet 调用 Docker 或其他容器运行时启动 Pod 中定义的容器。
  7. Pod 运行，kubelet 持续汇报状态
    • kubelet 持续向 API Server 汇报容器状态，API Server 更新 etcd，保证集群状态一致

类似于

  • API Server 是中枢大脑，接受命令，保存状态。
  • Scheduler 是派遣员，决定任务（Pod）去哪里执行。
  • Controller Manager 是监管者，确保状态符合预期。
  • kubelet 是执行官，拿到命令后具体去启动容器。

kube-proxy和containerd/Docker

kube-proxy

kube-proxy 本质上就是自动化管理节点上的「分布式防火墙 + 路由表」的工具

它不是传统意义上的防火墙，但它借用了 Linux 的防火墙技术（iptables / ipvs）来实现服务转发和负载均衡

举个例子

你访问了 10.96.0.10:80（某个 ClusterIP Service）

1
2
3
4
5
6
7
8
9
10
1. kube-proxy 已在本机通过 iptables 建了这样的规则：

   如果目标是 10.96.0.10:80，
   随机转发到：
     - 192.168.11.101:80 （Pod 1）
     - 192.168.11.102:80 （Pod 2）

2. 这就类似一个负载均衡 + NAT 转发行为。

3. 所有规则是 kube-proxy 自动维护的，不用人手动写 iptables。

但是，kube-proxy 不是用来做安全策略限制的防火墙

总结

职责 说明
🧭 服务发现路由（Service 转发） 把虚拟的 Service IP 请求，转发给真实 Pod 的 IP
🔁 负载均衡 在多个 Pod 之间做负载均衡：随机、轮询，具体由 iptables 或 ipvs 规则控制
🔗 节点网络配置 为 NodePort 类型 Service 开放端口并设置本地端口转发
🧲 监听 API Server 的 Service / Endpoints 变更 当 Pod 增加/减少时，自动更新转发规则

containerd/Docker

其实这个就是个docker，但是这只是早期版本才是，现在只需要containerd

谁是谁的下层？

  • 当你执行 docker run nginx，其实底层就是：
    • Docker CLI → Docker Engine → containerd → runc → 启动容器

containerd 作为后台运行容器的引擎

k8s使用容器运行时

运行时 是否兼容 Kubernetes 说明
Docker ❌（已废弃） 需要安装 dockershim 适配层，K8s 1.24 起已移除
containerd ✅（推荐） 与 Kubelet 直接通过 CRI 通信，轻量、稳定、性能好
CRI-O ✅（OpenShift 等常用） RedHat 主导，专为 Kubernetes 而生

版本变化

  1. 早期版本（K8s ≤ 1.23）：

    • kubelet 没有直接支持 containerd，而是通过一层叫 dockershim 的“适配器”让 Kubernetes 可以使用 Docker。
    • 所以你必须装 Docker。

  2. 后来（K8s ≥ 1.24）：

    • 官方移除了 dockershim。
    • Kubernetes 原生支持通过 CRI（Container Runtime Interface） 直接连接 containerd 或 CRI-O。
    • Docker 不再被官方支持作为 Kubernetes 的运行时。