Kubernetes集群需要几台服务器？控制平面与工作节点配置指南

准备上 Kubernetes 的人最先问的问题往往不是"怎么装"，而是"要买几台机器"。有人听说明面上三台就能跑，结果发现三台全忙时控制平面先扛不住；也有人一次性买了十台，业务量根本用不满，钱花在了闲置的核上。这篇文章把集群规模的账算清楚：控制平面为什么必须是奇数台、etcd 为什么对磁盘这么挑、工作节点的 CPU 内存网卡该怎么配、最小可用集群长什么样、不同业务量级大概需要多少节点。给出的是可落地的经验值，具体仍要以你的压测为准。

一、集群的两种角色：控制平面与工作节点

Kubernetes 集群里的机器分两种角色。控制平面节点（Control Plane）跑 API Server、etcd、Scheduler、Controller Manager，负责决策和保存状态，本身不跑业务容器；工作节点（Worker Node）跑 kubelet、kube-proxy 和容器运行时，承载你的业务 Pod。

一个容易踩的坑是：很多人图省事，让所有机器既做控制平面又做工作节点（单节点或小集群常见）。这在学习和测试环境没问题，但在生产环境很危险——业务 Pod 把控制平面节点的 CPU、内存、磁盘 IO 吃满后，整个集群连 kubectl 都响应不了，故障放大成全局故障。生产环境要把控制平面和工作节点分开。

判断需要几台机器，本质是回答两个问题：控制平面要几台才能高可用，工作节点要几台才能装下业务并留出故障冗余。

二、控制平面为什么必须是奇数台

这里面有三个独立的理由，任何一个都足以让你选择奇数。

第一，etcd 的选举机制。etcd 用 Raft 协议做一致性复制，集群要能选出主节点（Leader）必须满足"多数派"（quorum），也就是超过一半的节点存活。三节点集群容忍 1 台故障（2 台存活即多数），五节点容忍 2 台，四节点和七节点同理也只会容忍更少。四节点和五节点都只能容忍 2 台故障，但四节点多花一台机器、性能还更差，所以没人选偶数——这是最核心的原因。

第二，避免脑裂（Split-Brain）。偶数节点在某些分区场景下可能出现两个分区各占一半、谁都不是多数派，或者达成"平票"无法选举的尴尬局面。奇数节点天然不存在平票。

第三，Raft 的写入性能。每次写操作要复制到多数派才算提交，节点越多，完成多数派确认的耗时越长。所以控制平面不是越多越好，三到五台是甜点区，超过五台写入延迟反而上升。

# 查看 etcd 集群成员与健康状态（需在控制平面节点执行）
kubectl -n kube-system get pods -l component=etcd
# 用 etcdctl 查看成员列表
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member list -w table
# 查看集群健康
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health --cluster

三、etcd 对磁盘 IO 极其敏感

etcd 保存集群的全部状态，任何写操作（新建 Pod、更新配置、心跳上报）都要落盘并同步到多数派。如果磁盘写延迟高，整个集群的 API 响应就会变慢，表现为 kubectl 卡顿、控制器反应迟钝，严重时引发超时和误判。

结论很明确：etcd 必须用 SSD，最好用 NVMe，绝对不要用机械硬盘，也不要用网络存储（NFS、Ceph 这类）。etcd 官方给的健康参考是，fsync 延迟（wal_fsync_duration）在正常情况下应在 10 毫秒以内，超过 25 毫秒就要警惕，长期高于 100 毫秒基本没法用。

除了介质，还要注意：不要和控制平面其他组件抢磁盘，etcd 独占一块 SSD 最稳；etcd 数据目录要放在低延迟、高 IOPS 的盘上；容量不用很大，几 GB 到几十 GB 足够，但要留够写入余量。集群规模大时，etcd 的数据库文件会增长，定期做碎片整理（compaction + defrag）能回收空间。

