Kubernetes Pod 深度理解：从入门到实战

在 Kubernetes 集群中，Pod 是最小、也是最基础的管理单元。它不是一个容器，而是一个或多个容器的组合。Kubernetes 之所以选择 Pod 而非直接管理单个容器，是因为现实中的复杂应用往往由多个紧密耦合的进程组成------它们需要共享存储、网络、进程空间，或者存在强烈的生命周期依赖关系。Pod 作为这些容器的"逻辑主机"，屏蔽了底层容器运行时（Docker、containerd、CRI-O 等）的差异，让用户能够以声明式的方式编排应用。

本文将带你系统性地掌握 Pod 的方方面面：从基础概念到常用命令，从 YAML 编写到探针配置，从启动流程到故障排查，最后还会补充一批生产环境必备的高级知识点。全文包含 40+ 可直接运行的代码示例，适合作为博客收藏或手边查询手册。

一、Pod 核心概念解析

1.1 什么是 Pod？

Pod = 一组共享资源（网络、存储、IPC、PID）的容器集合 。

在 Pod 内部，所有容器共享同一个 Pause 容器（也叫基础设施容器）。Pause 容器负责：

接管 Pod 内的僵尸进程（init 进程的角色）
持有网络命名空间，让其他容器通过 localhost 互相通信
作为存储卷的生命周期锚点

可以把 Pod 想象成一台"微型虚拟机"，而里面的容器就像是这台机器上运行的多个进程。

1.1Pod 是什么？用"豆荚"理解

Pod 是 Kubernetes 里最小的部署单元 。

想象一个"豆荚"（英文 Pod 的本意）：外面是一层皮，里面可以放 1 颗豆子，也可以放多颗豆子。

单容器 Pod：豆荚里只有 1 个容器。最常见。
多容器 Pod ：豆荚里有 2 个或更多容器。这些容器紧密协作，比如一个写日志，一个跑主程序。

关键特性：一个 Pod 里的所有容器：

共享同一个 IP 地址 和 端口空间（可以用 localhost 互相访问）
共享同一个 存储卷（可以互相读写文件）
共享同一个 生命周期（一起创建，一起销毁）

例子：一个 Pod 里跑着 nginx 容器（处理 Web 请求）和 sidecar 容器（自动把 nginx 日志上传到中心）。它们用 localhost 通信，一起启动，一起停止。

1.2 Pod 的两大核心特征

特征	说明
网络	每个 Pod 拥有一个唯一的集群内 IP，内部容器共享该 IP 和端口空间，可通过 `localhost:端口` 互访
存储	可定义多个共享卷（Volume），Pod 内所有容器都能读写同一份数据，容器重启不影响共享卷内容

1.3Pod 里面不只有你的容器 ------ 还有"pause"容器（父进程）

每个 Pod 实际上有一个隐藏的、永远运行的容器 ，只负责"占位"和资源回收,叫 pause。

它是 Pod 里的 PID 1 进程（父进程），作用：

创建并持有 Pod 的网络命名空间（IP、端口等）。你的业务容器"加入"这个空间，而不是自己创建。
回收僵尸进程（如果你的容器里产生了孤儿进程，pause 会帮它们收尸）。
保证 Pod 的身份不变：即使你的业务容器挂了重启，Pod 的 IP 不会变（因为 pause 没挂）。

验证方法 ：在 K8s 节点上执行 crictl ps | grep pause，你会看到类似 k8s.gcr.io/pause:3.6 的容器。

例子：你执行 kubectl get pod my-pod -o wide 看到 IP 10.244.1.5。这个 IP 其实是 pause 容器的 IP，你的 nginx 容器共享它。

二、Pod 的状态全览（Phase）

Pod 的生命周期由 status.phase 字段定义，下表列出了所有可能的状态及其触发条件：

