KKubepath
解决方案架构师 路线第 5 / 16 节 · 把需求写成集群规格退出路线
原理预计 30 分钟

集群规划与命名：把方案写成一张表

几个控制面、几段网络、节点怎么命名 —— 这些在装机之前定下来，后面两年都不用返工。

学完这节你能做到

  • 按地区、集群、DNS、节点四层规则给一套新集群命名
  • 规划 Pod / Service / 节点三段网络，并算出它们够撑多大规模
  • 决定控制面节点数、是否复用负载均衡节点、GPU 节点怎么分组

集群规划里真正不可逆的决定，其实只有几个：网段、控制面节点数、命名规则。

它们的共同特点是"建成后改不动"。改网段等于重建集群；改命名规则等于所有监控面板、告警规则和文档一起返工。所以这一节的目标很具体：在装机之前，把这几件事写成一张能交给实施的表。

命名：四层规则

命名看起来是小事，但它决定了两年后你还能不能从一个告警里一眼看出这是哪个机房的哪个集群的哪台机器。

地区机房

格式 <地区缩写><机房序号>，例如 bj1、zw1、hs1。序号跳过 4。

集群

格式 <用途或项目><序号>：

前缀含义示例
k8s提供 K8s 服务的容器云k8s1
dev开发集群dev1
rds数据库集群rds1
vast / xeos存储集群vast1、xeos1

面向特定用户的计算集群直接用官方全称，例如 apple1。存储、数据库这类基础设施默认假定多用户共享。

DNS

格式 <service>.<cluster>.<region>.<domain>：

cr.dev1.zw1.paratera.com        容器镜像仓库
gf.apple1.zw1.paratera.com      Grafana
s3.ceph1.hs1.paratera.com       对象存储入口

第一次解析不区分内外网。确实需要区分时，用 -ext / -int 后缀挂在 region 上：cr.dev1.zw1-ext.paratera.com。

节点

格式 <两位角色缩写>-<IP 用短横线分隔>。这个写法的好处是：从主机名就能直接读出 IP 和角色，排障时不用查表。

缩写角色数量要求示例
mn控制（管理）节点生产至少 3，最多 7mn-10-128-0-1
ln网络负载均衡节点至少 2，可复用管理节点ln-10-128-0-11
gnGPU 计算节点按需gn-10-128-1-1
cnCPU 计算节点按需cn-10-128-100-1
dn数据库节点至少 3，推荐独立dn-10-128-200-1
sn存储节点至少 3，推荐独立sn-10-128-201-1
✓给 IP 段留出结构

上面的示例里有个不明显的设计：不同角色用不同的第三段（0 管理、1 GPU、100 CPU、200 数据库、201 存储）。

这样做之后，防火墙规则、监控分组、Ansible inventory 都可以按网段写，而不用逐台列举。新加一台 GPU 节点不需要改任何规则。

控制面：3、5 还是 7

etcd 用 Raft，需要多数节点存活才能写入。所以节点数必须是奇数，而且能容忍的故障数是 (n-1)/2：

控制面节点数容忍故障适用场景代价
10实验环境挂了就没了
31绝大多数生产集群写入需 2 个节点确认
52大集群、跨机架部署写入需 3 个节点确认，延迟更高
73极少数场景写延迟明显上升，通常不值得
!etcd 节点越多，写入越慢

新人容易以为"节点越多越可靠"，于是直接上 7 台。

但每次写提案都要等到多数节点 fsync 确认。3 节点等 2 个，7 节点等 4 个 —— 等的人多了，延迟就被最慢的那几个决定。可靠性的收益（容忍 3 台故障 vs 1 台）在实践中远不如写延迟的损失来得明显。

**默认选 3。**只有当控制面确实要跨机架或跨机房分布、单机架故障可能带走 2 台时，才上 5。

网段：三段地址，一次定死

一套集群要规划三段互不重叠的地址空间：

节点网段    10.128.0.0/16     物理网络，宿主机 IP
Pod CIDR    10.244.0.0/16     每个节点从里面切一个 /24
Service CIDR 10.96.0.0/12     ClusterIP 的虚拟地址空间

关键的约束在 Pod CIDR 上。kube-controller-manager 会按 node-cidr-mask-size 给每个节点切一段子网：

Pod CIDR每节点子网最多节点数每节点可用 IP
/16/24256254
/16/25512126
/14/241024254
/12/244096254

两个数字乘起来必须同时满足集群规模和 Pod 密度。这两个掩码在集群建成后都改不了 —— 改它们意味着所有节点的 Pod 网络重划，等于重建集群。

×按当前规模选网段，是最常见的规划事故

「我们就 20 台机器，/16 配 /24 够用了」—— 这话对，直到两年后要扩到 300 台。

规划网段要按三年后的规模来，而且要留一倍余量。Pod CIDR 用的是私有地址，10.0.0.0/8 里有一千六百万个地址，从 /16 放大到 /14 不花一分钱。真正的成本是和公司现有网络规划撞段 —— 所以这件事必须和网络团队一起定。

同样容易被忽略的是 Service CIDR：每个 Service 占一个 IP，/12 给 100 万个，通常够；但如果集群里有大量短命的临时 Service，也要算一下。

网络：三张网

网络带宽要求说明
内网互联所有节点至少 10Gb 以太Pod 间东西向流量走这里
存储复制网存储节点额外至少 10Gb独立出来能显著提升存储性能
外网接入负载均衡节点至少 1Gb不对外提供服务时可选

GPU 训练集群还要额外规划 RDMA 网络（RoCE 或 InfiniBand），那部分在 L0 的《硬件与拓扑》里展开。

把规划落成配置

上面这些最终都要变成 kubespray 的 inventory。对应关系：

# inventory.ini —— 节点命名与角色，直接照规划表写
[kube_control_plane]
mn-10-128-0-1 ansible_host=10.128.0.1
mn-10-128-0-2 ansible_host=10.128.0.2
mn-10-128-0-3 ansible_host=10.128.0.3

[etcd:children]
kube_control_plane

[kube_node]
gn-10-128-1-1 ansible_host=10.128.1.1
cn-10-128-100-1 ansible_host=10.128.100.1
# group_vars/k8s_cluster/k8s-cluster.yml —— 网段规划落在这几个字段
kube_service_addresses: 10.96.0.0/12
kube_pods_subnet: 10.244.0.0/16
kube_network_node_prefix: 24          # 每节点 /24，最多 256 节点
cluster_name: k8s1.zw1.paratera.com
检查点单选

集群规划为 Pod CIDR 10.244.0.0/16、每节点子网 /26。这套配置的规模上限是？

交付给实施的那张表

规划做完，应该能填满这张表 —— 填不满就说明还有没定的东西：

项目值
集群名 / DNS 后缀k8s1.zw1.paratera.com
控制面节点数与主机名3 台，mn-10-128-0-{1,2,3}
负载均衡方式复用控制面 + kube-vip / 独立 ln 节点
节点网段10.128.0.0/16
Pod CIDR + 每节点掩码10.244.0.0/16 + /24（上限 256 节点）
Service CIDR10.96.0.0/12
etcd 数据盘独占 NVMe，已通过 fio 验收
计算节点分组与命名gn- GPU / cn- CPU
三张网的规格内网 25G / 存储 25G / 外网 1G

延伸资料

  • ·k8s-in-actionk8s/plan/README.md
下一课：硬件与拓扑：控制面、计算节点与 GPU 机型 →