kubernetes（K8s）学习笔记（第四期）：Pod 管理

AOwhisky2026-06-25 11:47

kubernetes（K8s）学习笔记（第四期）：Pod 管理

本笔记为 Kubernetes 系列第四期，聚焦 Kubernetes 最基本的工作负载对象------Pod 。Pod 是 Kubernetes 中最小调度、管理和自愈单元，也是容器运行的载体。涵盖：Pod 概念、基本管理（创建/查看/编辑/删除/exec/cp）、多容器 Pod、Pod 关键属性、Pod 生命周期与状态、restartPolicy、Init Container、静态 Pod、pause 容器深度解析。所有命令均来自课堂笔记，经过整理和注释。全文包含 70+ 命令示例 、16 个 YAML 片段 和 12 张对比表格，是 Kubernetes 工作负载管理的基础。
--- Compiled and Authored by Whisky --- June 24th, 2026

目录

  1. Pod 介绍
  2. Pod 基本管理
  3. 多容器 Pod
  4. Pod 关键属性详解
  5. Pod 生命周期与状态
  6. restartPolicy（重启策略）
  7. Init Container（初始化容器）
  8. 静态 Pod
  9. Pod 与容器深度辨析 + pause 容器
  10. 总结与知识点一览表

一、Pod 介绍

1.1 什么是 Pod？

官方定义：Pod 是 Kubernetes 中最小的可部署和可管理单元，代表集群上正在运行的一个进程实例。

Kubernetes 中，Pod 是容器的"外壳"，包含一个或多个容器。这些容器共享同一个网络命名空间（Network Namespace）、存储卷（Volume）和生命周期。

"豌豆荚"比喻：

ini 复制代码 
┌─────────────────────────────────────────────┐
│                    Pod                       │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  │
│  │  Pause   │  │  Nginx   │  │ Sidecar  │  │
│  │ (infra)  │  │ (业务)   │  │ (日志)   │  │
│  └──────────┘  └──────────┘  └──────────┘  │
│  共享网络、存储、IP、端口空间                │
└─────────────────────────────────────────────┘

可以把 Pod 看成一个"豌豆荚"，里面的"豆子"就是容器。一个豌豆荚里的豆子共享相同的"生长环境"（网络、存储、资源），它们一起被调度、一起运行、一起销毁。

1.2 单容器 Pod vs 多容器 Pod

类型 特点 适用场景
单容器 Pod Pod 中只有一个业务容器 大部分常规应用
多容器 Pod Pod 中有多个容器协同工作 日志收集、监控代理、网络代理（Sidecar 模式）

单容器 Pod 示例：

ini 复制代码 
Pod
└── Nginx 容器（web 服务）

多容器 Pod 示例：

ini 复制代码 
Pod
├── Nginx 容器（web 服务）
└── Filebeat 容器（日志收集 Sidecar）

1.3 Pod 中多个容器共享的资源

Pod 中所有容器共享以下资源：

  • 网络命名空间 ：所有容器共享同一个 IP 地址和端口空间，可以通过 localhost 互相通信。
  • 存储卷（Volume）：所有容器可以挂载同一个 Volume，实现数据共享。
  • IPC 命名空间：容器之间可以通过进程间通信（如共享内存）交互。
  • UTS 命名空间：容器共享主机名。

💡 白话理解：Pod 中的多个容器就像住在同一间公寓的室友，共用"门牌号"（IP）、"公共区域"（存储卷），彼此之间可以通过"敲门"（localhost）交流。
💡 思维误区：有些新手以为 Pod 就是容器，或者 Pod 只是容器的简单封装。实际上，Pod 是 Kubernetes 独有的抽象，它提供了网络共享、存储共享、生命周期管理等容器层面无法实现的能力。

1.4 环境准备

bash

bash 复制代码 
[root@master30 ~]# kubectl create ns pods
namespace/pods created
[root@master30 ~]# kubectl config set-context --current --namespace=pods
Context "kubernetes-admin@kubernetes" modified.

二、Pod 基本管理

2.1 创建 Pod

方式一：使用 kubectl run

直接创建：

