Kubernetes 集群部署方案全景解析

在容器化应用落地的过程中，集群如何部署往往是第一个需要决策的问题。部署方案的选择不仅影响初期的搭建效率，更决定了后续的运维复杂度、故障恢复能力和横向扩展空间。本文从部署形态、架构要素与典型故障处置三个维度，对主流部署方案进行系统梳理，并给出可落地的实践建议。

一、部署方案的分类维度

讨论”有哪些方案”之前，先明确分类的维度，否则容易陷入工具名称的罗列。通常可以从以下几个角度划分：

• 部署形态：单节点、多节点自建、托管式集群服务
• 组件管理方式：由安装工具统一引导，还是逐组件手工部署
• 控制面高可用能力：单控制面、多控制面加负载均衡
• 运维责任边界：用户自管全部组件，还是仅管理工作负载

不同的组合对应不同的适用场景。下面按从轻到重的顺序展开。

二、轻量级单机方案：适合开发与验证

开发者在本地快速验证编排能力时，通常不需要完整的多节点集群。此类方案的特点是安装快、资源占用低，但控制面与工作负载共享同一台机器，不具备高可用能力。

常见的实现路径包括在单机上运行轻量发行版，或使用容器内运行集群组件的方式。这类方案的核心价值在于降低学习门槛，让开发者能在几分钟内获得一个可用的 API Server 与调度器。需要注意的是，单机方案中的网络插件、存储插件往往做了简化，与生产环境的差异较大，不适合直接作为上线前的验证环境。

适用场景：本地开发、CI 中的集成测试、教学演示。
不适用场景：性能压测、多节点调度策略验证、高可用演练。

三、工具引导式多节点部署：自建集群的主流选择

当需要一套多节点集群时，使用安装工具引导是最常见的方式。这类工具负责证书生成、组件配置下发、网络插件安装等繁琐步骤，将部署过程收敛为若干条命令。

3.1 引导式部署的典型流程

以业界普遍采用的方式为例，流程大致分为：环境预检、初始化第一个控制面节点、加入其余控制面节点、加入工作节点、安装网络与存储插件。

# 初始化控制面（示意）
kubeadm init --control-plane-endpoint "<lb-endpoint>:6443" \
  --pod-network-cidr=10.244.0.0/16
# 工作节点加入集群（示意）
kubeadm join "<lb-endpoint>:6443" --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

引导式方案的优势在于标准化程度高、升级路径清晰。多数工具支持 plan 之类的预检子命令，能在真正变更前暴露版本偏差、端口占用、内核参数缺失等问题。

3.2 高可用控制面的关键设计

多控制面节点必须解决两个问题：API Server 的访问入口统一，以及数据面的一致性。

• 入口统一：在多个 API Server 前置负载均衡，对外暴露单一端点。负载均衡需支持 TCP 层转发与健康检查，避免单点。
• 数据一致性：控制面的状态存储采用集群化部署，节点数量通常取奇数以满足仲裁要求。生产环境建议至少三个节点，跨故障域分布。
• 证书管理：多控制面场景下证书需在各节点间正确分发，引导工具通常会自动处理，但扩容控制面节点时需要确认证书有效期与 SAN 列表是否覆盖新增端点。

3.3 二进制手工部署：可控性优先

另一条路径是逐组件部署：分别安装 API Server、调度器、控制器管理器、kubelet 与容器运行时，自行编写服务单元与配置文件。这种方式对细节的掌控最强，便于针对特定内核版本、安全基线或离线环境做定制，但代价是运维成本高、升级需人工介入、出错面广。

适用场景：对组件版本、启动参数有强定制需求，或有严格合规审计要求的环境。对多数团队而言，引导式方案的投入产出比更优。

四、托管式集群服务：把控制面交给平台

托管方案将控制面组件的运维责任转移给云平台，用户只需创建节点池并提交工作负载。其优势体现在：

• 控制面高可用、版本升级、证书轮换由平台保障
• 与云上网络、存储、监控告警等通用能力天然集成
• 节点池支持弹性伸缩，按需扩缩容

需要权衡的是：控制面的可定制参数相对受限，部分高级调度特性或准入控制策略的调整空间较小；跨云或混合云场景下还需考虑网络打通与一致性管理。