# 查看 etcd 磁盘延迟相关指标（HTTP 指标端口默认 2381）
curl -s http://127.0.0.1:2381/metrics | grep -E 'fsync|backend_commit'
# 查看 etcd 数据目录所在磁盘的 IO 情况
df -h /var/lib/etcd
iostat -x 2 5    # 关注 %util 与 await，await 长期偏高说明盘慢
# 定时维护：压缩旧版本并整理碎片（会短暂阻塞，建议在低峰期做）
ETCDCTL_API=3 etcdctl compact $(ETCDCTL_API=3 etcdctl endpoint status \
  --write-out=json | grep -o '"revision":[0-9]*' | head -1 | cut -d: -f2)
ETCDCTL_API=3 etcdctl defrag --cluster

四、控制平面节点的硬件配置

控制平面的负载主要来自 API Server 的请求处理和 etcd 的磁盘写入，对 CPU 和内存的要求中等，但对磁盘和网络延迟要求高。

经验配置参考（小到中型集群）：2 到 4 个 CPU 核、4 到 8 GB 内存、SSD 系统盘 40 GB 以上，etcd 数据盘单独一块 SSD。如果集群里节点和 Pod 数量多、API 调用频繁，CPU 提到 8 核、内存 16 GB 会更从容。控制平面节点通常不需要独立显卡，也不需要大内存。

网络方面，控制平面节点之间的延迟要低且稳定，最好在同一个交换机下、同一个机房内。跨机房部署 etcd 会显著拖慢写入，除非有专线且延迟极低，否则不建议。

五、工作节点：业务真正跑在哪里

工作节点的配置完全取决于你跑什么业务，无法一概而论，但有几条通用原则。

CPU：按业务 Pod 的 requests 总和来估算，并留出至少 30% 到 50% 的余量。不要按 limits 总和买，因为 limits 通常远大于实际使用。一台节点如果 CPU requests 已经占到 80% 以上，就没法再调度新 Pod 了（调度器按 requests 算账）。

内存：和工作方式类似，内存 requests 也参与调度。要特别注意，内存不可压缩，Pod 超限会被 OOM Kill。所以内存的总 requests 不要超过节点可分配内存的 80%（节点系统组件本身要占一部分）。经验上，为了故障时能快速迁移 Pod，单节点业务内存 requests 占比控制在 70% 左右比较稳。

磁盘：节点本地盘主要用来存放镜像和容器临时文件。镜像多的集群，每台节点建议至少 100 GB 系统盘，镜像仓库大的话用 200 GB 以上。如果你的业务需要本地暂存（如批处理、缓存），另外挂数据盘。

网络：工作节点网卡带宽直接影响服务间通信和大规模拉镜像的速度。千兆网卡（1 Gbps）适合小集群；万兆（10 Gbps）是中大型集群的常见选择；如果涉及存储流量或高吞吐服务，考虑 25 Gbps 及以上。多网卡可以做流量分离（业务一张、存储一张）。

六、网络插件（CNI）的选择

Kubernetes 本身不管 Pod 之间怎么通信，这部分交给 CNI 插件。没有 CNI，节点即使 Ready，Pod 网络也不通，集群不可用（093 篇会讲这个典型故障）。常见方案有三类思路。

第一类是简单扁平网络的 overlay 方案（Flannel 是典型代表），部署简单，适合小集群，但网络策略能力弱。第二类是基于 BGP 的 Calico，性能好、支持网络策略（NetworkPolicy），是中大型集群的常见选择。第三类是基于 eBPF 的 Cilium，可观测性和性能都强，能替代部分 kube-proxy 功能，但对内核版本有要求。

选型建议：小规模或学习用 Flannel；生产集群且需要网络隔离用 Calico；追求性能和可观测性、内核版本够新用 Cilium。无论哪种，都要确认 Pod CIDR 和节点网段、集群 Service 网段三者不冲突，否则会出现路由混乱。

七、最小可用集群与规模估算

