K8s学习笔记：（01与02）辅助-核心架构-集群节点Pod关系

类型：辅助讲义（对应 第一章 Pod + 第二章 Deployment）
定位：讲透”归属关系”和”管理关系”两条主线，涵盖 Pod 到 Deployment 的底层原理
日期：2026年7月13日
前置：已完成第一章（环境搭建与 Pod 入门）

一、一句话总览

集群是一群机器，每台机器叫节点，Pod 跑在节点上，容器装在 Pod 里。

1
2
3
4
Cluster（集群）
  └── Node（节点 / 一台机器）
        └── Pod（K8s 最小调度单位）
              └── Container（容器 / 你的 nginx 进程）

二、关键：这里有”两条关系线”，别混

初学最容易把两件事搅在一起。K8s 里同时存在两套层级，交汇点都是 Pod：

关系线 层级 回答的问题
归属关系（物理） Cluster → Node → Pod → Container 谁装在谁里面？Pod 住在哪台机器？
管理关系（逻辑） Deployment → ReplicaSet → Pod 谁管谁？谁保证 Pod 数量对？ 
1
2
3
4
5
6
7
8
9
归属线（东西住在哪）                 管理线（谁负责管）

Cluster                             Deployment
  │                                    │
Node                                ReplicaSet
  │                                    │
Pod  ◄────────── 交汇点 ──────────►  Pod
  │
Container
  • 归属线：描述”物理上东西在哪”。Pod 必须落在某个 Node 上，Node 属于某个 Cluster。
  • 管理线：描述”谁来维持期望状态”。Deployment 说要 3 个 Pod，就通过 ReplicaSet 保证始终有 3 个。
  • 两条线在 Pod 这一层交汇：Pod 既是”被管理的对象”，也是”被调度到节点上的实体”。

下面第三～六节详解归属线，第七节详解管理线。

三、归属线逐层拆解

层级 是什么 类比 Kind 环境里对应
Cluster 一整套 K8s 系统 一个机房 k8s-lab 这整个
Node 一台干活的机器 机房里一台服务器 k8s-lab-control-plane 这个 Docker 容器
Pod 一个或多个容器的打包盒 一个工位 my-nginx-deploy-xxx-yyy
Container 真正运行的进程 工位上干活的人 盒子里的 nginx 进程

为什么要有 Pod 这一层（不直接是容器）？

Pod 是 K8s 的最小调度单位，不是容器。一个 Pod 可以装 1 个或多个容器，同一 Pod 内的容器：

  • 共享同一个网络（同一个 IP，互相 localhost 直连）
  • 共享存储卷
  • 永远被一起调度到同一个 Node、一起生死

多数场景一个 Pod 只放一个主容器；多容器 Pod 常见于”主容器 + 边车（sidecar）”模式（如日志收集、代理）。

四、Cluster 内部：两种角色的 Node

集群里的节点按职责分两类。你现在用 Kind 单节点，一个节点身兼两职。

1
2
3
4
5
6
7
8
9
10
11
12
13
Cluster（k8s-lab）
│
├── Control-Plane Node（大脑 / 做决策）
│     ├── kube-apiserver      ← 唯一入口，kubectl 只跟它说话
│     ├── etcd                ← 数据库，存"你想要什么"（期望状态）
│     ├── scheduler           ← 决定新 Pod 该放哪个 Node
│     └── controller-manager  ← 盯着"实际 = 期望"，不符就纠正
│
└── Worker Node（工人 / 真正跑 Pod，可多个）
      ├── kubelet             ← 节点上的工头，管 Pod 生死
      ├── containerd          ← 容器运行时，拉镜像、起容器
      └── Pod
            └── Container（nginx）
组件 住在哪种节点 职责
kube-apiserver Control-Plane 集群总入口，所有操作的必经之路
etcd Control-Plane 存储集群全部状态（期望+实际）
scheduler Control-Plane 调度：给 Pod 挑节点
controller-manager Control-Plane 控制循环：持续纠偏
kubelet 每个节点都有 在本节点执行 Pod 的启停
containerd 每个节点都有 真正运行容器的运行时

Kind 单节点：control-plane 节点上也跑了 kubelet + containerd，所以它既是大脑又干活，Pod 直接落在它身上。真实生产里大脑和工人分开（第七章 kubeadm 体验）。

