K8s集群部署步骤如果只理解为“执行初始化命令、复制join命令、看到节点Ready”，很容易在生产阶段踩坑。企业真正需要的是一套可复核的部署流程：每一步做什么、为什么做、失败时看哪里、完成后留下什么证据。

前置条件：本文聚焦生产化部署检查和验收口径，不替代具体版本的官方安装文档；实际命令需按操作系统、Kubernetes版本和容器运行时复核。

*图：生产化K8s集群部署应形成从环境检查到节点加入的证据链，避免只记录成功命令而缺少验收材料。*

步骤一：先做环境检查，不要急着初始化集群

K8s集群部署的第一步不是安装组件，而是确认环境是否能承载后续集群生命周期。很多部署失败表面发生在kubelet、网络插件或节点加入阶段，根因却是主机名、时间同步、内核参数、端口、DNS或镜像仓库准备不足。

环境检查至少覆盖以下方面：

• 节点角色规划：控制平面节点、工作节点、后续扩容节点是否明确
• 操作系统基线：内核版本、系统参数、swap、时间同步、主机名和解析关系是否满足要求
• 网络连通性：节点间必要端口、DNS、容器网络规划、负载均衡和访问入口是否清楚
• 容器运行时：containerd或其他运行时版本、配置和镜像拉取路径是否可用
• 镜像与制品：核心镜像、插件镜像、私有仓库和离线环境策略是否准备好
• 安全边界：SSH访问、sudo权限、防火墙、证书文件和审计要求是否有记录

这一阶段的输出不应只是“环境OK”。建议形成一份部署前检查表，记录节点清单、版本、网络段、镜像来源、端口开放、风险项和责任人。后续排障时，这份表能快速判断问题是部署操作导致，还是环境前提没有满足。

步骤二：准备运行时和基础组件

完成环境检查后，需要安装并配置容器运行时、kubelet、kubeadm和kubectl等基础组件。这里最容易出现版本不一致和配置漂移问题。生产部署中，控制平面节点和工作节点应保持明确的版本策略，避免某些节点临时安装了不同小版本，后续升级和排障困难。

运行时配置要重点关注两件事。第一是cgroup驱动与kubelet配置是否一致。第二是镜像拉取路径是否稳定，尤其是在内网、离线或受限网络环境中，需要提前准备镜像仓库和镜像同步策略。

基础组件准备完成后，建议保留以下证据：

• 节点上的组件版本记录
• 容器运行时状态和配置摘要
• kubelet服务状态
• 镜像仓库连通性验证
• 关键系统参数和时间同步状态

这些材料看似琐碎，但在集群初始化失败、节点NotReady或镜像拉取异常时，能显著减少排查时间。

步骤三：初始化控制平面，明确API入口和证书边界

控制平面初始化是K8s集群部署中的关键步骤。初始化前要明确API Server访问地址、证书SAN、Pod网段、Service网段、控制平面高可用方式和后续扩容策略。测试环境可以临时使用单节点控制平面，生产环境则需要提前考虑高可用、备份和升级路径。

初始化时不要只复制一条命令。建议把初始化参数写入配置文件，并纳入变更记录。配置文件比长命令更容易复核，也更适合团队协作。

初始化完成后，应检查以下结果：

• API Server、Controller Manager、Scheduler和etcd等核心组件状态
• kubeconfig是否仅分发给授权人员或系统
• 证书有效期、证书路径和备份策略是否记录
• 控制平面节点事件是否存在异常
• 集群版本、Pod网段和Service网段是否符合规划

控制平面初始化完成，不等于集群可用；只有核心组件稳定、API入口明确、证书和访问权限可控，才算进入下一步。

步骤四：安装网络插件，验证Pod和Service连通性

没有容器网络，节点状态和Pod调度都会受到影响。网络插件选择取决于性能、网络策略、运维能力、现有网络环境和安全要求。部署时不要只看插件是否安装成功，还要验证Pod之间、Pod到Service、Pod到外部系统的访问路径。

建议用一个最小测试工作负载验证网络：

1. 在不同节点上调度多个Pod

2. 测试Pod之间跨节点通信

3. 创建Service并验证ClusterIP访问

4. 验证DNS解析是否正常

5. 如启用NetworkPolicy，测试允许和拒绝规则是否生效

网络问题往往在应用接入后才暴露，因此部署阶段要尽早留下验证证据。对于金融、制造、央国企或多网络域场景，还要额外确认网络隔离、出口访问、审计和安全策略如何落地。

