K8s怎么部署应用？从镜像、Deployment到Service暴露

K8s怎么部署应用？标准流程不是把代码直接放进集群，而是先构建容器镜像，再用 Deployment 描述应用副本和发布策略，用 Service 提供稳定访问入口，并配合配置、密钥、健康检查和日志监控完成上线验证。读完本文，你可以把一次应用部署拆成可检查、可回滚、可交付的几个关键步骤。

本文适用场景

这篇文章适合三类读者：

• 刚开始把 Java、Go、Node.js 或 Python 应用迁移到 Kubernetes 的研发团队
• 需要把容器镜像、Deployment、Service 串起来的 DevOps 工程师
• 正在建设企业容器平台，希望统一应用交付流程的平台团队

如果只是本地试验，一个简单 YAML 就能跑起来；但在企业生产环境里，部署应用还要考虑配置变更、实例健康、版本回滚、访问控制、日志采集和权限边界。

一次完整的K8s应用部署包含哪些环节

可以把 K8s 部署应用理解为六个连续动作：

1. 构建镜像：把应用代码和运行时依赖打包成容器镜像。
2. 推送镜像仓库：把镜像推到企业镜像仓库，供集群节点拉取。
3. 编写工作负载声明：通常使用 Deployment 描述副本数、镜像版本和更新策略。
4. 注入配置和密钥：通过 ConfigMap、Secret 或平台配置中心管理环境差异。
5. 暴露服务访问入口：用 Service 提供集群内稳定访问，用 Ingress 或网关提供外部访问。
6. 验证和观测：检查 Pod 状态、接口可用性、日志、指标和告警。

第一步：准备可交付的容器镜像

Kubernetes 调度的不是源码，而是镜像。企业团队应把镜像作为交付物管理，而不是临时构建、临时上传。

好的镜像至少满足几个要求：

• 镜像标签能对应代码版本、构建流水线和发布记录
• 基础镜像来源可控，避免引入未知漏洞
• 镜像体积尽量精简，减少拉取时间和攻击面
• 不把密码、Token、私钥等敏感信息写入镜像
• 通过企业镜像仓库统一扫描、签名和分发

很多部署故障并不是 Kubernetes 本身造成的，而是镜像版本不可追踪、配置混进镜像、构建环境不一致导致的。上线前先把镜像治理做好，后续排障会简单很多。

第二步：用Deployment描述应用运行状态

Deployment 是大多数无状态应用上 Kubernetes 的首选对象。它关心的不是“执行一次启动命令”，而是持续维持一组 Pod 处于期望状态。

Deployment 通常负责：

• 指定应用镜像版本
• 设置副本数量
• 管理滚动更新
• 通过 ReplicaSet 维护 Pod
• 在发布异常时回滚到旧版本

生产环境里不要只写镜像名和端口，还应补齐资源规格、健康检查和更新策略。尤其是 readinessProbe，它决定 Pod 是否可以接流量；如果没有就绪探针，应用进程刚启动但依赖还没准备好时，流量可能已经进入，造成短暂故障。

第三步：用Service提供稳定访问入口

Pod 是会重建和漂移的，IP 不稳定。因此应用之间不能直接依赖 Pod IP，而要通过 Service 访问。

Service 的核心价值是：

• 给一组 Pod 提供稳定名称和虚拟 IP
• 根据标签选择后端 Pod
• 在多个副本之间做基础负载均衡
• 让调用方不关心 Pod 如何重建和迁移

常见类型包括 ClusterIP、NodePort、LoadBalancer。多数企业内部服务使用 ClusterIP，外部访问再通过 Ingress、API 网关或负载均衡器统一接入。

第四步：处理配置、密钥和环境差异

应用真正进入生产环境后，开发、测试、预发、生产往往使用不同数据库、消息队列、第三方接口和开关配置。不要为每个环境构建一套不同镜像，而应把配置外置。

常用方式包括：

• ConfigMap 管理普通配置
• Secret 管理敏感配置
• 环境变量注入运行参数
• 挂载配置文件到容器内
• 通过平台配置中心或 GitOps 管理变更

需要注意的是，Secret 不是万能保险箱。企业生产环境仍应结合权限控制、审计、密钥轮换和外部密钥系统，避免所有人都能查看敏感配置。

第五步：上线前做发布验证

