配置pod的完整操作指南：从yaml编写到资源管理
配置pod是Kubernetes日常运维里最核心的动作，想要稳定上线业务，关键在于把资源声明、启动命令、健康检查和调度策略写对写全。很多新手习惯只写镜像和端口，结果遇到重启、调度、存储挂载问题才回头补配置，本文直接把配置pod时常用的字段、坑位和实战写法一次讲透。
配置pod时的yaml结构拆解
配置pod绕不开yaml文件，Kubernetes的pod定义就是一套声明式规范，你告诉集群“我要什么”，控制器负责“给你什么”,一个标准pod的yaml骨架如下：
apiVersion: v1
kind: Pod
metadata:
name: my-pod
namespace: default
labels:
app: web
spec:
containers:
- name: main-app
image: nginx:1.25
ports:
- containerPort: 80
这份配置里最基础的四项是apiVersion、kind、metadata、spec，apiVersion固定写v1，kind固定写Pod，metadata里的name和labels决定身份标识,spec里定义真正运行的容器。
很多入门教程到这里就结束了，但生产环境配置pod远比这个复杂，你不光要写“跑什么”，还要写“怎么跑”“跑在哪”“资源给多少”“挂了怎么办”，所以下面按实际场景,把高频配置项拆开讲。
pod配置文件里常见的核心参数
容器的启动命令与参数覆盖
镜像默认的启动命令不满足需求时，用command和args覆盖,这俩字段对应Dockerfile里的ENTRYPOINT和CMD。
spec:
containers:
- name: app
image: busybox:1.36
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello; sleep 10; done"]
注意一点：command替换ENTRYPOINT，args替换CMD，如果你只想替换CMD，就不要写command，只写args，这个细节在配置pod时经常弄反,导致容器启动后立刻退出。
环境变量的注入方式
配置pod时环境变量有三种常见写法：
- 直接写死：env下的name/value对。
- 引用configMap：valueFrom下的configMapKeyRef。
- 引用secret：valueFrom下的secretKeyRef。
env:
- name: DB_HOST
value: "10.0.0.8"
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: password
大型项目里secret引用比写死安全得多，尤其涉及数据库密码、第三方API密钥时。
端口与协议声明
容器监听端口必须在ports里声明，但不声明也不影响网络访问，Kubernetes真正用ports做的是服务发现和服务转发，建议配置pod时养成写明containerPort的习惯,方便后续的Service和Ingress关联。
ports: - containerPort: 8080 protocol: TCP
protocol默认TCP，支持UDP和SCTP，gRPC服务需要额外设置appProtocol: grpc。
配置pod资源限制时，如何给requests和limits设置合理值
资源管理是配置pod里最影响稳定性的部分，康容器调度器（kube-scheduler）根据requests把pod分配到合适的节点,limits限制容器最多能占用的资源。
理解CPU和内存的单位
- CPU单位：1表示一颗完整核心，100m表示0.1核。
- 内存单位：Mi是MiB，Gi是GiB，别把Mi当MB，虽然数值接近,但在高负载下换算差异会放大。
requests和limits怎么分配
行业共识认为，requests保底，limits封顶，如果只写limits不写requests，Kubernetes会自动把requests拉升到和limits一样，造成资源浪费，如果只写requests不写limits,容器可能把节点内存榨干。
线上配置pod的经验做法：
| 资源类型 | requests建议 | limits建议 | 说明 |
|---|---|---|---|
| CPU | 平均负载的70%-80% | 平均负载的150%-200% | 容忍突发流量 |
| 内存 | 平均使用量的120% | 平均使用量的150%-180% | 防OOM但留余量 |
resources:
requests:
cpu: 250m
memory: 512Mi
limits:
cpu: "1"
memory: 1Gi
内存超过limits时容器会被OOM Killer杀掉，CPU超过limits不会被杀，而是被节流（throttle）,表现为响应变慢。
配置pod生命周期钩子与健康检查
健康检查是配置pod时最容易被忽视但极其重要的模块，没有探针的pod，只有进程崩溃时才会被发现；有了探针，业务假死、死锁、内存泄漏导致的响应超时都能被感知并自动摘除流量。
livenessProbe存活探针
livenessProbe决定容器需不需要重启，进程还在但业务卡死的情况,livenessProbe可以识别。
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 3
initialDelaySeconds给应用留启动时间，periodSeconds每隔几秒执行一次,failureThreshold连续失败几次后重启容器。
readinessProbe就绪探针
readinessProbe决定流量是否打入，只有readiness通过,pod的IP才会被加入Service的Endpoints列表。
readinessProbe:
tcpSocket:
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
同一个端口可以同时挂liveness和readiness，但路径建议分开，因为readiness失败时不应重启容器，只是摘流量；liveness失败则说明应用彻底不行了,应该重启。
startupProbe启动探针
处理慢启动应用时用startupProbe，比如Java应用启动就要两分钟，如果用livenessProbe，启动期间就被杀好几次，startupProbe期间，liveness和readiness暂停工作,直到startupProbe成功。
startupProbe:
httpGet:
path: /health
port: 8080
failureThreshold: 30
periodSeconds: 10
pod配置里的存储挂载方式比较
配置pod时需要挂载数据的场景很多：日志文件、配置文件、临时缓存、持久化数据,每种场景用的卷类型不一样。
emptyDir：临时目录，随pod生命周期存活
适合放缓存、临时文件和sidecar之间交换数据,pod删除后emptyDir里的数据一起消失。
volumes:
- name: cache-dir
emptyDir: {}
containers:
- name: app
volumeMounts:
- mountPath: /cache
name: cache-dir
hostPath：节点目录直挂，适合读节点系统信息
hostPath把宿主机目录挂到容器里，常用于采集节点日志或读取节点配置，不适合跨节点持久化,因为pod漂移后数据不在新节点上。
persistentVolumeClaim：真正的持久化方案
生产环境配数据库、文件服务时用PVC,底层由云厂商的块存储或网络存储承载。
volumes:
- name: data
persistentVolumeClaim:
claimName: my-data-pvc
PVC的好处是与存储实现解耦你只管声明要多大、什么读写模式，具体分配给哪块云盘由存储类（StorageClass）决定。
多容器pod配置注意事项
一个pod里放多个容器是高级用法，它们共享网络命名空间和存储卷,适合sidecar模式。
常见搭配是主业务容器加一个日志采集sidecar：
spec:
containers:
- name: nginx
image: nginx:1.25
volumeMounts:
- mountPath: /var/log/nginx
name: logs
- name: log-shipper
image: fluentd:latest
volumeMounts:
- mountPath: /logs
name: logs
多容器编排时注意两个原则：
- 启动顺序无法保证，sidecar进程可能早于主容器就绪,应用需要自己处理依赖。
- 日志统一输出到stdout，而不是各写各的文件，否则Kubernetes的kubectl logs只能看到整个pod的合并日志,排查单容器问题很痛苦。
配置pod调度策略：从节点选择到亲和性
默认情况下配置pod的处理方式由调度器自动决定，但某些业务需要把pod绑到特定节点，比如GPU机器、高IO机器、满足合规要求的数据本地化。
nodeSelector：最简单粗暴的固定调度
给节点打label，然后pod指定label,限GPU训练任务最常见的写法。
nodeSelector: gpu-type: a100
nodeAffinity：灵活的偏好调度
如果想让pod优先在某个节点上跑，但不强制,用nodeAffinity。
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
preference:
matchExpressions:
- key: disk-type
operator: In
values:
- ssd
preferred表示软约束，没有匹配条件也会调度，requiredDuringSchedulingIgnoredDuringExecution是硬约束,没有符合条件的节点pod就一直Pending。
配置pod时容易踩的七个坑
根据运维经验，以下问题在配置pod时高频出现,提前避开能省大量排查时间。
- 镜像未指定tag或用了latest，导致每次拉取结果不一致,排障困难。
- 内存limits设置过低，看起来很“省”,实际频繁触发OOM重启。
- 单副本pod直接跑业务，没有用Deployment兜底,节点故障业务直接挂。
- Health check路径返回200但业务异常，因为探针只是确认进程还活着,不代表依赖的数据库连接正常。
- 忽略podPending状态，一直等却不知道为什么,本质是资源不够或调度约束不满足。
- 改了yaml没apply，直接编辑线上的实际config，尽量用kubectl apply -f file.yaml管理变更。
- 不设置pod disruption budget,节点维护时一次性全部pod被驱逐。
Q&A：配置pod相关的高频疑问
kubectl run和kubectl create有什么区别？
kubectl run会直接生成一个pod或deployment，适合快速测试，kubectl create是创建资源，必须提供yaml或json定义，生产环境配置pod建议都用create或apply配合yaml文件，因为可追溯、便于版本管理。
配置pod的资源限制时，requests和limits可以不写吗？
可以不写，但强烈不建议，不写requests意味着调度器不会为这个pod预留任何资源，节点上所有pod都可以把资源占满，一旦节点内存耗尽，或者CPU跑满，反而影响整个节点上的所有应用,至少在关键业务上写上合理值。
修改pod配置后，为什么有时候生效有时候不生效？
直接修改pod的yaml中部分字段（比如image）会触发pod重建，但有些字段（比如resources）在pod创建后是只读的，你需要通过deployment之类的控制器更新，控制体会先创建新pod，再删除旧pod,滚动升级。
配置pod这件事没有银弹，核心思路是声明清楚每一个细节，用版本管理yaml文件，按环境拆分参数，把基础字段写好，把资源限制给足，把探针配上，只要这三步做到位,绝大多数线上事故都可以避免。