前置条件：本文面向准备搭建测试、预生产或生产K8s集群的团队。重点不是复制命令，而是把部署拆成可检查、可验收、可复盘的7个阶段。
K8s集群部署看起来是安装控制面、加入节点、安装网络插件和验证Pod运行，但生产环境真正关心的是另一组问题：集群规模怎么定，节点角色如何规划，网络和存储是否满足业务，证书和权限如何管理，监控日志是否接入，故障时如何恢复，后续升级由谁负责。
如果只按教程执行命令，集群可能当天可用，但后续扩容、排障、升级和安全加固都会变成隐患。
第一步：明确集群用途和验收标准
部署前先确认集群用途。不同用途决定不同架构：开发测试集群可以简化高可用要求，预生产集群要尽量接近生产，生产集群则必须考虑控制面高可用、备份恢复、监控告警、安全边界和升级策略。
建议先回答以下问题：
- 集群服务哪些应用和团队
- 预计节点数量、Pod数量和业务峰值是多少
- 是否需要多可用区、高可用控制面或多集群架构
- 是否承载有状态应用、AI任务或关键业务
- 是否已有镜像仓库、监控、日志、CI/CD和权限体系
- 验收时如何判断集群可以进入生产
没有这些答案，部署命令本身没有意义。平台团队应把集群部署视为工程项目，而不是一次安装任务。
第二步：完成节点与操作系统前置检查
节点准备是K8s部署质量的基础。很多集群问题不是安装过程造成的，而是主机命名、时间同步、内核参数、磁盘规划、运行时版本和网络策略在前置阶段没有统一。
前置检查建议覆盖：
| 检查项 | 需要确认的内容 |
| 主机规划 | 主机名、IP、角色、可用区和管理网段清晰 |
| 时间同步 | 所有节点时间一致，避免证书和日志时间错乱 |
| 系统版本 | OS、内核、容器运行时和K8s版本兼容 |
| 磁盘规划 | 系统盘、镜像盘、日志盘和数据盘容量明确 |
| 安全策略 | 防火墙、端口、SELinux或等效策略符合要求 |
| 账号权限 | 安装账号、运维账号和审计要求明确 |
节点检查不要依赖人工口头确认。建议形成脚本化检查和记录，至少留下节点清单、版本清单、端口清单和磁盘容量证据。生产环境中，前置检查本身就是验收材料的一部分。
第三步：规划网络、域名和访问路径
K8s网络包括Pod网络、Service网络、节点网络、Ingress或网关访问，以及与外部系统的连接。部署前必须规划网段，避免与现有机房、云上VPC、VPN或办公网络冲突。
需要确认的网络问题包括：
- Pod CIDR和Service CIDR是否与现有网络冲突
- 节点之间是否允许必要端口通信
- 是否需要跨机房、跨云或多集群互通
- Ingress、负载均衡、DNS和证书由谁管理
- NetworkPolicy是否作为安全隔离手段启用
- 日志、监控、镜像仓库和外部依赖访问路径是否清晰
网络规划不能等到应用上线时再补。很多“应用部署成功但访问失败”的问题，本质是Service、Ingress、DNS、负载均衡和安全策略没有在集群建设阶段统一设计。
第四步：安装控制面并保护关键组件
控制面是K8s集群的大脑，包含API Server、Scheduler、Controller Manager和etcd等关键组件。测试环境可以单控制面起步，生产环境则应考虑高可用、证书管理和etcd备份。
控制面部署后应重点验证：
- API Server可访问且证书有效
- 控制面组件状态正常
- etcd健康状态和备份机制明确
- kubeconfig权限和分发范围受控
- 审计日志、认证授权和准入策略有规划
- 控制面节点资源、磁盘和网络有监控
不要把“kubectl get node能返回结果”当作控制面验收。真正的控制面验收应包含高可用、备份、权限、证书和审计。尤其是etcd，必须明确备份频率、备份位置、恢复演练和责任人。
第五步：加入工作节点并验证调度能力
工作节点加入后，需要验证的不只是节点Ready，还要确认Pod能被正确调度、镜像能被拉取、网络能互通、资源请求能被识别、节点标签和污点符合预期。
建议逐项验证：
- 所有节点状态为Ready
- 节点角色、标签和污点符合规划
- 测试Pod可以跨节点调度
- 镜像仓库访问正常
- Pod之间、Pod到Service、Pod到外部依赖通信正常
- 资源请求与限制能影响调度和容量评估
如果集群后续会承载不同团队或不同业务等级，还应提前规划节点池。不要把所有节点放在一个无差别资源池里，否则后续很难做关键业务隔离、AI任务隔离、测试生产隔离或故障域控制。
第六步：安装基础插件和平台能力
K8s裸集群只是基础。要进入企业使用，还需要网络插件、存储插件、Ingress或网关、监控、日志、镜像仓库、证书管理、DNS、权限管理和备份能力。缺少这些能力，应用上线后会频繁遇到“能部署但不好运维”的问题。
基础插件建议按优先级推进：
1. 网络插件：支撑Pod通信和网络策略
2. 存储插件：支撑PVC和有状态应用
3. Ingress或网关：支撑外部访问和流量治理
4. 监控日志：支撑指标、日志、事件和告警
5. 镜像仓库：支撑制品分发、安全扫描和版本追踪
6. 权限与审计：支撑多团队隔离和操作追踪
7. 备份恢复：支撑关键资源和数据恢复
这些插件不是越多越好。每一项都应有负责人、版本策略、升级路径和故障处理方式。否则插件本身也会成为平台风险。
第七步：生产验证和交接
集群部署完成后，必须做生产验证。验证内容应覆盖功能、稳定性、安全、可观测、备份和运维交接。
建议用以下清单作为最低验收：
| 验收维度 | 验收问题 |
| 基础功能 | Pod、Service、Ingress、PVC是否可用 |
| 高可用 | 控制面、节点、关键插件是否有冗余设计 |
| 安全权限 | RBAC、Namespace、审计和Secret管理是否生效 |
| 可观测 | 指标、日志、事件和告警是否覆盖关键组件 |
| 备份恢复 | etcd、配置资源和关键数据是否可恢复 |
| 发布验证 | 示例应用能否滚动发布、回滚和扩缩容 |
| 运维交接 | 账号、文档、应急流程和责任边界是否清楚 |
生产验证的意义是让集群从“安装成功”变成“可以承担业务”。如果验证只停留在部署示例应用，后续业务上线时仍然会把问题暴露给应用团队。
常见误区：把K8s部署当成一次性安装
K8s集群部署最常见的误区是忽略生命周期。集群不是装完就结束，后续还要升级、扩容、证书更新、插件维护、漏洞修复、容量调整和故障演练。
第二个误区是只关注控制面安装。很多生产问题发生在网络、存储、镜像仓库、日志、监控和权限边界上，而不是API Server本身。
第三个误区是没有验收文档。没有验收文档，后续问题很难判断是部署缺陷、应用问题还是运维流程问题。平台团队应把部署过程、配置版本、检查结果和遗留风险记录下来。
下一步建议
如果你正在准备部署K8s集群，建议先把本文7步转换成项目检查表：用途和验收、节点准备、网络规划、控制面、工作节点、基础插件、生产验证。每一步都留下证据，而不是只记录“已完成”。
对于企业生产环境，更建议把集群部署纳入容器平台建设：统一镜像仓库、权限体系、可观测、发布流水线和运维流程。这样K8s集群才不是孤立基础设施，而是应用交付、平台工程和云原生治理的共同底座。
延伸阅读可以查看容器与Kubernetes分类，并对照K8s集群部署步骤和部署K8s集群选型区分安装流程、部署方式与生产验收口径。
FAQ
K8s集群部署需要几台服务器？
测试环境可以从少量节点起步，生产环境通常需要考虑控制面高可用、工作节点冗余和故障域隔离。具体数量取决于业务规模、可用性要求、资源水位和运维能力，不应只按教程最低配置决定。
K8s部署成功后为什么应用仍然不可用？
常见原因包括Service选择器错误、Ingress或DNS未配置、网络策略限制、镜像仓库不可达、存储挂载失败、探针配置不当或应用自身依赖未准备好。集群Ready不代表应用路径全部可用。
生产K8s集群最重要的验收项是什么？
至少应覆盖控制面健康、etcd备份、节点调度、网络连通、存储挂载、镜像拉取、权限审计、监控告警、日志采集和示例应用发布回滚。缺少这些项，后续运维风险会明显增加。
自建K8s和托管K8s部署流程一样吗？
目标相似，但责任边界不同。托管K8s通常减少控制面安装和维护责任，自建K8s则需要团队负责控制面、etcd、证书、升级和底层节点运维。企业应按团队能力和合规要求选择。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：http://www.zghgdz.com/blog/467/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