五、完整包含关系图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌──────────────────────── Cluster: k8s-lab ────────────────────────┐
│                                                                   │
│   ┌───────────── Node: k8s-lab-control-plane ─────────────┐       │
│   │                                                        │       │
│   │   控制平面组件                                          │       │
│   │     apiserver   etcd   scheduler   controller-mgr      │       │
│   │                                                        │       │
│   │   节点组件                                              │       │
│   │     kubelet     containerd                             │       │
│   │                                                        │       │
│   │   ┌─────── Pod ───────┐      ┌─────── Pod ───────┐     │       │
│   │   │  Container        │      │  Container        │     │       │
│   │   │    nginx          │      │    nginx          │     │       │
│   │   └───────────────────┘      └───────────────────┘     │       │
│   │                                                        │       │
│   └────────────────────────────────────────────────────────┘       │
│                                                                   │
└───────────────────────────────────────────────────────────────────┘

多节点集群（第七章）会是这样，Pod 分散在多个 Worker 上：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
┌──────────────────────── Cluster ────────────────────────┐
│                                                          │
│   ┌── Control-Plane ──┐                                  │
│   │  apiserver        │   （只做决策，一般不跑业务 Pod）    │
│   │  etcd             │                                  │
│   │  scheduler        │                                  │
│   │  controller-mgr   │                                  │
│   └───────────────────┘                                  │
│                                                          │
│   ┌──── Worker 1 ─────┐        ┌──── Worker 2 ─────┐      │
│   │  kubelet          │        │  kubelet          │      │
│   │  containerd       │        │  containerd       │      │
│   │  ┌───── Pod ─────┐│        │  ┌───── Pod ─────┐│      │
│   │  │  nginx        ││        │  │  nginx        ││      │
│   │  └───────────────┘│        │  └───────────────┘│      │
│   └───────────────────┘        └───────────────────┘      │
│                                                          │
└──────────────────────────────────────────────────────────┘

六、Kind 环境的特殊性：Node 就是 Docker 容器

Kind = Kubernetes IN Docker。它把每个”节点”实现成宿主机上的一个 Docker 容器。

概念 真实集群 Kind 环境
Node 是什么 物理机 / 云主机 宿主机上的一个 Docker 容器
怎么”创建” Node 装好机器后 kubeadm join kind create cluster 自动起容器
大脑与工人 分离在不同机器 默认一个节点身兼两职
镜像仓库 节点各自的 containerd Kind 容器内独立的 containerd

关键认知：不是”Node 不用创建”，而是 kind create cluster 把”起节点容器”这步打包进”建集群”里自动做了。建完 docker ps 看到的 k8s-lab-control-plane 容器，就是你的 Node 实体。

Kind 里想要多节点，配置文件里加 nodes: 即可：

1
2
3
4
5
6
7
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: k8s-lab
nodes:
- role: control-plane
- role: worker
- role: worker

七、管理线详解：Deployment → ReplicaSet → Pod

前面讲的是”东西住在哪”（归属线）。这一节讲”谁负责维持状态”（管理线）——这是第二章的核心。

一句话

你只跟 Deployment 打交道，它建 ReplicaSet，ReplicaSet 建 Pod。

1
2
3
4
5
6
7
Deployment    你声明"要什么"：3 个副本、nginx:alpine 镜像
    │              （管版本、管更新、管回滚）
    ▼
ReplicaSet    保证"数量对"：盯着必须有 3 个 Pod，多退少补
    │              （只干一件事：维持副本数）
    ▼
Pod           真正运行的实体：里面跑 nginx 容器

各层职责（分工不重叠）

层级 唯一职责 你会用的操作
Deployment 管”版本”和”变更策略” set image 更新、rollout undo 回滚
ReplicaSet 管”副本数量” 一般不直接碰，自动干活
Pod 跑容器 logs、exec、describe 排查

看名字就懂层级

Pod 名字 my-nginx-deploy-6d8f7c9b5-x4k2p 直接编码了三层：

1
2
my-nginx-deploy - 6d8f7c9b5 - x4k2p
└── Deployment ┘ └─ RS哈希 ┘ └Pod哈希┘

同一个 ReplicaSet 建出的 Pod，中间那段哈希都一样，只有最后一段不同。

关键：为什么要 RS 这一层？两层不行吗？

ReplicaSet 存在，是为了滚动更新和回滚。 Deployment 每换一次镜像版本，就新建一个 ReplicaSet，旧的不删（缩到 0 保留），用于随时回滚：