状态	含义与排查方向
Pending	Pod 已被 K8s 接收，但调度未完成或镜像下载中 → `kubectl describe` 查看调度/镜像问题
Running	Pod 已绑定到节点，至少一个容器在运行（注意：运行不代表业务就绪）
Succeeded	所有容器正常退出（退出码 0），且不会再重启，多见于 Job/CronJob
Failed	所有容器均已终止，且至少一个以非零码退出 → 检查 command、启动命令、环境变量
Unknown	通常由于节点失联或 kubelet 无法上报状态 → 检查节点网络和 kubelet 健康状态
ImagePullBackOff	镜像拉取失败，进入退避等待 → 检查镜像名是否存在、私有仓库鉴权、网络连通性
CrashLoopBackOff	容器启动后立即崩溃，kubelet 反复重启 → 查看日志 `kubectl logs --previous`，定位应用启动错误
OOMKilled	内存超限被系统杀死 → 调大 memory limit 或排查内存泄漏
Terminating	Pod 正在被删除，优雅退出过程中 → 若长时间卡住可强制删除 `--force --grace-period=0`
ContainerCreating	容器正在创建，通常拉镜像或挂载卷耗时 → 检查节点磁盘、CNI 插件、PVC 绑定状态
Completed	容器主进程执行完毕退出（非崩溃），常见于一次性任务或 initContainer
SysctlForbidden	Pod 自定义了内核参数但未被 kubelet 允许 → 需要在节点上放开 `--allowed-unsafe-sysctls`

三、Pod 常用命令大全（附详细示例）

以下命令涵盖从创建、查看、调试到删除的全流程，均在 default 命名空间下演示。

3.1 创建与基础查看

复制代码

# 直接运行一个 nginx Pod
kubectl run nginx --image=nginx:1.7.9 --labels="app=nginx"

# 查看 Pod 列表（简略）
kubectl get pods

# 查看 Pod 列表（含 IP、节点、运行时长）
kubectl get pods -o wide

# 查看 Pod 的 Yaml 格式完整定义
kubectl get pod nginx -o yaml

# 查看 Pod 的详细事件（最常用的调试命令）
kubectl describe pod nginx

3.2 日志与调试

复制代码

# 查看 Pod 的标准输出日志
kubectl logs nginx

# 查看上一次崩溃的容器日志（CrashLoopBackOff 时必用）
kubectl logs nginx --previous

# 多容器 Pod 中查看指定容器的日志
kubectl logs nginx -c nginx

# 在容器内执行一次命令（不进入交互）
kubectl exec nginx -c nginx -- date

# 进入容器交互式 shell（若容器有 bash）
kubectl exec -it nginx -c nginx -- bash

# 在线编辑运行中 Pod 的 spec（注意：除部分字段外，大部分不可直接修改）
kubectl edit pod nginx

3.3 端口转发与文件拷贝

复制代码

# 将本地 8080 转发到 Pod 的 80 端口（前台运行）
kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80

# 在另一终端测试转发结果
curl 192.168.10.101:8080

# 从 Pod 内拷贝文件到宿主机
kubectl cp nginx:/etc/fstab /opt/aaa.txt

# 从宿主机拷贝文件到 Pod
kubectl cp /opt/aaa.txt nginx:/etc/bbb.txt

3.4 删除 Pod

复制代码

# 按名称删除
kubectl delete pod nginx

# 按 YAML 文件删除
kubectl delete -f nginx-pod.yaml

# 强制立即删除（跳过优雅终止）
kubectl delete pod nginx --force --grace-period=0

3.5 资源类型帮助

复制代码

# 查看 Pod 资源的一级字段说明
kubectl explain pod

# 查看 spec 下可配置的子字段
kubectl explain pod.spec

# 查看 containers 字段的详细结构
kubectl explain pod.spec.containers

# 同样适用于 Deployment、Service 等
kubectl explain deployment
kubectl explain service

四、Pod YAML 清单深度拆解

4.1 最简 Pod 示例

复制代码

vim   nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
    ports:
    - containerPort: 80

4.2 复杂 Pod 示例（含探针、多容器、重启策略）

复制代码

vim   frontend-localredis-pod.yaml


