8.2 与 K8s 生态的协同
8.2 与 K8s 生态的协同
本节摘要：Podman 与 Kubernetes 生态的协同不止 play kube：generate kube 反向把本地容器导出为 YAML，是迁移与文档化的利器；与 CRI-O 的同源关系（共享 libpod 血统）带来"本地与集群运行时行为一致"的工程价值。本节把正向、反向、同源三层协同讲完，并给出"compose 还是 kube YAML"的路线判断，以及本地模拟不了的东西的诚实清单。
反向桥梁：generate kube
8.1 节是"集群定义进本地"，generate kube 是反方向——"本地容器出集群定义"：
# 把一个调好的本地容器导出为 YAML podman generate kube myapp > myapp.yaml # 输出是一份标准结构的 Pod（或含 Service）定义： # 容器镜像、命令、环境变量、端口、卷挂载都被翻译进 YAML # 导出后立刻回放，验证往返一致性 podman play kube myapp.yaml # 回放行为与原容器一致——往返闭环说明两套表示等价 # 服务化部署也可以直接吃这个文件（第 7 章的 Quadlet 族） # .kube 单元让 systemd 管理 play kube 负载： # [Kube] # Yaml=/home/dev/myapp.yaml
generate kube 的三个真实用途。其一，迁移：Docker 时代积累的容器配置，在 Podman 里跑顺后导出为 YAML，直接进集群评审流程。其二，文档化：容器的"真实运行配置"（含后来手动 exec 改过又想固化的部分没法导出，但启动配置可以）变成可评审的文本。其三，学习：导出结果与手写 YAML 对比，是最直观的"集群需要什么字段"教材。局限也明确：它只能导出"当前配置"，镜像外的东西（依赖关系、探针语义）要自己补。
同源关系：CRI-O 与 Podman 的血缘
CRI-O 是 Kubernetes 专用的容器运行时（实现 K8s 的 CRI 接口），它与 Podman 的关系常被一句话带过："都是 Red Hat 做的"。准确的说法是：两者共享同一套核心库（libpod 系）与存储栈（containers/storage），Podman 里管理 Pod、镜像、存储的代码与 CRI-O 里做同样事情的代码大量重合。
这个血缘的工程价值在"行为一致性"：本地 play kube 跑的 Pod，与集群里 CRI-O 跑的 Pod，在镜像处理、层管理、卷语义这些底层行为上来自同一份实现。对比另一种常见组合（本地 Docker、集群 containerd），底层是两套独立实现，偶尔出现"本地拉取正常、集群报镜像层校验错"这类诡异差异。同源不等于全同（CRI-O 走的是 K8s 的调度与生命周期，Podman 是用户直驱），但底层行为的确定性让"本地验证的结论"多了一层保障。
路线判断：compose 还是 kube YAML
多容器项目的编排描述文件该用哪个？给一个决策框架：
- 纯本地开发工具链、不上集群：compose 兼容层（podman-compose）够用，团队熟悉成本低
- 目标是集群、本地只是预演：直接 kube YAML 加 play kube，避免翻译层
- 混合期（部分服务上云、部分留本地）：核心服务用 kube YAML 管理，外围工具用 compose，Quadlet 的 .kube 与 .container 单元可以在同一台机器上混编
- 编排复杂度走高（多副本、滚动更新、服务发现）：这些已经不是"本地编排"问题，该上真集群或轻量发行版，本地只保留单 Pod 验证
判断的轴不是哪个工具更好，而是你的部署终点在哪。终点是集群就尽早说集群的语言；终点是本机就别为了"显得云原生"提前背 YAML 的包袱。这条判断轴还有个时间维度：部署终点会漂移。今年纯本地的工具链，明年可能因为要接公司平台而被迫上集群——提前把"终点可能变化"写进决策记录，到时候的迁移就只是执行既定预案，而不是临时抱佛脚。
诚实清单：本地永远模拟不了的
把 8.1 节的边界清单扩成完整版：多副本调度与节点亲和（需要真实集群的多节点拓扑）；Service 的负载均衡与集群 IP（本地只有端口映射近似）；滚动更新与回滚（Deployment 控制器行为）；HPA 伸缩；网络策略（NetworkPolicy 的执行）；RBAC 与命名空间隔离。这些能力属于"集群作为分布式系统"的那一面，单机工具原则上不该也无法模拟。本地能可靠验证的始终是 Pod 以内的世界——这行字值得写在每个 play kube 工作流的文档开头。
一个完整案例：compose 项目的双轨过渡
背景：一个八服务的内部平台长期用 compose 文件维护，团队决定把其中三个核心服务迁上集群，剩下五个工具型服务继续留在一台虚机上。操作：先把三个核心服务从 compose 文件里拆出来，逐个改写为 Pod YAML（照 8.1 节的模板，补上探针与资源字段），本地 play kube 验证两周；虚拟机侧的五个服务留在 compose 兼容层，但把 compose 文件与三份 YAML 收进同一个版本库的两个目录；给虚机上的五个服务配 Quadlet 的 compose 启动单元（.container 族之外也可以直接 systemd 管理 compose 兼容层的 up 命令）。结果：核心服务上集群一次通过，两套描述文件在同一个仓库里各自演进、互不干扰，新人看目录结构就能理解"哪些是集群负载、哪些是本地负载"。解读：双轨过渡的关键动作不是技术转换，而是"资产分家"——把要上云的与要留下的显式分开管理，避免一个混合文件两头都要改。变式：如果五个本地服务将来也要上集群，按同一流程每次搬一两个，每次搬运都是一次独立的验证周期，不追求一次到位。
本节要点回顾
- generate kube 是反向桥：本地容器导出集群定义，迁移、文档、学习三用途
- 往返闭环：generate 出的 YAML 能被 play kube 无损回放
- CRI-O 与 Podman 同源：共享 libpod 与存储栈，底层行为一致
- 编排文件按终点选：终点集群就早用 kube YAML，终点本机就别硬背
- 本地验证的边界是 Pod 以内：调度、副本、网络策略属于集群的世界