
一个集群由多个节点构成,节点被分成管理节点及工作节点
Pod是集群中可以调度最小单元,是一组容器集合抽象,因此为由一个一个容器组合一起来构成其本身,它是一个可以运行一个或多个紧密相关容器的逻辑主机。每个 Pod 都具有自己的 IP 地址、存储和网络空间。一个 Pod 中的容器共享相同的资源,可以通过 localhost 相互通信。
在 Kubernetes(K8s)中,一个应用实例与容器的关系是一对一的。在 K8s 中,应用程序被打包为一个或多个容器,并以 Pod 的形式进行部署和运行。
在 Kubernetes 中,Pod 是最小的、可部署的计算单元,也是整个系统的核心抽象。理解 Pod 是掌握 Kubernetes 的关键第一步。
Pod 是一个或多个容器(Container)的逻辑集合,共享网络、存储和运行环境,作为一个整体被调度和管理。 ✅ 核心特点: 表格 特性 说明 原子调度单位 Kubernetes 调度器以 Pod 为单位分配到节点(Node),不是单个容器 共享网络 Pod 内所有容器共享同一个 IP 地址和端口空间,可通过 localhost 互相通信 共享存储 通过 Volume,容器可共享文件系统(如日志、临时数据) 同生共死 Pod 被删除 → 所有容器终止;任一容器崩溃 → Pod 进入异常状态
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
labels:
app: web
spec:
# 定义容器
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 80
volumeMounts:
- name: config
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
- name: log-shipper # Sidecar 容器
image: fluentd
volumeMounts:
- name: logs
mountPath: /var/log
# 定义共享存储卷
volumes:
- name: config
configMap:
name: nginx-config
- name: logs
emptyDir: {}
# 可选:初始化容器(先于主容器运行)
initContainers:
- name: wait-for-db
image: busybox
command: ['sh', '-c', 'until nslookup mydb; do echo waiting; sleep 2; done']Pod 不是“永久实体”,它有明确的状态流转:
Pending → Running → Succeeded / Failed / Unknown
状态 | 含义 |
|---|---|
Pending | 已创建,但镜像拉取中或资源不足 |
Running | 至少一个容器在运行(或重启中) |
Succeeded | 所有容器正常退出(常用于 Job) |
Failed | 至少一个容器异常退出 |
CrashLoopBackOff | 容器反复崩溃重启(常见错误!) |
💡 使用 kubectl describe pod <name> 查看事件,定位卡在 Pending 或 Crash 的原因。
直接运行容器不行吗?不行! 原因如下:
问题 | Pod 如何解决 |
|---|---|
多容器协作 | Web + 日志收集器(sidecar)需共享日志目录 |
网络共享 | 应用与代理(如 Istio sidecar)需 localhost 通信 |
原子性 | 调度时必须保证 Web 和 Cache 在同一节点 |
生命周期绑定 | 主容器退出,辅助容器也应终止 |
🌰 例子:
一个 Pod 包含: 主容器:Python Web 应用 Sidecar 容器:Prometheus exporter Init Container:等待数据库就绪 它们共享 /app/logs 目录,且必须一起调度到同一台机器。
1. 不要直接创建裸 Pod! 裸 Pod 不会自动恢复(节点故障后不会重建) 应使用 控制器(Controller) 管理: Deployment:无状态应用(推荐) StatefulSet:有状态应用(如 ZooKeeper、MySQL) DaemonSet:每节点运行一个(如日志代理) Job/CronJob:一次性任务 ✅ 正确做法:用 Deployment 创建 Pod,而非直接 kubectl apply -f pod.yaml 2. Pod IP 是临时的 Pod 重建后 IP 会变 必须通过 Service 提供稳定访问入口 3. Pod 是“不可变”的 一旦创建,不能修改 spec.containers 等核心字段 更新应用 → 创建新 Pod(由控制器滚动更新) 4. 资源限制必须设置 避免单个 Pod 耗尽节点资源:
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"# 查看 Pod 列表及状态 kubectl get pods
# 查看 Pod 详细信息(事件、挂载、IP 等) kubectl describe pod <pod-name>
# 查看日志(主容器) kubectl logs <pod-name>
# 查看特定容器日志(多容器 Pod) kubectl logs <pod-name> -c <container-name>
# 进入容器执行命令 kubectl exec -it <pod-name> -- sh
# 查看前一次崩溃的日志(关键!) kubectl logs <pod-name> --previous
关键点 | 说明 |
|---|---|
最小调度单元 | K8s 不调度容器,只调度 Pod |
多容器协作模型 | 支持主应用 + sidecar/init 模式 |
共享上下文 | 网络、存储、IPC 共享 |
短暂性 | IP 和 hostname 不保证持久,需 Service 抽象 |
由控制器管理 | 实际生产中几乎总是通过 Deployment/StatefulSet 创建 |