apiVersion: v1
kind: Pod
metadata:
  name: redis-php
  labels:
    name: redis-php
spec:
  restartPolicy: OnFailure   # 重启策略：仅失败时重启
  containers:
  - name: frontend
    image: kubeguide/guestbook-php-frontend:localredis
    imagePullPolicy: IfNotPresent
    livenessProbe:            # 存活探针
      tcpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
    ports:
    - containerPort: 80
  - name: redis
    image: kubeguide/redis-master
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379

4.3 YAML 一级属性说明

字段	类型	必填	说明
apiVersion	string	是	K8s API 版本，如 v1
kind	string	是	资源类型，如 Pod、Deployment、Service
metadata	object	是	元数据，包含 name、namespace、labels、annotations 等
spec	object	是	期望状态，定义了容器、卷、探针、调度等细节
status	object	否	当前状态，由 K8s 自动填充，用户无需提供

4.4 spec 常用子字段

字段	说明
`containers`	容器列表，必须至少有一个
`initContainers`	初始化容器，在主容器启动前按顺序执行完毕
`nodeName`	强制调度到指定节点名
`nodeSelector`	通过标签选择节点
`affinity`	更灵活的亲和性/反亲和性规则
`tolerations`	容忍节点污点
`volumes`	声明卷（需在容器内 volumeMounts 挂载）
`restartPolicy`	Always / OnFailure / Never
`hostNetwork`	是否使用宿主机网络（默认 false）
`dnsPolicy`	DNS 策略（ClusterFirst / Default / None）
`serviceAccountName`	绑定的服务账号，用于访问 API Server

4.5 创建与验证

复制代码

# 创建 Pod   （创建可以使用create还可以使用apply）
kubectl create -f nginx-pod.yaml
kubectl create -f frontend-localredis-pod.yaml



命令式 (create): 直来直去，像一个硬性指令，"我要创建一个Pod"。

声明式 (apply): 则更像一个期望声明，"我希望集群最终是这样的状态"。如果资源已存在，它会做增量更新，以保证集群状态与你的配置一致





# 查看状态
kubectl get pods
# 输出示例：
# NAME        READY   STATUS    RESTARTS   AGE
# nginx       1/1     Running   0          5s
# redis-php   2/2     Running   0          31s

五、Pod 探针（Probe）全解

探针是 Kubelet 对容器定期执行的诊断操作，共三种类型。

5.1 三种检测方式

实现方式	描述
ExecAction	容器内执行命令，返回码 0 表示成功
TCPSocketAction	尝试连接容器指定端口，能打开则成功
HTTPGetAction	发起 HTTP GET 请求，状态码 200~399 表示成功

5.2 三种探针类型

探针类型	作用	失败后的行为
livenessProbe	判断容器是否存活（死锁、无响应）	重启容器
readinessProbe	判断容器是否就绪（依赖服务已启动、预热完成）	从 Service 的 Endpoints 中移除，不重启容器
startupProbe	针对启动慢的容器，在它成功之前禁用 livenessProbe 和 readinessProbe	超过 failureThreshold 后重启容器

5.3 探针共有参数

参数	默认值	说明
`initialDelaySeconds`	0	容器启动后多久开始第一次探测
`periodSeconds`	10	探测频率
`timeoutSeconds`	1	探测超时时间
`successThreshold`	1	失败后需要连续成功几次才恢复为成功状态
`failureThreshold`	3	连续失败几次才判定为真正失败（重启或摘除流量）

5.4 探针配置示例

复制代码

vim Custom-Header.yaml

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: Awesome
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 2
  failureThreshold: 3

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/ready
  initialDelaySeconds: 5
  periodSeconds: 5

startupProbe:
  tcpSocket:
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

生产最佳实践 ：对于启动时间超过 30 秒的应用，务必配置 startupProbe，避免 livenessProbe 在启动阶段误杀容器。

六、镜像拉取策略（imagePullPolicy）

