8.1 play kube：本地复现生产拓扑
8.1 play kube：本地复现生产拓扑
本节摘要：podman play kube 读取 Kubernetes 风格的 YAML，在单机上创建 Pod、卷与服务。本节从一份含双容器、共享卷、健康检查的 YAML 走起，验证本地行为与集群语义的对应关系，明确哪些字段本地生效、哪些被忽略，最后建立"本地验证的结论边界"——它验证的是 Pod 语义，不是集群行为。
第一份 YAML：从集群视角定义本地负载
直接看文件。这是一份"生产风格"的 Pod 定义——应用容器加日志收集容器共生，共享一个卷，应用带存活探针：
# site.yaml —— 一份同时适用于本地与集群的 Pod 定义 apiVersion: v1 kind: Pod metadata: name: site spec: containers: - name: app image: docker.io/library/nginx:1.27-alpine ports: - containerPort: 80 volumeMounts: - name: logs mountPath: /var/log/nginx livenessProbe: httpGet: path: / port: 80 initialDelaySeconds: 5 periodSeconds: 10 - name: collector image: docker.io/library/alpine:3.19 command: ["sh", "-c", "tail -f /var/log/nginx/access.log"] volumeMounts: - name: logs mountPath: /var/log/nginx volumes: - name: logs emptyDir: {}
在本地执行它：
podman play kube site.yaml # Pod: site # Created pod: site # Created container: site-app # Created container: site-collector # 验证第 2.3 节讲的共生语义在"集群定义"下同样成立 podman exec site-collector wget -qO- http://127.0.0.1:80 | head -1 # <!DOCTYPE html> # collector 通过回环地址读到 app 的响应—— # YAML 里没写任何网络配置，共生是 Pod 的默认行为 # 验证健康探针在被本地执行 podman inspect --format '{{.State.Health.Status}}' site-app # healthy # livenessProbe 在本地按定义周期执行并记录状态
这份 YAML 的价值不在"本地能跑"，而在它就是集群要的那份文件。验证通过后原样提交给 K8s：Pod 拓扑、容器共生、探针行为、卷声明全部保持语义。本地调试与生产部署之间的翻译层（把 compose 的东西手工转成集群资源）不复存在。
生效与忽略：本地验证的结论边界
诚实列出字段级差异，这是"本地验证过"这句话的适用范围：
| YAML 字段 | 本地行为 | 结论边界 |
|---|---|---|
| containers、volumeMounts、volumes | 完整支持 | 本地结论可迁移 |
| livenessProbe | 执行并记录健康状态 | 集群里另有"不健康即重启"的联动，本地需自查 |
| ports、containerPort | 记录，发布需显式声明 | 集群的 Service 暴露方式本地不模拟 |
| resources（requests/limits） | 本地不强制调度语义 | 集群按它调度节点，本地不验证资源适配 |
| replicas、Deployment 层字段 | play kube 支持有限 | 多副本与滚动更新必须集群验证 |
| Service、Ingress | 仅 Service 的部分形式 | 集群网络入口形态本地不模拟 |
边界意识是这节最想留下的东西。play kube 验证的是 Pod 语义——容器怎么共生、配置怎么注入、探针怎么跑；它不验证 集群行为——调度、副本伸缩、服务发现。把验证结论限定在前者，这个工作流就极其可靠；越界使用它，就会得到"本地明明好好的"式的失望。
迭代循环：改 YAML、重放、看差异
本地开发的真实节奏是迭代。play kube 的工作流：
# 修改 YAML（比如给 app 加一个环境变量）后重放 podman play kube --replace site.yaml # --replace：先删除同名 Pod 再按新定义创建， # 类似"apply"的幂等体验 # 反向：本地调好的容器导出为 YAML（下节展开的工具） podman generate kube site > site-exported.yaml # 导出结果与手写版对比，能看出生成器对字段的取舍—— # 也是学习"哪些字段是集群必需"的低成本方式
一个完整案例：上线前夜的本地预演
背景：一个"应用加采集器"的服务要上生产集群，团队曾在 compose 环境验证过逻辑，但上集群时栽过跟头（采集器读不到应用日志，因为 compose 里两个容器网络不互通，靠挂载共享目录绕过）。操作：按目标集群的实际拓扑重写为上面的 Pod YAML（采集器与应用共 volume 加回环通信，与集群行为一致）；podman play kube 本地跑通，重点验证回环互访与日志落盘；把探针参数（initialDelaySeconds 从 15 调到 5，本地观察到应用两秒内就绪）回填 YAML；原样提交集群。结果：上线一次通过，此前栽跟头的日志链路按预期工作。解读：compose 验证的是"逻辑对不对"，kube YAML 本地验证的是"集群里怎么跑"——两者层次不同，后者的结论才能直接迁移到生产。变式：如果服务还有 ConfigMap 与 Secret，本地写成对应的 kind 段落，play kube 同样能建出本地副本，注入语义与集群一致。
本节要点回顾
- play kube 执行的是集群语言：一份 YAML 两边通用，翻译层消失
- 共生是默认：回环互通、共享卷，无需网络配置
- 验证结论有边界：Pod 语义可靠迁移，调度与副本必须集群验证
- --replace 给了幂等迭代：改定义、重放、看结果的工作流
- 探针本地执行但不联动：不健康后的动作本地不自动发生