适用场景：本文面向准备把应用部署到K8s生产环境的团队，重点讨论部署前后要补齐哪些平台能力，而不是给予单个命令教程。
K8s部署怎么落地，不能只看应用能否跑起来。生产环境真正要验证的是应用镜像、配置、权限、资源、网络、健康检查、监控告警和回滚流程是否形成闭环。如果只把YAML提交到集群，部署成功只能说明“这次运行起来了”，不能说明平台已经可治理。
很多团队第一次上K8s时，会把部署理解成编写Deployment、Service和Ingress。进入生产后，问题会变成：谁能发布，配置从哪里来，失败如何回滚，扩容是否受控，故障时如何定位，升级后怎么验证。
第1步：应用接入先建立部署底账
应用接入阶段的目标，是让平台知道这个应用是什么、归谁负责、依赖什么、使用哪些配置和资源。没有底账的K8s部署，后续排障和治理都会变成临时沟通。
接入时建议先确认：
- 应用名称、负责人、代码仓库和镜像仓库
- 镜像构建方式、版本规则和回滚版本保留策略
- 需要暴露的端口、协议和入口方式
- 配置、密钥、环境变量和依赖服务
- CPU、内存、存储和副本数需求
- 健康检查、启动探针和关闭行为
- 日志输出、指标暴露和告警责任人
这些信息不只是文档，也应该尽量沉淀到平台或流水线中。应用接入清楚后，后续CI/CD、观测、安全和发布治理才有共同对象。
第2步：环境准备要明确边界
K8s部署通常涉及开发、测试、预发布和生产环境。不同环境的权限、资源、网络、配置和审批规则不应混在一起。
| 准备项 | 需要确认的问题 | 风险 |
| 命名空间 | 应用放在哪个命名空间，谁能访问 | 多团队资源和权限混乱 |
| 资源配额 | CPU、内存、存储和副本是否有限额 | 应用互相抢资源 |
| 网络边界 | 服务暴露、Ingress、网关和网络策略是否清楚 | 内外部访问边界失控 |
| 配置密钥 | 配置来源、密钥管理和变更记录是否清楚 | 敏感配置误用或漂移 |
| 发布权限 | 谁能发布到生产，是否需要审批 | 高风险操作缺少留痕 |
环境准备不是一次性动作。随着团队增加，环境漂移会成为K8s部署的主要风险之一。平台应能持续显示环境差异和变更记录，而不是依靠人工比对。
第3步：发布验证不能只看Pod运行
Pod运行不代表应用发布成功。生产部署至少要结合健康检查、服务可访问、日志、指标、关键接口、告警和回滚能力做验证。
建议按以下顺序检查：
- 镜像版本是否正确
- Pod是否正常启动并顺利获得探针
- Service和入口是否可访问
- 关键配置和依赖是否加载正确
- 指标、日志和事件是否可查看
- 告警是否绑定到正确负责人
- 灰度或滚动发布策略是否按预期生效
- 回滚到上一个稳定版本是否可执行
发布验证的重点，是确认失败路径能被发现和收敛。如果部署失败后只能靠人工查命令、改YAML、重启Pod，平台还没有形成生产发布能力。
如果企业正在规划发布链路，可以结合 DevOps平台搭建怎么规划？4个阶段与验收项 ，把流水线、审批和回滚纳入统一评估。
第4步：持续运营决定部署是否可长期复制
一次K8s部署成功，并不等于后续所有应用都能稳定接入。持续运营阶段要关注升级、容量、安全、成本和故障复盘。
持续运营至少包含：
- 集群和节点升级计划
- 应用镜像漏洞扫描和修复节奏
- 资源利用率和容量趋势
- 告警降噪和故障复盘机制
- 发布记录、配置变更和操作审计
- 备份、恢复和灾备演练
- 多环境部署模板持续更新
这些能力决定K8s部署是否能从单个项目经验变成平台能力。否则每个应用都会重新摸索，平台团队也会被重复支持拖住。
K8s部署常见误区
误区1：把部署等同于写YAML。 YAML只是表达资源期望状态，生产部署还需要权限、环境、观测和回滚。
误区2：只验证成功路径。 真正要验证的是失败路径，包括镜像拉取失败、探针失败、配置错误、服务不可达和回滚失败。
误区3：忽略配置和密钥治理。 配置漂移、密钥暴露和环境变量误用，经常比工作负载本身更难排查。
误区4：缺少发布后观察。 发布完成后不观察指标、日志和告警，故障可能在用户侧先暴露。
POC或上线前可以用的检查口径
| 阶段 | 必须看到的证据 |
| 应用接入 | 应用元数据、负责人、镜像、配置、依赖和资源需求清楚 |
| 环境准备 | 命名空间、资源配额、权限、网络和密钥边界清楚 |
| 发布验证 | 健康检查、入口访问、日志指标、告警和回滚可验证 |
| 持续运营 | 升级、容量、安全、审计和故障复盘机制可执行 |
这份检查口径适合用于新应用接入，也适合用于评估现有K8s部署是否具备生产治理能力。
下一步建议
准备K8s部署时，建议先选一个中等复杂度应用做端到端验证。不要只验证能否启动，而要从接入、环境、发布、观测、回滚和运营6个角度检查证据是否完整。
如果团队已经有多个应用准备上K8s，可以先在 容器与Kubernetes分类 梳理容器平台选型、多集群、容器云平台和项目验收内容，再决定是否需要把部署能力升级为平台化能力。
常见问题
K8s部署最容易漏掉什么？
最容易漏掉的是失败路径和责任边界。很多团队能把应用部署成功，却没有验证镜像失败、配置错误、探针失败、服务不可达和回滚失败时如何处理。
K8s部署一定需要CI/CD平台吗？
不一定，但生产环境建议至少有可追踪的发布流程。CI/CD可以帮助沉淀镜像版本、测试结果、审批记录、部署状态和回滚证据，减少人工操作风险。
单集群部署和多集群部署有什么不同？
多集群部署会增加环境一致性、权限、镜像分发、网络入口、发布策略和观测聚合复杂度。单集群先把模板和流程实行，后续多集群治理会更容易。
K8s部署成功后还需要检查什么？
需要检查应用是否可访问，关键接口是否正常，日志和指标是否采集，告警是否生效，资源使用是否异常，以及是否能回滚到稳定版本。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：http://www.lygntwl.com/blog/180/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