bash 复制代码 
[root@master30 ~]# kubectl run web --image=docker.io/library/nginx
pod/web created

生成 YAML 但不创建（dry-run）：

bash 复制代码 
[root@master30 ~]# kubectl run web --image=nginx --dry-run=client -o yaml
yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: web
  name: web
spec:
  containers:
  - image: docker.io/library/nginx
    name: web
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

💡 思维误区 ：kubectl run 创建的是"裸 Pod"（没有 Deployment 等控制器管理）。在生产环境中，建议使用 Deployment 等控制器管理 Pod，以获得滚动更新、回滚、自愈等能力。

方式二：使用 YAML 文件创建
yaml 复制代码 
# web.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: web
  name: web
spec:
  containers:
  - image: docker.io/library/nginx
    name: web
bash 复制代码 
[root@master30 ~]# kubectl create -f web.yaml
# 或
[root@master30 ~]# kubectl apply -f web.yaml

2.2 查看 Pod

bash 复制代码 
# 查看 Pod 列表
[root@master30 ~]# kubectl get pod
NAME   READY   STATUS    RESTARTS   AGE
web    1/1     Running   0          51s

# 查看 Pod 详细信息（含 IP、节点）
[root@master30 ~]# kubectl get pod -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE
web    1/1     Running   0          67s   10.224.51.131   worker31.whisky.cloud

# 查看 Pod YAML 定义
[root@master30 ~]# kubectl get pod web -o yaml

# 查看 Pod 详细状态（排错首选）
[root@master30 ~]# kubectl describe pod web

# 查看 Pod 日志
[root@master30 ~]# kubectl logs web
# 实时跟踪日志
[root@master30 ~]# kubectl logs -f web

2.3 在 Pod 中执行命令

bash 复制代码 
# 执行单条命令
[root@master30 ~]# kubectl exec web -- hostname
web
[root@master30 ~]# kubectl exec web -- pwd
/

# 交互式执行
[root@master30 ~]# kubectl exec -it web -- bash
root@web:/# echo "Hello" > /usr/share/nginx/html/index.html
root@web:/# exit

# 查看当前用户
[root@master30 ~]# kubectl exec web -- id
uid=0(root) gid=0(root) groups=0(root)

🔧 常用场景 ：kubectl exec 是调试 Pod 的首选工具，可用于查看 Pod 内部文件、测试网络连通性、查看进程状态等。

2.4 复制文件到 Pod

bash 复制代码 
[root@master30 ~]# kubectl cp /etc/hosts web:/new-hosts
[root@master30 ~]# kubectl exec web -- ls /new-hosts
/new-hosts

2.5 编辑 Pod

bash 复制代码 
[root@master30 ~]# kubectl edit pod web

⚠️ 注意 ：并非所有属性都可以在线编辑。例如 Pod 的 name、namespace、spec.containers.image 等字段可能无法直接修改。如果需要修改这些字段，可以：

  1. 导出 YAML 文件：kubectl get pod web -o yaml > web.yaml
  2. 修改 YAML 文件
  3. 删除旧 Pod：kubectl delete pod web
  4. 重新创建：kubectl apply -f web.yaml

2.6 删除 Pod

bash 复制代码 
[root@master30 ~]# kubectl delete pod web
pod "web" deleted

💡 思维误区 ：执行 kubectl delete pod 后，Pod 不会立即消失，而是有一个 优雅终止期（terminationGracePeriodSeconds，默认 30 秒）。在此期间，Pod 会收到 SIGTERM 信号，容器可以执行清理操作。如果 30 秒后仍未退出，会被强制杀死（SIGKILL）。

查看优雅终止时间：

bash 复制代码 
[root@master30 ~]# kubectl get pod web -o yaml | grep terminationGracePeriodSeconds
terminationGracePeriodSeconds: 30

2.7 综合实验：构建 WordPress

场景：在 Kubernetes 集群中部署 WordPress + MySQL。

步骤 1：创建 MySQL Pod

bash 复制代码 
[root@master30 ~]# kubectl run wordpress-db \
    --image=mysql \
    --image-pull-policy IfNotPresent \
    --env MYSQL_ROOT_PASSWORD=123

