一、Pod 到底是什么

Pod 是 Kubernetes 集群中运行和管理应用的最小部署单元。一个 Pod 里可以封装一个或多个容器，这些容器共享网络、存储以及部分命名空间资源，因此它们之间可以非常紧密地协作。

一个 Pod 不只是“容器的壳”，它本质上代表一组应该被一起调度、一起运行、一起销毁的进程集合。

另外，Pod 中通常还会有一个 pause 容器。它不负责业务处理，而是负责承载 Pod 级别的共享网络和命名空间环境。

二、Pod 的架构应该怎么理解

下面这张图很适合用来理解 Pod 架构：

image-20250314222950347

如果以一个包含 Nginx 和 PHP 的 Pod 为例，可以这样理解：

  • pause 容器：为整个 Pod 提供共享网络和命名空间基础
  • Nginx 容器：负责接收 Web 请求
  • PHP 容器：负责处理动态业务逻辑

它们之所以能高效协作，是因为同一个 Pod 中的容器具备几个重要特性。

1. 共享网络命名空间

同一个 Pod 内的所有容器共享同一个 IP 和端口空间，因此容器之间可以直接通过 localhost 通信。

例如：

  • Nginx 监听 80
  • PHP-FPM 监听 9000
  • Nginx 可以直接把请求转发给 localhost:9000

2. 可以共享存储卷

多个容器可以挂载同一个 Volume，从而共享文件数据。一个常见场景就是：

  • Nginx 提供静态文件
  • PHP 处理动态请求
  • 两者共享同一份业务代码或静态资源目录

3. 生命周期天然协同

Pod 内的容器会被一起调度到同一个节点上，也通常一起启动、一起销毁。这非常适合强依赖协作的服务组合。

三、Pod 的设计思想是什么

Pod 的设计，不是为了“把多个容器随便塞一起”，而是为了表达进程级协作关系。

它背后的几个核心思想包括：

  • 多容器协作：适合主容器和 Sidecar 一起运行
  • 强依赖服务聚合：适合必须共享网络和生命周期的一组进程
  • 生命周期管理简化：把多容器组视为一个调度对象
  • 兼容多种运行时：通过 CRI 对接不同容器运行时实现

所以，Pod 关注的不是“单个容器有多强”，而是“一组进程怎样以最小单位稳定协作”。

四、Pod 的基本创建方式

1. 推荐方式：写 YAML 创建

一个最小 Pod 示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: registry.cn-hangzhou.aliyuncs.com/zq-demo/nginx:1.14.2
    ports:
    - containerPort: 80

这个 YAML 里最关键的字段可以这样理解：

  • apiVersion：资源 API 版本
  • kind：资源类型
  • metadata.name：Pod 名称
  • spec.containers：容器定义列表

创建命令：

kubectl create -f nginx.yaml

查看状态：

kubectl get -f nginx.yml
kubectl get -f nginx.yml -o wide

2. 直接通过命令创建

kubectl run nginx --image=registry.cn-hangzhou.aliyuncs.com/zq-demo/nginx:1.14.2

然后查看：

kubectl get po nginx
kubectl get po nginx -o wide

这种方式适合临时验证，但长期管理仍然更推荐 YAML。

五、写 Pod YAML 时两个很好用的辅助命令

查看 Pod 相关 API 资源：

kubectl api-resources | grep pod

查看 Pod 字段定义：

kubectl explain pod

它们能帮助你快速确认 Pod 对象的版本、字段层级和写法，避免纯靠记忆硬写 YAML。

六、操作 Pod 时要注意什么

一个很容易忽略的点是：Pod 不是为“频繁在线修改”设计的对象。

在很多场景下，只有 annotations 和 labels 这类字段修改后还能直接替换；如果涉及容器镜像、端口、命令等关键字段，通常更稳妥的做法是删除旧 Pod，再按新定义重新创建。

这也是为什么在真实生产环境中，更常见的是用 Deployment 来管理 Pod，而不是长期手工直接改 Pod。