K8s介绍（2）POD架构

K8s 中 Pod 的底层架构和容器组成：

整体架构分层（先看大结构）

这张图分为2 大区域：

• 左侧：Master Node（控制平面）​ —— 负责“发号施令”

• 右侧：Worker Node（工作节点）​ —— 负责“干活执行”

二、 左侧：Master Node（控制平面）组件

控制平面的核心是“让集群按期望运行”，所有指令都经过API Server。

📌控制流逻辑（箭头方向）：

1. 你用kubectl发请求 → 打到API Server​

2. API Server → 存到etcd（记录状态）

3. Controller-Manager​ 监听 API Server，发现“实际状态≠期望状态” → 调谐（比如重建 Pod）

4. Scheduler​ 监听 API Server，发现新 Pod 没调度 → 选一个 Worker Node → 通知 API Server

三、 右侧：Worker Node（工作节点）组件

工作节点的核心是“运行 Pod”，所有容器都在这里跑。

📌运行流逻辑（箭头方向）：

1. API Server 收到 Scheduler 的调度结果 → 通知对应 Worker Node 的kubelet​

2. kubelet​ → 调用docker​ → 拉镜像、启容器 → 形成pod（里面包含 container）

3. kube-proxy​ → 监听 API Server 的 Service 变化 → 写 iptables/IPVS 规则 → 让外部流量能访问到 Pod

四、 图的“细节亮点”（容易被忽略的点）

1. 红色框：pod和docker的关系

• 图中红色框内，pod是逻辑概念（K8s 的调度单位），docker是实际运行环境（容器运行时）。

• 一个pod里可以有多个 container（比如 pause + 业务容器 + init 容器），这些 container 都由docker启动。

2. 箭头双向性

• API Server和etcd之间是双向箭头：

  • API Server → etcd：写状态（比如创建 Pod）

  • etcd → API Server：读状态（比如查询 Pod）

• API Server和kubelet之间也是双向箭头：

  • API Server → kubelet：下发 Pod 配置

  • kubelet → API Server：汇报容器状态（Running、Failed 等）

3. 两个 Worker Node 的重复结构

• 图中画了两个 Worker Node，说明 K8s 是多节点集群，每个节点都有kubelet+kube-proxy+pod+docker。

五、 结合“创建 Pod”的流程（串联整张图）

我们拿“kubectl create -f pod.yaml”​ 来串一遍：

1. kubectl​ → 调用API Server（Master 节点）

2. API Server​ → 把 Pod 对象写入etcd（存状态）

3. Scheduler​ 监听 API Server → 发现新 Pod 没调度 → 选一个 Worker Node（比如 Worker 1） → 通知 API Server

4. API Server​ → 通知 Worker 1 的kubelet​

5. kubelet​ → 调用docker​ → 拉镜像、启容器 → 形成pod（里面有 container）

6. kubelet​ → 向 API Server 汇报：“Pod 已 Running”

7. kube-proxy​ → 监听 API Server，如果 Pod 被 Service 关联 → 写 iptables 规则 → 让外部能访问

一、Pod 内容器的类型（必须掌握）

✅Pod = 一组共享 Network / IPC / Volume 的容器集合

1️⃣ pause 容器（基础设施容器）

• 第一个启动

• 作用：

  • 创建Linux namespace（network / ipc / pid）

  • 为业务容器提供：

    • 共享网络栈（同一个 IP / localhost）

    • 共享存储卷

• 特点：

  • 不跑业务

  • 生命周期 = Pod 生命周期

📌一句话：

pause 容器是 Pod 的“地基”，所有容器都站在它上面。

2️⃣ init 容器（InitContainer）

• 在业务容器之前串行执行

• 作用：

  • 初始化环境

  • 等待依赖服务就绪

  • 拉配置、改权限、预检查

• 特点：

  • 必须全部成功退出（exit 0）

  • 任何一个失败 → Pod 重启 / 卡住

📌 常见场景：

• 等数据库 ready

• 下载配置文件

• 初始化数据库表

3️⃣ 业务容器（Container）

• 真正跑服务的

• 并行启动

• 受探针 & 重启策略管理

✅启动顺序总结（必考）

纯文本

纯文本

pause 容器 ↓ init 容器（串行） ↓ 业务容器（并行）

二、Pod 的三种类型（重点区分）

1️⃣ 自主式 Pod

• 直接kubectl run或 YAML 创建

• 挂了就挂了

• 不会被重建

📌面试坑：

自主式 Pod 不是“不能恢复”，而是没有控制器帮你恢复

2️⃣ 控制器管理的 Pod（最常用）

• Deployment / StatefulSet / DaemonSet / Job

• 保证副本数、版本、滚动更新

3️⃣ 静态 Pod

• 由kubelet 直接管理

• 文件路径：/etc/kubernetes/manifests

• 特点：

  • 不走 apiserver

  • 不调度

  • 常用于：

    • kube-apiserver

    • kube-controller-manager

    • kube-scheduler

📌面试高频：

静态 Pod 在kubectl get pods能看到，但删不掉（删了 kubelet 又拉起来）

三、ImagePullPolicy（镜像拉取策略）

📌生产规范：

• 非 latest 镜像 →IfNotPresent

• latest 镜像 →Always

• 离线环境 →Never

四、RestartPolicy（容器重启策略）

📌联系 Pod 类型：

• Deployment → 几乎都是Always

• Job / CronJob →OnFailure / Never

五、Harbor 镜像推送

bash

bash

docker tag nginx:latest 192.168.110.141/ruoyi/nginx:ruoyi-vue docker login -u admin -pHarbor12345 192.168.110.141 docker push 192.168.110.141/ruoyi/nginx:ruoyi-vue

📌K8s 使用：

yaml

yaml

image: 192.168.110.141/ruoyi/nginx:ruoyi-vue imagePullSecrets: - name: harbor-secret

六、Pod 资源限制（Requests / Limits）

yaml

yaml

resources: requests: cpu: 200m memory: 300Mi limits: cpu: 500m memory: 500Mi

📌核心概念：

• requests：调度依据（Node 是否有资源）

• limits：最大可用上限（OOM 杀手依据）

📌面试必说：

requests 决定能不能调度，limits 决定会不会被 kill

七、K8s 驱逐机制（Eviction）

1️⃣ 驱逐触发条件

• Node 资源不足：

  • memory.available

  • nodefs.available

  • imagefs.available

  • pid.available

📌硬阈值示例：

yaml

yaml

eviction-hard: memory.available < 100Mi

2️⃣ QoS 等级（决定谁先死）

✅驱逐优先级：

纯文本

纯文本

BestEffort → Burstable → Guaranteed

八、容器健康检查（三大探针）

1️⃣ 三种探针的区别（必背）

📌启动顺序：

纯文本

纯文本

startupProbe → livenessProbe + readinessProbe

2️⃣ 探测方式

📌MySQL 示例

bash

bash

mysql -uroot -pabc123 -e "show slave status\G" | grep -c "Yes"

九、一句话总结（面试收尾）

Pod 由一个 pause 容器提供基础环境，init 容器做初始化，业务容器跑服务；

Pod 由控制器管理可实现自愈，通过 requests / limits 限制资源，

依靠 startup / liveness / readiness 探针判断容器状态，

在资源不足时，K8s 根据 QoS 等级进行驱逐，保障集群稳定性。