步骤 2：创建 WordPress Pod

bash 复制代码 
[root@master30 ~]# kubectl run wordpress-app \
    --image=wordpress \
    --image-pull-policy IfNotPresent

步骤 3：端口转发（将 Pod 端口暴露到宿主机）

bash 复制代码 
[root@master30 ~]# kubectl port-forward pod/wordpress-app --address 10.1.8.30 8080:80
# 此命令需要保持运行，不要关闭窗口

步骤 4：查看 Pod IP

bash 复制代码 
[root@master30 ~]# kubectl get pods -o wide | awk '{print $1" "$6}'
NAME IP
wordpress-app 10.224.113.135
wordpress-db 10.224.19.5

步骤 5：创建数据库

bash 复制代码 
[root@master30 ~]# mysql -uroot -p123 -h 10.224.19.5
mysql> create database wordpress;
mysql> create user wordpress identified by '123';
mysql> grant all privileges on wordpress.* to wordpress;
mysql> flush privileges;
mysql> exit

步骤 6：访问 WordPress

浏览器访问 http://10.1.8.30:8080，填写 WordPress 安装信息。

三、多容器 Pod

3.1 多容器 Pod 的使用场景

场景 说明
Sidecar 模式 在主容器旁运行辅助容器（日志收集、监控、代理）
数据同步 一个容器写数据，另一个容器读取或备份
初始化 使用 Init Container 完成初始化后再启动主容器
代理/网关 主容器提供业务服务，代理容器处理网络通信

3.2 多容器 Pod YAML 示例

yaml 复制代码 
# pod-blog.yaml
apiVersion: v1
kind: Pod
metadata:
  name: bbs
  labels:
    run: bbs
spec:
  containers:
  # 容器1：MySQL 数据库
  - image: docker.io/library/mysql:latest
    imagePullPolicy: IfNotPresent
    name: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "123"
    - name: MYSQL_USER
      value: tom
    - name: MYSQL_PASSWORD
      value: "123"
    - name: MYSQL_DATABASE
      value: bbs
    ports:
    - containerPort: 3306
      name: mysql
      protocol: TCP

  # 容器2：WordPress 应用
  - image: docker.io/library/wordpress:latest
    imagePullPolicy: IfNotPresent
    name: wordpress
    env:
    - name: WORDPRESS_DB_USER
      value: tom
    - name: WORDPRESS_DB_PASSWORD
      value: "123"
    - name: WORDPRESS_DB_NAME
      value: bbs
    - name: WORDPRESS_DB_HOST
      value: 127.0.0.1   # 使用 localhost 访问同 Pod 中的 MySQL
    ports:
    - containerPort: 80
      name: wordpress
      protocol: TCP
      hostPort: 80       # 将容器端口映射到宿主机 80 端口

3.3 部署和验证

bash 复制代码 
[root@master30 ~]# kubectl apply -f pod-blog.yaml

# 查看 Pod 状态
[root@master30 ~]# kubectl get pods -o wide
NAME   READY   STATUS    RESTARTS   AGE   IP              NODE
bbs    2/2     Running   0          10m   10.224.225.68   worker32.whisky.cloud

# 多容器 Pod 中执行命令（-c 指定容器）
[root@master30 ~]# kubectl exec bbs -c wordpress -- hostname
bbs

# 复制文件到指定容器
[root@master30 ~]# kubectl cp /etc/hosts bbs:/new-hosts -c wordpress

# 访问 MySQL 容器
[root@master30 ~]# kubectl exec -it bbs -c mysql -- mysql -utom -p123
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| bbs                |
+--------------------+
mysql> exit

💡 关键理解 ：WordPress 容器通过 127.0.0.1 连接 MySQL 容器，因为它们处于同一个 Pod 中，共享网络命名空间。这正是多容器 Pod 的核心价值------容器之间无需通过 Service，直接使用 localhost 通信，延迟更低、配置更简单。

访问 WordPress ：浏览器打开 http://10.1.8.32/（宿主机 IP），应能看到 WordPress 安装界面。

四、Pod 关键属性详解