策略	行为	适用场景
Always	每次创建 Pod 都尝试拉取	镜像标签为 `latest` 或需要实时同步
Never	从不拉取，只使用本地镜像，若不存在则失败	完全信任节点本地镜像库
IfNotPresent	仅当本地不存在时才拉取（K8s 默认策略，但若 tag 为 `latest` 则自动变为 Always）	生产环境固定版本号

指定方式：

yaml

复制代码

containers:
- name: app
  image: myregistry/app:v1.2.3
  imagePullPolicy: IfNotPresent

私有仓库鉴权（imagePullSecrets）：

bash

复制代码

# 先创建 docker-registry 类型的 secret
kubectl create secret docker-registry mysecret \
  --docker-server=https://myregistry.com \
  --docker-username=admin \
  --docker-password=pass

# 在 Pod 中引用
spec:
  imagePullSecrets:
  - name: mysecret
  containers: ...

七、Pod 重启策略（restartPolicy）

策略	触发条件	典型用例
Always	任何退出（无论退出码）都重启	常驻服务（Web、数据库）
OnFailure	仅非正常退出（非 0 码）才重启	批处理任务、定时任务
Never	从不重启	一次性任务，或手动清理的 Pod

bash

复制代码

# 通过命令行设置重启策略（run 命令）
kubectl run nginx --image=nginx:1.7.9 --restart=OnFailure

# 在 YAML 中设置
spec:
  restartPolicy: OnFailure

注意：restartPolicy 作用于 Pod 内的所有容器，且受限于 kubelet 的重启退避机制（指数延迟，最大 5 分钟）。

八、多容器 Pod 设计模式

8.1 示例：Nginx + PHP-FPM 共享 localhost

yaml

复制代码

# nginx-php.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-php
  labels:
    name: nginx-php
spec:
  containers:
  - name: nginx-app
    image: nginx:1.7.9
    ports:
    - containerPort: 80
  - name: php-app
    image: bitnami/php-fpm
    imagePullPolicy: Never   # 假设本地已构建
    ports:
    - containerPort: 9000

部署并暴露：

bash

复制代码

kubectl apply -f nginx-php.yaml
kubectl expose pod nginx-php --port=8080 --target-port=80 --type=NodePort --name=nginx-php
kubectl get pod,svc nginx-php -o wide
# 访问测试（端口随机，如 32598）
curl http://192.168.10.101:32598/

8.2 常见的多容器模式

模式	说明	示例
Sidecar	为主容器提供辅助功能（日志收集、代理、监控）	Fluentd 收集应用日志、Istio 代理
Ambassador	代理外部服务，屏蔽连接细节	将本地 localhost:6379 转发到远程 Redis 集群
Adapter	将主容器的指标或日志转换为外部系统要求的格式	将应用普通日志转换为 Prometheus 指标
Init Container	在主容器启动前完成准备工作（等待依赖、初始化数据库等）	等待数据库就绪、生成配置文件、修改权限

九、静态 Pod（Static Pod）

静态 Pod 由节点上的 kubelet 直接管理，无需 API Server 参与。它们不受 ReplicaSet、Deployment 等控制器的管理，也不能通过 kubectl delete 真正删除（会被 kubelet 重建）。

9.1 创建静态 Pod

bash

复制代码

# 在 kubelet 配置的清单目录中（通常是 /etc/kubernetes/manifests/）创建 YAML
cat <<EOF > /etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    name: static-web
spec:
  containers:
  - name: static-web
    image: nginx:1.7.9
    ports:
    - containerPort: 80
EOF

等待约 20 秒，kubelet 自动创建 Pod：

bash

复制代码

kubectl get pods
# 输出类似： static-web-k8s-master01   1/1   Running   0   20s

9.2 删除静态 Pod

bash

复制代码

# 正确方式：删除清单文件
rm -f /etc/kubernetes/manifests/static-web.yaml

# 错误方式（会进入 Pending 状态，无法删除）
kubectl delete pod static-web-k8s-master01