应用部署后不能只看 Pod 处于 Running，还要看业务是否真的可用。建议至少检查：

• Deployment 是否达到期望副本数
• Pod 是否 Ready
• Service 是否能解析和访问
• Ingress 路由是否命中正确服务
• 日志中是否有启动异常
• 关键接口是否通过健康检查
• 监控指标是否出现异常波动

如果发布接入了流水线，最好把这些检查固化为自动化门禁，而不是靠人工逐项登录集群查看。

企业环境里还要补哪些能力

单个应用部署成功只是第一步。企业真正需要的是可复制的应用交付体系：

• 镜像仓库、扫描和准入控制
• 多环境部署模板
• 命名空间和权限隔离
• 发布审批和审计
• 统一日志、监控和告警
• 回滚、灰度和版本追踪
• 多集群分发和灾备能力

这也是为什么企业通常不会只给研发一个裸 Kubernetes 集群，而是建设容器平台或平台工程能力。像灵雀云 ACP 这类企业级容器平台，更适合把部署流程、权限治理、多集群管理和可观测能力沉淀为统一入口，减少每个团队重复搭建。

常见误区

误区一：能跑起来就等于部署成功

进程启动只是最低标准。生产部署还要看服务可访问、配置正确、依赖可用、资源稳定、告警正常。

误区二：所有环境共用一套手写YAML

手写 YAML 容易复制粘贴出错。企业更适合使用模板化、流水线或平台化交付方式统一管理差异。

误区三：只关注Deployment，不关注Service和Ingress

应用部署不是孤立的工作负载声明，还包括访问入口、路由规则、证书、域名和流量治理。

部署前需要准备哪些前置条件

K8s 部署应用不是把镜像地址写进 YAML 就结束。发布前应准备好镜像仓库、命名空间、资源规格、环境变量、配置、Secret、健康检查、访问方式和回滚策略。缺少这些前置条件，应用可能能启动，但无法稳定对外服务。

建议发布前检查：

1. 镜像是否来自可信仓库，并使用明确版本号。
2. Deployment 是否设置副本数、资源 Request 和 Limit。
3. readinessProbe 和 livenessProbe 是否符合业务健康判断。
4. ConfigMap 和 Secret 是否按环境拆分。
5. Service、Ingress 或网关是否符合访问模型。
6. 日志、指标和告警是否能覆盖发布后的异常。

教程类部署文章的关键不是命令能跑通，而是读者能知道每一步为什么做、做完如何验证。

部署后如何验证是否成功

部署完成后应按三层验证：先看 Deployment 是否滚动完成、Pod 是否 Ready、事件是否异常；再看 Service 是否有 Endpoint、集群内是否能访问；最后看 Ingress 或网关入口是否能从外部访问，并检查日志和监控是否正常。

如果出现失败，优先查看 kubectl describe 的事件、Pod 日志、镜像拉取状态、探针失败原因和资源不足情况。不要只重复 apply，同一个错误配置重复提交不会解决问题。

结语

K8s部署应用的核心链路是：镜像交付、Deployment 编排、Service 暴露、配置注入和上线验证。对于个人学习，掌握这些对象就能跑通基本流程；对于企业生产环境，更重要的是把这些步骤变成标准化、可审计、可回滚的交付体系。

FAQ

K8s部署应用一定要用Deployment吗？

大多数无状态业务应用建议使用 Deployment，因为它支持副本管理、滚动更新和回滚。如果是有状态服务，可以考虑 StatefulSet；如果是一次性任务，可以使用 Job 或 CronJob。

Service和Ingress有什么区别？

Service 主要解决集群内部服务发现和稳定访问问题，Ingress 主要解决 HTTP/HTTPS 外部入口、域名和路径路由问题。实际生产中通常二者配合使用。

为什么Pod Running了业务还是不能访问？

可能是容器进程启动但业务未就绪、Service 标签选择器不匹配、端口配置错误、Ingress 路由错误、网络策略限制或后端依赖异常。排查时不要只看 Pod 状态，要同时看事件、日志和访问链路。

企业部署K8s应用最应该先标准化什么？

建议先标准化镜像命名、资源规格、健康检查、配置管理、发布流水线和回滚流程。这些能力决定应用能否稳定进入生产，而不是只在测试环境跑起来。