4.1 pod.metadata

bash 复制代码 
[root@master30 ~]# kubectl explain pod.metadata | grep '^  [a-zA-Z]'
   annotations	<map[string]string>
   clusterName	<string>
   creationTimestamp	<string>
   deletionGracePeriodSeconds	<integer>
   deletionTimestamp	<string>
   finalizers	<[]string>
   generateName	<string>
   generation	<integer>
   labels	<map[string]string>
   managedFields	<[]Object>
   name	<string>
   namespace	<string>
   ownerReferences	<[]Object>
   resourceVersion	<string>
   selfLink	<string>
   uid	<string>

重点关注：

属性 作用
labels 标签，用于选择、分组和调度
name Pod 名称，集群内唯一
namespace 命名空间
deletionGracePeriodSeconds 优雅终止宽限期（秒）

4.2 pod.spec

bash 复制代码 
[root@master30 ~]# kubectl explain pod.spec | grep '^  [a-zA-Z]'
   activeDeadlineSeconds	<integer>
   affinity	<Object>
   containers	<[]Object> -required-
   dnsPolicy	<string>
   hostAliases	<[]Object>
   hostIPC	<boolean>
   hostNetwork	<boolean>
   hostPID	<boolean>
   hostname	<string>
   imagePullSecrets	<[]Object>
   initContainers	<[]Object>
   nodeName	<string>
   nodeSelector	<map[string]string>
   restartPolicy	<string>
   schedulerName	<string>
   securityContext	<Object>
   serviceAccountName	<string>
   terminationGracePeriodSeconds	<integer>
   tolerations	<[]Object>
   volumes	<[]Object>

重点关注：

属性 作用
containers 必填，Pod 中容器列表
nodeName 指定调度到哪个节点
volumes 定义存储卷
restartPolicy 重启策略
terminationGracePeriodSeconds 优雅终止宽限期

4.3 pod.spec.containers

bash 复制代码 
[root@master30 ~]# kubectl explain pod.spec.containers | grep '^   [a-zA-Z]'
   args	<[]string>
   command	<[]string>
   env	<[]Object>
   envFrom	<[]Object>
   image	<string>
   imagePullPolicy	<string>
   lifecycle	<Object>
   livenessProbe	<Object>
   name	<string> -required-
   ports	<[]Object>
   readinessProbe	<Object>
   resources	<Object>
   securityContext	<Object>
   startupProbe	<Object>
   stdin	<boolean>
   terminationMessagePath	<string>
   volumeDevices	<[]Object>
   volumeMounts	<[]Object>
   workingDir	<string>

重点关注：

属性 作用
image 容器镜像
imagePullPolicy 镜像拉取策略
command / args 容器启动命令和参数
env 环境变量
ports 容器端口
volumeMounts 挂载存储卷

4.4 imagePullPolicy（镜像拉取策略）

策略 行为 适用场景
Always 每次启动都从仓库拉取镜像 镜像标签为 latest 时默认
Never 只使用本地镜像，不拉取 使用本地构建的镜像
IfNotPresent 本地没有时才拉取 生产环境推荐，节省带宽

五、Pod 生命周期与状态

5.1 Pod 生命周期

Pod 的生命周期取决于 Pod 中所有容器的生命周期：

  1. Pod 创建（Pending）→ 调度到节点
  2. 容器创建（ContainerCreating）→ 拉取镜像、创建容器
  3. 容器运行（Running）→ 容器进程运行
  4. 容器终止（Terminating）→ 收到终止信号，优雅退出
  5. Pod 删除（Completed / Error）→ 资源清理

5.2 Pod 状态（Status）

状态 含义 常见原因
ContainerCreating 正在创建容器 拉取镜像、创建容器过程中
Running Pod 正常运行 所有容器均已启动
Completed 运行完成 容器进程正常退出（exit 0）
Error 运行错误 容器进程错误退出（exit ≠ 0）
CrashLoopBackOff 反复崩溃重启 容器启动失败，正在退避等待
ErrImagePull / ImagePullBackOff 镜像拉取失败 镜像不存在、网络问题、认证失败
Terminating 正在终止 执行删除操作，优雅终止中

