KnoAI 技术站

主题

RKE1 + Kubernetes 1.16.3 节点拆分后的集群规模与管理规划 ​

一、背景 ​

  • 当前物理机数量：138 台
  • 计划：将大规格物理机拆分为多台虚拟机，每个 VM 作为一个 K8s 节点
  • 当前架构：RKE1 + Kubernetes 1.16.3 + docker
  • 风险：节点数可能从 138 大幅增长到 552 ~ 1104+，进入中大型集群规模

本文档从控制面、网络、DNS、监控、运维等维度给出规划建议。

二、拆分后节点规模估算 ​

拆分比例物理机数K8s 节点数集群规模
1 台物理机 = 2 VM138276中等
1 台物理机 = 4 VM138552较大
1 台物理机 = 8 VM1381104很大

K8s 1.16 + etcd 3.3 实践经验：

  • 300 节点以下：相对轻松，常规优化即可；
  • 500 节点左右：需要专门调优 etcd、Calico、CoreDNS；
  • 1000 节点以上：RKE1 + 1.16 + docker 会比较吃力，建议升级架构或拆分成多集群。

三、控制面规划 ​

1. etcd 是最大瓶颈 ​

etcd 存储所有 Node、Lease、Pod、Endpoint、Service 等对象，节点数翻倍后，数据量和 watch 压力显著增加。

项目建议
etcd 节点数至少 3 节点，500+ 节点建议 5 节点
磁盘必须 SSD/NVMe，etcd 对磁盘延迟极度敏感
内存每 etcd 节点至少 8GB，500+ 节点建议 16GB+
网络etcd 节点之间低延迟、高带宽，最好独立网段
参数调优增大 quota-backend-bytes、调整 heartbeat-interval、election-timeout
维护定期 compaction 和 defrag，监控 etcd_db_total_size_in_bytes

RKE1 cluster.yml 示例：

yaml
services:
  etcd:
    extra_args:
      quota-backend-bytes: "8589934592"      # 8GB
      auto-compaction-retention: "1h"
      heartbeat-interval: "500"
      election-timeout: "2500"
    backup_config:
      enabled: true
      interval_hours: 6
      retention: 30

2. API Server / Controller Manager / Scheduler ​

  • kube-controller-manager、kube-scheduler 在 RKE1 中为静态 Pod，运行在 control plane 节点；
  • 节点数到 500+ 时，control plane 资源必须独立且充足。
组件建议
control plane 节点独立 3~5 台，不与 worker 混部
API Server多副本 + 外部负载均衡（LB / keepalived + haproxy）
Controller Manager / Scheduler确保 control plane 节点 CPU/内存充足

四、网络规划 ​

1. PodCIDR 必须提前规划 ​

默认 cluster-cidr=10.42.0.0/16，每节点 /24，最多支持 256 个节点。

cluster-cidr每节点掩码最大节点数
10.42.0.0/16/24256
10.42.0.0/15/24512
10.42.0.0/14/241024
10.40.0.0/13/242048

cluster-cidr 一旦确定很难修改，必须在规划阶段覆盖未来 1~2 年的节点上限。

2. Calico / Canal 改用 Route Reflector ​

RKE1 默认 Canal 使用 BGP full mesh。节点数超过 100 后，BGP 邻居关系会爆炸增长。

建议：

  • 改为 Route Reflector（RR）模式；
  • 选择 3~5 台网络性能好的节点作为 RR；
  • 或使用 Calico BGP peer 模板集中管理。

3. kube-proxy 模式 ​

iptables 模式在节点数 >200 时规则数和锁竞争非常严重，必须改为 ipvs：

yaml
services:
  kubeproxy:
    extra_args:
      proxy-mode: "ipvs"

五、DNS 规划 ​

项目建议
CoreDNS 副本数按节点数比例扩容，建议每 50~100 节点 1 副本，上限 10~15 个
NodeLocal DNSCache必须开启并确保全节点覆盖，降低 CoreDNS 压力
CoreDNS 反亲和配置 PodAntiAffinity，避免多个副本落在同一物理机/VM
DNS 缓存 TTL业务侧适当调整 DNS 缓存，减少 CoreDNS 查询

六、监控与日志 ​

项目建议
Prometheus使用远程存储（Thanos、Cortex、VictoriaMetrics）或分片采集
scrape 间隔非核心指标放宽到 30s/60s
指标裁剪丢弃不必要的高基数 cAdvisor/kubelet 指标
日志采集Fluentd/Fluent Bit 按节点数评估吞吐，独立 ES/Loki 集群
告警按物理机聚合，避免 VM 级告警噪音

七、节点命名、标签与调度策略 ​

推荐命名规则 ​

<机房>-<机架>-<物理机编号>-vm<VM编号>
例如：sz-rack05-szb13032-vm01

推荐标签 ​

标签用途
topology.kubernetes.io/zone可用区/机房
physical-host所属物理机
node-typeworker / controlplane / etcd
vm-indexVM 编号
resource-profilecpu-intensive / memory-intensive

调度策略 ​

  • 关键应用配置 PodAntiAffinity，避免多个副本落在同一物理机或同一 VM；
  • 使用 topology spread constraints 分散副本；
  • NUMA/本地盘敏感应用使用 nodeAffinity 绑定到特定规格 VM。

八、运维管理 ​

RKE1 手工维护 500+ 节点的 cluster.yml 不现实，建议引入自动化：

方向建议
集群部署Terraform + cloud-init + RKE1，或迁移至 Rancher 管理 RKE/RKE2
节点扩缩容使用 Rancher Node Pool / Cluster API
升级策略分批滚动升级，按 zone/物理机分组，配合 cordon + drain
维护窗口同一物理机上的 VM 分批操作，避免整台物理机同时不可用
镜像分发私有镜像仓库 + 节点本地缓存 / P2P 分发（如 Dragonfly）

九、是否该拆成多个 K8s 集群？ ​

如果拆分后节点数预计超过 600~800，强烈建议考虑多集群：

拆分维度适用场景
按业务域每个业务独立集群，降低爆炸半径
按环境生产 / 预发 / 测试 独立集群
按机房/可用区苏州 / 上海 / 北京各一个集群
多集群管理Rancher Multi-Cluster、ArgoCD、Cluster Federation

多集群优点：

  • 单集群规模可控，etcd/API Server 压力小；
  • 故障隔离；
  • 升级风险低，可逐集群升级。

十、针对当前 138 台物理机的建议 ​

目标节点数建议
300~500适度拆分（平均每物理机 2~4 VM），单集群可管理，需调优 etcd/Calico/DNS
500~800拆分 + 强控制面（5 etcd、独立 control plane、RR、NodeLocal DNS），RKE1+1.16 较吃力
800+必须升级架构或拆分多集群，不建议在 RKE1+1.16+docker 上硬撑

十一、总结 ​

维度核心建议
规模先算清楚拆分后节点数，控制在 500 以内较安全
控制面独立 control plane、5 节点 etcd、SSD、参数调优
网络提前扩大 PodCIDR、Calico 改 Route Reflector、kube-proxy 改 ipvs
DNSNodeLocal DNSCache + CoreDNS 多副本 + 反亲和
监控Prometheus 远程存储、指标裁剪、日志独立集群
运维自动化部署、分批升级、清晰的命名标签体系
长期500+ 节点建议升级 RKE2/containerd 或多集群架构

文档生成时间：2026-07-23