真正能称为"最小可用生产集群"的形态是：3 台控制平面节点 + 2 台以上工作节点。三台控制平面保证 etcd 高可用，两台工作节点保证一台宕机时另一台能接管 Pod。这是很多中小团队的起点。

为什么不建议 1 控制平面 + 2 工作节点？因为控制平面单点，etcd 挂了集群管理直接不可用。为什么不建议 3 台全做"控制平面兼工作节点"？前面说过，业务会拖垮控制平面。

按业务规模的粗略估算（经验值，务必以压测为准）：几十个 Pod、单服务的小业务，3 控制平面 + 2 到 3 工作节点足够；中等规模（上百个 Pod、十几个服务、有状态服务若干），3 控制平面 + 4 到 6 工作节点；规模较大（数百 Pod、需要按业务分组），3 到 5 控制平面 + 8 个以上工作节点，并考虑按业务属性给工作节点打标签、用节点池（Node Pool）区分。

# 查看节点可分配资源与已分配 requests（判断还能不能再塞 Pod）
kubectl describe node  | sed -n '/Allocated resources/,/Events/p'
# 查看各节点上运行的 Pod 数量
kubectl get pods -A -o wide --field-selector spec.nodeName=
# 给工作节点打标签，便于调度区分
kubectl label node  node-role=compute
# 给节点加污点，阻止普通 Pod 调度（控制平面通常自带污点）
kubectl taint nodes  dedicated=gpu:NoSchedule

常见问题

Q：一台服务器能搭 Kubernetes 吗？
能，用 k3s、minikube、kind 都行，适合学习和演示。但单机没有高可用，一台挂了全没，生产环境必须有冗余。

Q：控制平面能和工作节点复用吗？
技术上可以（不设置控制平面污点），生产环境不建议。业务负载会和控制平面抢资源，一旦控制平面响应变慢，整个集群受影响。

Q：etcd 用普通的云盘可以吗？
要看云盘类型。高 IOPS 的 SSD 云盘可以，低配的通用型或机械盘不行。etcd 对 fsync 延迟敏感，选盘时看 IOPS 和延迟指标，不要只看容量和价格。

Q：工作节点买多少核合适？
没有标准答案，取决于业务。核心方法是用 kubectl describe node 看已分配 requests 占比，控制在 70% 到 80% 以内。宁可多买几台中配机器，也别买一台超大机器——节点越大，单点故障影响面越大。

Q：集群规模变大后要做什么调整？
控制平面从 3 台扩到 5 台；拆出独立 etcd 主机；按业务给节点分组；启用节点自动扩缩容（Cluster Autoscaler，需云环境支持）；把镜像拉取、日志、监控等基础组件从控制平面节点剥离。

Q：Swap 要不要开？
传统上 Kubernetes 要求关闭 swap，理由是调度依赖内存 requests 的准确性。较新版本支持有限度的 swap 支持，但仍需谨慎配置。生产环境最稳妥的做法是关闭 swap，让内存压力能被调度器正确感知。

总结

控制平面节点数必须是奇数，生产推荐 3 台（容忍 1 台故障）或 5 台（容忍 2 台）。四台和七台是浪费，偶数会导致平票问题，节点过多还会拖慢写入。

etcd 对磁盘 IO 极度敏感，必须用 SSD 或 NVMe，fsync 延迟关注 10 毫秒量级，绝不能用机械盘或网络存储，数据盘最好独立。

工作节点配置由业务决定，核心方法是按 Pod 的 requests 总量规划 CPU 和内存，留 30% 到 50% 余量，内存 requests 占比控制在 70% 左右。尽量用多台中配机器，避免单台超大机器。

最小可用生产集群是 3 控制平面 + 2 工作节点。CNI 插件必须装好，否则节点 Ready 但网络不通。选型按规模来：小集群 Flannel，生产 Calico，追性能用 Cilium。

最后一句实话：先从小集群起步，用监控数据看真实瓶颈，再决定扩哪一部分。一次性买满配置，通常是给未来某个可能永远不会到来的峰值付费。