3.1 Pod：种子的最小包装
3.1 Pod：种子的最小包装
本节摘要：Pod 是 Kubernetes 调度与运行的最小单元，内部可含一个或多个共享网络地址与存储卷的容器。多个容器同盆的意义是"同生共死、同地共址"，典型如应用加日志边车。本节解剖 Pod 结构、给出第一份可直接运行的 Pod 清单、辨析单容器与多容器的取舍，并解释"为什么不是直接调度容器"。
从定义开始：Pod 是什么
先把定义立稳：Pod 是一组共享网络与存储的容器的打包单位，是集群调度、部署、扩缩的最小单元。名字来自鲸鱼群（a pod of whales）——一群鲸同行同止。落到农事框架：Pod 是种子的最小包装，包装里通常只有一粒种子（一个容器），偶尔装两三粒"必须挨着种"的种子（主容器加边车）。
为什么最小单元不是容器本身？因为容器彼此隔离得太彻底，连打个招呼都要走网络。而现实中确有一类组件天生要"贴着"主应用跑：给它刷日志的采集器、给它做代理的网格组件、给它解密配置的注入器。Kubernetes 的解法是把这几个容器装进同一个 Pod：共享同一个 IP、同一组端口空间、同一块临时卷，彼此用本地回环地址通信，像住进同一只花盆的两株苗，根须缠在一起。调度以 Pod 为单位，保证了这组容器永远落在同一节点、同生共死。
图：一只 Pod 的解剖面
第一份清单：裸种一粒种子
不借助任何高级农具，直接种一个 Pod 感受一下（日常并不推荐这么种，原因见下）：
# 单个 Pod 的种子袋，类型 kind 直接写 Pod apiVersion: v1 kind: Pod metadata: name: greenlib-web-manual # 给这粒种子起个名 labels: app: greenlib-web # 苗牌：第三章 3.3 与第四章都要用 spec: containers: - name: web image: greenlib/web:0.9.1 # 照哪张图纸造盆 ports: - containerPort: 8080 # 盆里留的取水口
kubectl apply -f pod-manual.yaml # pod/greenlib-web-manual created kubectl get pods -o wide # NAME READY STATUS RESTARTS AGE IP NODE # greenlib-web-manual 1/1 Running 0 30s 10.24.1.17 node-3 # 观察点：READY 一列写成 分子式，因为一个 Pod 可能装多个容器 kubectl delete pod greenlib-web-manual # pod "greenlib-web-manual" deleted # 删除后再 apply 同一份清单才会再有；没有人替你补种，这就是裸种 Pod 的宿命
最后一行注释是关键剧情：裸种的 Pod 死了就死了，园丁不会补。因为台账里只有"这一粒种子"的记录，没有"田里应有三株"的期望。要有人替你维护株数，就得把期望抬高一层——那是下一节 Deployment 的戏份。
一个 Pod 装几个容器
这是新手最容易纠结的问题，给一组可直接执行的判断：
| 场景 | 装法 | 理由 |
|---|---|---|
| 普通无状态服务 | 一 Pod 一容器 | 扩缩容以 Pod 为单位，多容器会一起被复制，浪费且耦合 |
| 应用加日志采集 | 应用加边车，共卷 | 采集器要读应用的日志文件，必须共址 |
| 应用加配置解密注入 | 应用加初始化容器 | 解密要在应用启动前完成，初始化容器先跑完才轮到主容器 |
| 前台与后台两个服务 | 各自独立 Pod | 生命周期与伸缩节奏不同，硬绑一起只会互相拖累 |
口诀化的版本：同生共死才同盆，仅是相邻不同盆。判断标准只有一个生命周期：一起生、一起死、必须挨着的，进同一个 Pod；只是业务上有来往的，老老实实分盆，靠第四章的 Service 互相找。
⚠️ 常见坑：把 Pod 当成"性能隔离单位"给不同业务用，一只 Pod 塞五六种角色。后果是任何一个角色崩了都可能连坐整只 Pod 重启，排查时日志混在一起。Pod 不是隔间柜，它是绑腿跑的小队。
Pod 的生命周期速览
Pod 从创建到消亡有一串状态值得认脸：Pending（已记账、等地或等图纸）、ContainerCreating（造盆中）、Running（活着，不代表健康）、CrashLoopBackOff（反复崩溃、退避重试）、Succeeded 或 Failed（终态，不重启）。第九章的排错手册会逐个细拆，这里先建立一个直觉：kubectl get pods 的 STATUS 列是苗情的第一现场，看到异常状态先别慌，每个状态都有明确的含义与去路。
💡 记一个反直觉事实：Pod 的 IP 在重建后会变，而且这是"特性"而非缺陷。系统有意让"株"廉价可弃，把"稳定"这件事上移给 Service。想通这一点，你就不会再执着于固定 Pod IP 的执念了。
Pod 状态速查表
苗情状态是排错的第一现场，先把高频状态列成速查表（第九章排错手册会逐个展开）：
| 状态 | 含义 | 第一反应 |
|---|---|---|
| Pending | 已记账，等地或等图纸 | 看 describe 的事件段 |
| ContainerCreating | 造盆中 | 稍等，或看镜像拉取进度 |
| Running | 进程在跑，不代表能接客 | 结合就绪探针判断 |
| CrashLoopBackOff | 反复崩溃，退避重试中 | 读前一世的日志 |
| ImagePullBackOff | 图纸拉不到 | 核对镜像名与仓库凭据 |
| Evicted | 被节点驱逐 | 看节点水位与资源限额 |
最后一条多说一句：驱逐是节点资源紧张时的自保动作——内存见底前，节点按第七章讲的服务等级顺序请苗让座，被请走的苗通常会在别的节点补上。看到 Evicted 别急着删，先看那块田是不是渴了。
一个冷知识：静态苗
每个节点上其实还长着几株"不走调度"的苗——许多集群把控制平面自身的组件以静态 Pod 的形式交给 kubelet 直接照看，不经调度器派地。它们是这片田的地基作物，describe 系统田时看到的 apiserver 之类的苗正是它们。动它们等于动承重墙，知道即可，别碰。
本节要点回顾
- Pod 是调度与生死的最小单位，容器只是 Pod 的成员
- 同盆容器共享网络地址与卷，用本地回环互通，永不分节点
- 装容器的判据是生命周期是否必须一致，不是业务上是否有来往
- 裸种 Pod 没人补苗，要维持株数需要把期望抬到 Deployment 一层
- Pod IP 生而短暂，稳定性的接力棒交给了第四章的 Service