🔧 排故思路：当 Pod 状态异常时，按以下顺序排查：

  1. kubectl get pod -o wide 查看 Pod 所在节点
  2. kubectl describe pod <name> 查看事件（Events）
  3. kubectl logs <name> 查看容器日志
  4. kubectl logs <name> --previous 查看上次崩溃的日志

5.3 实验：单容器 Pod 状态验证

YAML 文件（正常退出）：

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  restartPolicy: Never
  containers:
  - name: busybox
    image: docker.io/library/busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 10']

观察 Pod 状态变化：ContainerCreating → Running → Completed

YAML 文件（错误退出）：

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  restartPolicy: Never
  containers:
  - name: busybox
    image: docker.io/library/busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c', 'echoxxx Hello Kubernetes! && sleep 5']

观察 Pod 状态变化：ContainerCreating → Error

5.4 实验：多容器 Pod 状态验证

当 Pod 中包含多个容器时，Pod 的状态取决于所有容器的综合状态：

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  labels:
    app: busybox
spec:
  restartPolicy: Never
  containers:
  - name: busybox1
    image: docker.io/library/busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 5']
  - name: busybox2
    image: docker.io/library/busybox
    imagePullPolicy: IfNotPresent
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 10']
  • 当一个容器完成而另一个还在运行时，Pod 状态可能为 NotReady（有一个容器未就绪）
  • 当所有容器都完成时，Pod 状态变为 Completed
  • 当任何一个容器错误退出时，Pod 状态变为 Error

六、restartPolicy（重启策略）

6.1 三种重启策略

策略 行为 适用场景
Always 无论什么状态，总是重启容器 默认值，适用于 Web 服务等长期运行的应用
OnFailure 只有在失败时才重启 适合批处理任务
Never 从不重启 适合一次性任务（调试、数据迁移）

💡 思维误区 ：restartPolicy 是针对 Pod 中所有容器的，而不是单个容器。只要 Pod 中有一个容器需要重启，整个 Pod 就会根据策略重新创建。

6.2 实验：验证重启策略

Always 策略（默认）：

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  restartPolicy: Always
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'echo Hello && sleep 5']

观察：容器完成后被自动重启，不断循环。

OnFailure 策略：

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  restartPolicy: OnFailure
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'echo Hello && sleep 5']

观察：容器正常完成（exit 0）后不会重启 ；如果命令错误（exit ≠ 0），则会重启。

Never 策略：

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  restartPolicy: Never
  containers:
  - name: busybox
    image: busybox
    command: ['sh', '-c', 'echo Hello && sleep 5']

观察：容器完成或出错后都不重启。

6.3 多容器场景下的重启策略

验证结果 ：只要有一个容器满足重启策略条件，就会重启整个 Pod。

💡 白话理解：Pod 中的容器是一荣俱荣、一损俱损的"命运共同体"。任何一个容器出问题，都会触发 Pod 级别的重启。

七、Init Container（初始化容器）

7.1 什么是 Init Container？

Init Container 是在 Pod 中在普通容器启动之前运行的特殊容器，用于执行初始化任务。

关键特点：

  • 按顺序执行，前一个成功后才能执行下一个
  • 所有 Init Container 必须成功完成（exit 0），普通容器才能启动
  • 如果 Init Container 失败，Kubernetes 会根据 restartPolicy 重启 Pod
  • Init Container 不支持就绪探针（readinessProbe）

7.2 Init Container 使用场景

场景 示例命令
等待依赖服务就绪 until nslookup myservice; do sleep 2; done
等待固定时间 sleep 60
初始化数据 git clone ... 或 chown ...
数据库迁移 运行数据库迁移脚本

7.3 Init Container 实验

实验 1：等待 Service 就绪

yaml 复制代码 
# pod-myapp.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done; sleep 3;']
  - name: init-mydb
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done; sleep 3;']
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']

实验过程：

  1. 先创建 2 个 Service（myservice、mydb）
  2. 再创建 Pod
  3. 观察 Pod 状态变化：Init:0/2 → Init:1/2 → PodInitializing → Running