静态 Pod 常用于部署核心组件，如 kube-apiserver、kube-controller-manager 等。

十、Pod 启动过程（10 步详解）

提交定义 ：用户通过 kubectl 或 API 提交 YAML。
API Server 接收：认证、授权、准入控制（Admission Controllers）处理，写入 etcd。
Scheduler 监听 ：发现 status.phase 为 Pending 且未绑定节点的新 Pod。
调度决策：基于资源需求、节点亲和性、污点容忍等，选出最优节点。
绑定：Scheduler 将 Pod 与节点信息更新到 etcd。
kubelet 感知：节点上的 kubelet 通过 watch 机制拿到新 Pod。
创建容器：kubelet 调用 CRI（containerd、CRI-O）创建 Pause 容器和业务容器。
网络与存储：调用 CNI 分配 IP，CSI 挂载 PersistentVolume。
探针等待 ：若定义了 startupProbe 则等待其成功；否则 livenessProbe 开始工作。
进入运行 ：所有容器就绪，status.phase 更新为 Running。

十一、故障排查全流程（附命令）

11.1 通用排查步骤

bash

复制代码

# 1. 看 Pod 状态
kubectl get pods -n <namespace>

# 2. 看详细事件（最重要）
kubectl describe pod <pod-name> -n <namespace>

# 3. 看当前日志
kubectl logs <pod-name> -n <namespace>

# 4. 看上一次崩溃的日志（如果反复重启）
kubectl logs <pod-name> -n <namespace> --previous

# 5. 多容器时指定容器名
kubectl logs <pod-name> -c <container-name> --previous

11.2 针对不同状态的排查表

状态	常见原因	排查命令
Pending	资源不足、PVC 未绑定、节点污点无容忍	`kubectl describe pod` 查看事件；检查节点资源 `kubectl top node`
ImagePullBackOff	镜像名错误、私有仓库未鉴权、仓库网络不通	`kubectl describe pod` 查看拉取错误详情；手动 `docker pull` 测试
CrashLoopBackOff	启动命令错误、依赖服务未就绪、配置错误	`kubectl logs --previous` 查看崩溃时的输出
OOMKilled	内存 limit 过小或应用内存泄漏	`kubectl describe pod` 查看 `State: Terminated` 中 `Reason: OOMKilled`，调大 `memory.limit`
ContainerCreating	镜像过大拉取慢、存储卷挂载失败（如 PVC 未绑定）、CNI 插件异常	`kubectl describe pod` 关注 Events；检查节点 `kubectl get pvc` 和 CNI 插件状态
ErrImagePull	与 ImagePullBackOff 类似，但无退避等待	同 ImagePullBackOff

11.3 高级排查工具

bash

复制代码

# 查看节点上实际运行的容器（需节点权限）
crictl ps -a | grep <pod-uid>

# 查看容器日志（绕过 kubelet，直接从 runtime 获取）
crictl logs <container-id>

# 临时增加 Pod 的调试容器（Ephemeral Container，需 k8s ≥1.23）
kubectl debug pod/<pod-name> -it --image=busybox --target=<container-name>

十二、补充高级知识点（生产必备）

以下是原文未详细展开但非常关键的高级主题，每个都附有简短说明和示例。

12.1 Init Containers（初始化容器）

Init 容器在主容器启动前按顺序执行，全部成功后才启动主容器。常用于：

等待数据库或依赖服务 curl --fail --retry 10 http://db:5432
初始化数据卷（创建目录、修改权限）
注册中间件或生成配置文件

yaml

复制代码

spec:
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting; sleep 2; done;']
  containers:
  - name: main-app
    image: myapp:latest

12.2 Pod 生命周期钩子（PostStart / PreStop）

允许在容器启动后或停止前执行特定命令。

yaml

复制代码

lifecycle:
  postStart:
    exec:
      command: ["/bin/sh", "-c", "echo Hello from postStart > /tmp/message"]
  preStop:
    exec:
      command: ["/bin/sh", "-c", "nginx -s quit; sleep 30"]