步骤五：加入工作节点，不只看Ready状态

节点加入通常顺利获得kubeadm生成的join命令完成。很多团队看到节点变成Ready就认为部署结束，但生产化验收还要继续检查节点标签、污点、资源容量、运行时状态、系统服务和日志。

节点加入后建议逐项确认：

加入节点还要考虑后续扩容。建议把节点加入步骤固化为脚本或标准操作手册，但脚本中不能包含未保护的token、私钥或生产密码。join token也应按安全策略管理，避免长期暴露。

步骤六：配置存储、Ingress和基础权限

集群节点可用后，才进入平台能力补齐阶段。企业生产集群通常还需要持久化存储、Ingress或网关、证书管理、镜像仓库访问、Namespace规划、RBAC权限和资源配额。缺少这些能力，应用即使能跑，也很难稳定进入生产。

存储需要验证PV/PVC创建、绑定、挂载、扩容和故障恢复路径。Ingress或网关需要验证域名、证书、路由、超时、访问日志和安全策略。权限需要按团队、环境和操作类型分层，避免所有人共享集群管理员权限。

这一阶段建议不要一次性开放给所有业务团队。先选择低风险应用进行接入，验证平台能力和流程后，再扩大范围。

步骤七：做部署验收，形成可交接证据

K8s集群部署完成后，验收应回答“是否可以进入应用接入和长期运营”，而不是只回答“安装是否成功”。验收材料建议分成5类。

• 环境证据：节点清单、版本、网络、运行时、系统参数
• 集群证据：控制平面状态、节点状态、组件状态、证书和kubeconfig管理
• 能力证据：网络、DNS、存储、Ingress、权限、镜像拉取和资源配额
• 演练证据：应用部署、扩缩容、滚动更新、节点异常、Pod异常和恢复测试
• 交接证据：操作手册、应急联系人、备份策略、升级策略和监控告警说明

如果缺少这些证据，后续应用团队遇到问题时只能依赖部署人员记忆。对于企业级容器云平台建设，证据链本身就是交付质量的一部分。

常见部署风险和处理边界

K8s集群部署常见风险并不神秘，但经常被低估。

版本风险：Kubernetes、运行时、操作系统和插件版本之间存在兼容边界。升级或安装前应确认支持矩阵，避免临时拼装。

网络风险：Pod网段、Service网段、宿主机网络和企业现有网络可能冲突。冲突一旦进入生产，回滚成本高于前期规划成本。

权限风险：部署人员为了省事使用过高权限，后续缺少审计和最小权限控制。生产集群应尽早建立RBAC和访问记录。

运维风险：没有备份、监控、告警和升级策略的集群，即使初始部署成功，也会在第一次故障或版本生命周期问题中暴露短板。

下一步建议

如果团队刚完成K8s集群部署，建议先不要急着大规模接入业务。先选择一个低风险应用验证网络、存储、Ingress、权限、日志、监控和回滚流程，并把验证结果沉淀为标准接入模板。

如果团队正在从测试集群走向生产集群，下一步应评估是否需要企业级容器平台来统一多集群、权限、应用交付、安全合规、可观测和运维流程。单次部署解决的是“集群能不能起来”，平台化建设解决的是“多个团队能不能长期、安全、稳定地使用”。

常见问题

K8s集群部署完成后，节点Ready就算成功吗？

不算。Ready只能说明节点与控制平面基本通信正常，还需要验证网络、DNS、镜像拉取、存储、Ingress、权限、监控、告警和应用发布。生产环境还要检查证书、备份、升级和交接材料。

kubeadm适合生产部署吗？

kubeadm可以用于构建符合Kubernetes标准的集群，但生产可用性取决于高可用设计、网络存储选型、证书管理、备份恢复、升级维护和运维流程。工具本身不是完整平台，企业仍需补齐长期运营能力。

节点加入失败通常先排查什么？

优先检查时间同步、主机名解析、端口连通、token和证书哈希、kubelet状态、容器运行时状态、镜像拉取和防火墙策略。不要只重复执行join命令，应先看kubelet日志和节点事件。

生产部署是否必须一次完成高可用？

如果集群承载生产业务，控制平面高可用、etcd备份和恢复策略应在上线前明确。小规模试点可以先限制范围，但必须写清楚风险、升级路径和不可承载的业务边界。