实验 2：Init Container 初始化 Volume

yaml 复制代码 
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  volumes:
  - name: workdir
    emptyDir: {}
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  initContainers:
  - name: init-poda
    image: busybox
    command: ['sh', '-c', 'touch /work-dir/aa.txt && sleep 10']
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"

在 app 容器中查看初始化生成的文件：

bash 复制代码 
[root@master30 ~]# kubectl exec myapp-pod -c myapp-container -- ls /work-dir
aa.txt

八、静态 Pod

8.1 什么是静态 Pod？

问题：Master 节点上的 kube-apiserver、kube-scheduler、kube-controller-manager 等组件是由谁管理的？它们也是 Pod，但谁来管理它们？

答案 ：kubelet 服务 。Master 节点上的系统组件以静态 Pod 方式运行，由本地 kubelet 直接管理，不通过 API Server。

静态 Pod 特点：

  • kubelet 直接管理，不依赖 API Server
  • 不能与 ReplicationController、Deployment 或 DaemonSet 关联
  • kubelet 不会对其健康检查
  • 无法通过 API Server 删除（只能删除本地文件）

8.2 静态 Pod 配置

kubelet 通过 staticPodPath 参数指定静态 Pod 目录：

bash 复制代码 
[root@master30 ~]# grep staticPodPath /var/lib/kubelet/config.yaml
staticPodPath: /etc/kubernetes/manifests

[root@master30 ~]# ls -1 /etc/kubernetes/manifests
etcd.yaml
kube-apiserver.yaml
kube-controller-manager.yaml
kube-scheduler.yaml

kubelet 会定期扫描该目录中的 YAML 文件，根据文件变更创建或删除 Pod。

💡 思维误区 ：有些人以为可以通过 kubectl delete pod 删除 Master 组件 Pod。实际上这些是静态 Pod，kubectl delete pod 会显示 Pod 被删除，但 kubelet 会立即根据本地 YAML 文件重新创建它们。

九、Pod 与容器深度辨析 + pause 容器

9.1 Pod 与 Container 的核心区别

特性 容器（Container） Pod
K8s 最小调度单位 ❌ 不是 ✅ 是
独立 IP ✅ 有 ✅ 有
独立存储 ✅ 有 ✅ 有
多容器支持 ❌ 不支持 ✅ 天然支持
网络/存储共享 ❌ 不能 ✅ 内部容器可共享
生命周期管理 ❌ 弱（运行时层面） ✅ 完整（重启、自愈）
属于谁 容器运行时（Docker/containerd） Kubernetes

💡 白话理解：容器是"真正的打工者"（跑应用的进程），Pod 是"工位"（提供网络、存储、运行环境）。Kubernetes 不直接管"打工者"，而是管"工位"。

9.2 为什么 K8s 管理 Pod 而不是容器？

1. 容器太"原子"，不适合直接调度

K8s 需要一个能直接调度、有完整身份、能独立运行的对象------这就是 Pod。

2. Pod 支持"多容器协同"（最关键的设计）

很多场景必须多个容器一起跑、共享资源：

  • 业务容器 + Sidecar（日志、监控、代理）
  • 业务容器 + InitContainer（初始化）
  • 业务容器 + 网络/安全代理容器

它们需要：

  • 共享 Network Namespace（同一个 IP、端口空间）
  • 共享 Volume
  • 一起调度到同一台机器

3. Pod 提供统一的生命周期与自愈

如果直接管理容器，多容器应用会非常混乱。以 Pod 为单位，管理语义清晰、一致。

4. 解耦底层容器运行时

Pod 屏蔽了底层实现（Docker、containerd、cri-o），K8s 只跟 Pod/CRI 打交道。

9.3 pause 容器的 3 个核心作用

在 Kubernetes 中，每个 Pod 都会自动创建一个 pause 容器 （也叫 infra 容器），它是 Pod 里第一个启动、最后退出的容器。

作用 1：创建并持有 Pod 的 Linux Namespace

Pod 里所有容器要共享：

  • Network namespace（同一个 IP、端口）
  • PID namespace（可选）
  • IPC namespace