注意：postStart 与主容器的 ENTRYPOINT 异步执行，不保证顺序；preStop 在 Pod 被删除时调用，常用于优雅下线。

12.3 Pod 安全上下文（SecurityContext）

可以设置容器以非 root 用户运行、限制特权、添加 Capabilities。

yaml

复制代码

spec:
  securityContext:          # Pod 级
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: app
    securityContext:        # 容器级
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
        add: ["NET_ADMIN"]

12.4 Pod 的 QoS 类（Quality of Service）

K8s 根据 Pod 的 requests 和 limits 自动划分三个等级，优先级从高到低：

QoS 类	条件	驱逐时优先级
Guaranteed	每个容器的 `requests == limits`（CPU 和内存）	最低，几乎不会被驱逐
Burstable	至少有一个容器的 `requests` 小于 `limits`	中等
BestEffort	没有任何容器的 `requests` 和 `limits`（全为 0）	最高，最先被驱逐

12.5 Pod 亲和性与反亲和性

相比 nodeSelector，亲和性支持软约束 和复杂逻辑。

yaml

复制代码

spec:
  affinity:
    podAntiAffinity:           # 尽量不与某类 Pod 在同一节点
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values: ["web"]
          topologyKey: kubernetes.io/hostname
    podAffinity:               # 尽量与某类 Pod 在一起
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app: cache
        topologyKey: topology.kubernetes.io/zone

12.6 拓扑分布约束（TopologySpreadConstraints）

将 Pod 均匀分布在故障域（节点、区域、可用区）上。

yaml

复制代码

spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: myapp

12.7 Pod 优先级与抢占（Priority & Preemption）

先创建 PriorityClass，然后 Pod 指定 priorityClassName。高优先级 Pod 可抢占低优先级 Pod 的资源。

yaml

复制代码

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
---
spec:
  priorityClassName: high-priority

12.8 PodDisruptionBudget（PDB）

限制自愿中断（如节点排空、滚动更新）时最多可同时移除多少个 Pod，保障可用性。

yaml

复制代码

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

12.9 临时容器（Ephemeral Containers）

用于实时调试运行中的 Pod，无需重启，特别适合无 bash 的镜像。

bash

复制代码

kubectl debug -it pod/myapp --image=busybox --target=myapp-container

12.10 Pod 开销（Pod Overhead）

对于使用虚拟化容器（如 Kata Containers）的场景，调度器需额外预留资源给虚拟机监视器（VMM）。

yaml

复制代码

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata
overhead:
  podFixed:
    memory: "120Mi"
    cpu: "250m"

12.11 Cgroup v2 支持

K8s 1.25+ 全面支持 cgroup v2，提供更准确的资源统计和更好的内存隔离。节点需配置 cgroupDriver: systemd 并启用 v2。

12.12 Pod 的 DNS 策略

策略名	说明
`ClusterFirst`	优先使用集群 DNS（kube-dns/coreDNS），外部域名通过集群 DNS 转发
`Default`	继承节点上的 `/etc/resolv.conf`
`None`	完全自定义 `dnsConfig`

yaml

复制代码

spec:
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
    - 1.2.3.4
    searches:
    - ns1.svc.cluster.local

总结

本文从 Pod 的基础概念一路深入到生产级高级特性，覆盖了：

✅ 核心定义与 Pause 容器
✅ 所有状态及其排错方法
✅ 40+ 条常用命令（创建、调试、端口转发、文件拷贝）
✅ 多个完整的 YAML 示例（包含探针、多容器、重启策略）
✅ 启动过程的 10 步详解
✅ 系统性故障排查流程
✅ 12 个高级知识点（initContainer、安全上下文、QoS、亲和性、PDB、临时容器等）

Pod 是 Kubernetes 的灵魂，理解它就能掌握集群调度的基本单位。希望这份"知识大全"能成为你日常开发和运维中随手翻阅的工具手册。如果你在实践中遇到了本文未覆盖的 Pod 问题，欢迎留言交流。