1
2
3
4
5
6
7
8
9
10
11
12
13
更新前：
  Deployment
    └── RS-v1 (nginx:alpine)      ← replicas: 3   ✔ 当前

set image 更新到 alpine-perl 后：
  Deployment
    ├── RS-v1 (nginx:alpine)      ← replicas: 0   （留着备用）
    └── RS-v2 (nginx:alpine-perl) ← replicas: 3   ✔ 当前

rollout undo 回滚后：
  Deployment
    ├── RS-v1 (nginx:alpine)      ← replicas: 3   ✔ 切回来了
    └── RS-v2 (nginx:alpine-perl) ← replicas: 0

滚动更新的本质，就是 Deployment 让新 RS 一个个加 Pod、旧 RS 一个个减 Pod，保证总数不掉、服务不中断：

1
2
旧RS: 3 → 2 → 1 → 0
新RS: 0 → 1 → 2 → 3    （交替进行）

所以三层的意义：

  • Deployment 记得所有历史版本（每版一个 RS），负责”切换哪个版本上线”
  • ReplicaSet 只闷头保证自己那个版本有几个 Pod
  • 两层分工，才能实现”平滑换版 + 秒回滚”

与归属线的交汇

1
2
3
4
5
6
7
8
9
管理线（谁管谁）              归属线（住在哪）

Deployment                   Cluster
    │                           │
ReplicaSet                   Node
    │                           │
Pod  ◄──── 交汇 ────►         Pod
                                │
                             Container

Pod 是交汇点：被 RS 管着数量，同时被调度到某个 Node 上运行。

八、这套结构如何支撑”声明式”与”自愈”

理解了结构，K8s 最核心的两个特性就顺理成章了。

声明式：你说”要什么”，不说”怎么做”

1
你 → kubectl → apiserver → 把"要3个nginx"存进 etcd（期望状态）

你只声明目标，不手动一个个起容器。

自愈：控制循环持续纠偏

1
2
3
4
5
6
7
8
9
controller-manager 每时每刻在做：

   读期望状态（etcd：要3个）
        │
   比对实际状态（当前只有2个）
        │
   不一致 → 通知 scheduler 挑节点 → kubelet 起一个新 Pod
        │
   回到期望（3个）

所以第二章”删掉一个 Pod 立刻被补回”，本质就是：controller 发现”实际 2 ≠ 期望 3”，驱动 kubelet 在节点上补了一个。期望状态存在 control-plane，执行发生在 Node，被管理的是 Pod —— 三层各司其职。

九、常用查看命令（把抽象变具象）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 看集群信息（apiserver 地址等）
kubectl cluster-info

# 看有哪些 Node（机器层）
kubectl get nodes
kubectl get nodes -o wide         # 带 IP、系统、运行时版本

# 看某个 Node 的详情（容量、上面跑了哪些 Pod）
kubectl describe node <node-name>

# 看 Pod 住在哪个 Node 上（NODE 列）
kubectl get pods -o wide

# 看 Pod 里有几个容器、什么镜像
kubectl describe pod <pod-name>

# Kind 视角：Node 其实是 Docker 容器
docker ps | grep k8s-lab

十、小结（一图记牢）

1
2
3
4
5
6
7
8
9
谁装在谁里面（归属）          谁负责管谁（管理）

Cluster  一群机器             Deployment  声明要几个
   │                             │
Node     一台机器             ReplicaSet  保证有几个
   │                             │
Pod      调度单位   ◄── 交汇 ──►  Pod        被管+被调度
   │
Container 真正的进程
  • 一个 Cluster 含多个 Node；一个 Node 上跑多个 Pod；一个 Pod 装一个或多个 Container。
  • Control-Plane 是大脑（存期望、做决策），Worker 是工人（真正跑 Pod）。
  • Kind 里 Node = Docker 容器，建集群时自动创建。
  • 声明式 + 自愈，靠的就是”期望存 control-plane、执行在 Node、对象是 Pod”这套分工。
Kubernetes
#Kind #Pod #Deployment #ReplicaSet #K8s架构 #Cluster #Node #Container
K8s学习笔记：（01与02）辅助-核心架构-集群节点Pod关系
https://bote798.top/2026/07/14/K8s学习笔记-核心架构-集群节点Pod关系/
作者
bote798
发布于
2026年7月14日
更新于
2026年7月14日
许可协议