选型时可从三个问题入手：团队是否具备控制面运维能力？业务对控制面参数定制的需求有多强？是否存在跨环境统一管理的诉求？

五、部署方案之外：节点稳定性是长期课题

无论选择哪种方案，集群上线后都会面对同一类问题——节点状态异常。其中”节点变为 NotReady、其上工作负载被驱逐”是发生率最高的故障之一，值得在方案设计阶段就把预防措施配好。

5.1 故障表现与根因排序

典型现象是某个工作节点状态突然变为 NotReady，其上的 Pod 陆续出现 Evicted 或被重新调度到其他节点，业务出现短时抖动。触发机制是 kubelet 未能 在约定时间内向 API Server 上报心跳，节点被判定为不可用。

实际根因按出现频率大致排序如下：

根因	占比特征	识别线索
节点磁盘耗尽	最常见	镜像目录或日志目录所在分区写满
kubelet 进程被 OOM 杀死	常见	内核日志中存在 OOM 记录
节点与 API Server 网络不通	偶发	健康检查端点无法访问
kubelet 进程崩溃	较少	服务状态显示 failed

5.2 排查流程

登录问题节点后建议按以下顺序推进，先排除高频项：

# 第一步：服务状态与近期日志
systemctl status kubelet
journalctl -u kubelet --since "1 hour ago" | tail -200
# 第二步：磁盘使用率（最高频根因）
df -h
du -sh /var/lib/containerd   # 镜像与容器层
du -sh /var/lib/kubelet      # Pod 数据
du -sh /var/log              # 系统日志
# 磁盘满时的清理动作
crictl rmi --prune                                  # 清理悬空镜像
crictl rm $(crictl ps -a -q --state exited) 2>/dev/null  # 清理已退出容器
# 第三步：内存与 OOM 记录
free -h
dmesg | grep -i "oom" | tail -20
# 第四步：到 API Server 的连通性
curl -k https://<apiserver-ip>:6443/healthz
# 根因处理完毕后重启 kubelet
systemctl restart kubelet

排查顺序的设计逻辑是：磁盘问题占比最高且清理动作相对安全，优先处理；内存与网络问题需要更多判断，放在其后；进程崩溃通常有明确日志，易于定位。

5.3 预防配置：让驱逐先于崩溃发生

与其等节点彻底不可用再介入，不如让 kubelet 在资源紧张时主动驱逐部分 Pod，保留节点本身的可用性。这通过驱逐阈值配置实现：

# /var/lib/kubelet/config.yaml
evictionHard:
  memory.available: "200Mi"    # 可用内存低于阈值开始驱逐
  nodefs.available: "10%"      # 节点文件系统剩余不足时驱逐
  nodefs.inodesFree: "5%"      # inode 剩余不足时驱逐
  imagefs.available: "15%"     # 镜像存储剩余不足时驱逐

几个配置要点：

• 软阈值与硬阈值可配合使用。硬阈值触发立即驱逐，软阈值给予一段宽限期，适合对抖动敏感的业务。
• 阈值应结合节点规格设定。内存阈值设得过低会导致驱逐滞后，过高则频繁误驱逐。
• 镜像存储与节点文件系统若位于不同分区，需分别配置，否则可能出现镜像盘已满但节点盘正常的误判。
• 配置变更后需重启 kubelet 生效，建议纳入节点初始化的标准化流程，而非故障后的补救措施。

六、方案选型的实践建议

综合来看，部署方案的决策可以归纳为一条渐进路径：

1. 开发验证阶段：选用轻量单机方案，追求启动速度。
2. 预发与小规模生产：采用引导式工具部署多节点集群，控制面三节点起步，网络与存储插件按业务特性选择。
3. 规模化生产：在自建与托管之间权衡。若团队具备控制面运维能力且有深度定制需求，可延续自建并完善监控告警、备份恢复与升级演练；若希望聚焦业务、降低运维负担，托管方案更为合适。
4. 无论何种方案：将节点资源水位监控、驱逐阈值配置、日志轮转策略作为集群交付的标准组成部分，从源头降低 NotReady 类故障的发生概率。

部署方案没有绝对优劣，关键在于与团队能力、业务规模和运维预算相匹配。把故障预防配置前置到部署阶段，往往比事后排查更能体现方案设计的成熟度。