Kubernetes集群配置规划指南：从测试环境到生产高可用架构实践

应读者要求，聊一聊 Kubernetes 集群到底该怎么规划配置。需要提前说明的是：每个人的业务形态、团队规模、技术背景都不一样，不存在放之四海而皆准的配置方案。

所以本文不会给你一个“标准答案”，而是：

• 基于我自己踩过的坑和总结的经验
• 结合 Kubernetes 官方文档的推荐
• 给出 测试环境 和 生产环境高可用 两种典型配置思路

希望你能从中找到适合自己的那一版 Kubernetes。

一、先说结论：不要一上来就“生产级”

这是我见过最多的新手误区之一。

刚接触 Kubernetes 时，很多人第一句话就是：

“老师，生产环境该怎么配？”

但现实是：

• 你现在可能连 Deployment、Service、Ingress 的关系都没完全跑顺
• 业务量、QPS、Pod 数量都还没影子
• 团队对 Kubernetes 的运维经验为 0

👉 在这种情况下，直接规划“生产级集群”，大概率是在浪费时间。

官方文档其实一直在强调一句话：

Kubernetes 集群配置，应当与实际负载、规模和可用性目标匹配。

所以我们分两种场景来聊。

二、测试 / 学习环境：够用、稳定、可复现

1️⃣ 测试环境的目标是什么？

不是高可用，不是性能极限，而是：

• 能跑 Kubernetes 核心组件
• 能验证 YAML 是否正确
• 能跑完整的 CI/CD / 部署流程
• 挂了能快速重建

一句话总结： 👉 “随时可以推倒重来”

2️⃣ 官方推荐的最小可用集群

根据 Kubernetes 官方文档：

单控制平面节点 + 若干工作节点，是最小可用部署方式。

推荐配置（测试环境）

实际上， 1 台 4C / 8G 的虚机 ，同时跑 control-plane + worker，也完全没问题。

3️⃣ 组件建议

测试环境中，我的建议是：

• 安装方式
  • kubeadm、二进制（推荐）
  • k3s / kind / minikube（偏开发本地）
• etcd
  • 使用 control-plane 内置 etcd
• 网络插件
  • Calico（功能完整，和生产一致）
• Ingress
  • Nginx Ingress Controller
• 存储
  • 本地路径（local-path-provisioner / hostPath）
• 高可用
  • ❌ 不需要

测试环境的一个重要原则： 尽量和生产用“同一类组件”，只是规模不同。

4️⃣ 一个现实建议

如果你只是为了写 YAML、跑 Demo、做 PoC：

👉 1 台虚机（4C8G）+ k3s，已经足够 90% 场景

不要为了“看起来专业”，把测试环境搞得比生产还复杂。

三、生产环境规划前，你必须想清楚的 5 个问题

在聊高可用之前，先问自己几个问题：

1. 集群是否是核心业务？
2. 允许多长时间不可用？
3. 有没有专职或兼职 SRE？
4. 业务 Pod 规模（几十？几百？上千？）
5. 是否部署在云上，还是自建机房？

👉 这些问题，直接决定你要不要“真·高可用”。

四、生产环境：官方推荐的高可用架构

1️⃣ 控制平面高可用（必须）

Kubernetes 官方明确推荐：

生产集群应部署 多控制平面节点 ，并使用外部负载均衡访问 API Server。

官方推荐结构

           LoadBalancer (VIP)
                  |
        +-----------+-----------+
        |           |           |
  API Server   API Server   API Server
        |           |           |
       etcd        etcd        etcd

k8s高可用架构设计可参考我的另一篇文章。

2️⃣ 推荐配置（生产高可用）

控制平面节点

etcd 一定是奇数节点 ，这是共识。另外etcd所在节点一定要上SSD。

工作节点（Worker）

3️⃣ 负载均衡与 VIP

• API Server 前必须有 LB
• 常见方案：worker 节点采用本地代理模式：各节点均调用自身本地代理，由代理将请求转发至所有 API Server 节点。
  • 云厂商 LB（最简单）
  • HAProxy + Keepalived（外部独立）
  • worker节点采用本地代理（Nginx/HAProxy）模式（推荐）
• 注意：
  • LB 本身也要高可用
  • API Server 不建议直连某个节点 IP

4️⃣ 生产环境组件推荐

这些基本都是 官方生态和社区主流方案， 不过网络方案最近开始流行 cilium 。对于生产环境 集群 的搭建与维护，选择合适的生态组件至关重要。

五、一个我常用的“分阶段路线”

如果你不知道从哪开始，可以参考这个节奏：

1. 单节点 / k3s 学习
2. 1 CP + 2 Worker 测试集群
3. 3 CP + 3 Worker 生产集群
4. 再考虑多集群、异地容灾

Kubernetes 是一个 长期演进的系统 ，不是一次性工程。成功的 运维 策略往往始于清晰的阶段规划。

七、写在最后

Kubernetes 配置规划，本质上不是技术问题，而是：

业务目标、团队能力、运维成本之间的平衡

官方推荐给的是“方向”，

经验能帮你少走弯路，

但最终的答案，一定是你自己跑出来的。更多关于云原生技术的深度讨论，欢迎访问 云栈社区 。