这些共享空间必须由一个"永远不死"的容器来持有 ，否则共享空间会消失。这个容器就是 pause。

作用 2：让 Pod 生命周期独立于业务容器

  • 业务容器挂了 → 重启
  • pause 容器不挂 → Pod 就不会消失
  • 网络、IP、存储挂载都能保持不变

作用 3：实现多容器共享网络

所有容器都加入 pause 的 network namespace：

  • 共享同一个 IP
  • 可以用 127.0.0.1 互相访问
  • 端口不能冲突

9.4 超形象比喻

概念 比喻
pause = 房东 先占好房子（网络/命名空间）
Pod = 房子 提供居住环境
业务容器 = 租客 住进房子，干活

房东（pause）先占好房子（网络/命名空间），租客（业务容器）才能住进来。租客换了一波又一波，房子一直都在。

9.5 Pod 内部结构

text

ini 复制代码 
┌─────────────────────────────────────────────┐
│                    Pod                       │
│  ┌──────────────────────────────────────┐   │
│  │        pause 容器（infra）           │   │
│  │  - 持有 Network Namespace           │   │
│  │  - 持有 IP 地址                     │   │
│  │  - 第一个启动，最后一个退出          │   │
│  └──────────────────────────────────────┘   │
│                    │                         │
│  ┌────────────┐  ┌────────────┐  ┌─────────┐│
│  │  Nginx     │  │  业务容器  │  │ Sidecar ││
│  │  (共享 IP) │  │  (共享 IP) │  │ (共享IP)││
│  └────────────┘  └────────────┘  └─────────┘│
│  通过 127.0.0.1 互相通信，共享 Volume       │
└─────────────────────────────────────────────┘

十、总结与知识点一览表

10.1 核心知识点汇总

模块 核心概念 关键命令/配置
Pod 概念 最小调度单元、容器外壳 ---
Pod 管理 run / get / describe / logs / exec / cp kubectl run, kubectl get pod, kubectl exec
多容器 Pod Sidecar、共享网络/存储 kubectl exec -c
imagePullPolicy Always / Never / IfNotPresent imagePullPolicy: IfNotPresent
Pod 状态 ContainerCreating / Running / Completed / Error / CrashLoopBackOff kubectl describe pod
restartPolicy Always / OnFailure / Never restartPolicy: Always
Init Container 初始化任务、顺序执行 initContainers 字段
静态 Pod kubelet 管理、本地目录 staticPodPath
pause 容器 持有 Network Namespace 自动创建，无需配置

10.2 常用命令速查

操作 命令
创建 Pod kubectl run <name> --image=<image>
查看 Pod kubectl get pods / kubectl get pod -o wide
查看 Pod 详情 kubectl describe pod <name>
查看 Pod 日志 kubectl logs <name>
在 Pod 中执行命令 kubectl exec -it <name> -- <command>
复制文件到 Pod kubectl cp <local> <pod>:<path>
删除 Pod kubectl delete pod <name>
生成 YAML（不创建） kubectl run <name> --image=<image> --dry-run=client -o yaml

10.3 常见错误排查

错误 原因 解决方法
CrashLoopBackOff 容器反复崩溃 查看日志 kubectl logs <pod> --previous
ImagePullBackOff 镜像拉取失败 检查镜像名、仓库认证、网络
Pod Pending 资源不足或调度限制 kubectl describe pod 查看事件
Executable file not found command 命令不存在 检查容器内是否有该命令
terminationGracePeriodSeconds 超时 容器无法优雅退出 调整宽限期或检查容器关闭逻辑

下一期预告：Kubernetes 控制器管理------Deployment、ReplicaSet、DaemonSet、Job/CronJob 等核心工作负载控制器。
--- Compiled and Authored by Whisky --- June 24th, 2026

热门推荐
01GitHub 镜像站点022026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片03AI科技热点日报 | 2026年07月01日04幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南05AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路06GPT-5.5 对比 GPT-5.6 Sol、Terra、Luna：官方性能数据与选型分析072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？08国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）09几个好用的ip纯净度检测网站10Codex 下载安装指南：Windows 和 macOS 官方版下载