RKE1 + Kubernetes 1.16.3 大规格物理机节点拆分与容量规划建议

一、背景与问题

• 物理机规格：160 核 / 756 GB 内存（另有 1024 GB 存储）
• 当前架构：RKE1 + Kubernetes 1.16.3 + docker
• 当前 kubelet 配置：--max-pods=110~250
• 当前现象：单节点 Pod 数高时频繁出现 PLEG is not healthy、docker RPC DeadlineExceeded、xtables lock 等稳定性问题

核心矛盾：物理机算力很强，但 kubelet/docker/iptables/CNI 等单节点组件对 Pod 数量敏感，导致大规格物理机直接作为单个 K8s 节点时，反而更容易不稳定。

---

二、为什么不建议单台大物理机直接作为一个 K8s 节点

Kubernetes 官方默认 --max-pods=110 并非偶然。单节点 Pod 数过高会带来以下问题：

组件	高 Pod 数带来的问题
kubelet PLEG	PLEG 每轮需通过 docker 查询所有容器状态，Pod 越多越慢，超过 3 分钟即 PLEG is not healthy
docker daemon	docker 是单进程 daemon，高并发容器操作下容易锁竞争、goroutine 堆积、RPC 超时
iptables	kube-proxy iptables 模式规则数随 Pod 线性增长，xtables lock 竞争加剧
conntrack	大量连接易占满 conntrack 表，导致丢包或网络异常
CNI / Calico	每个 Pod 都要分配 IP、维护路由/FDB/ARP 表项，250 Pod 时开销显著增加
故障域	单节点 NotReady 会影响所有 Pod，影响面过大

大物理机（160C/756G）的资源容量足够跑很多 Pod，但单节点管理组件的并发处理能力跟不上。

---

三、方案对比：单节点 vs 虚拟机拆分

以 160 核 / 756 GB 物理机为例：

方案	节点形态	单节点规格	单节点 max-pods	单物理机总 Pod 容量	稳定性
A	单台物理机 = 1 个 K8s 节点	160C / 756G	250	250	差
B	拆成 4 台 VM	40C / 189G	110	440	较好
C	拆成 6 台 VM	~26C / 126G	110	660	好
D（推荐）	拆成 8 台 VM	20C / 94G	110	880	最好

推荐方案 D 的优势

1. 单节点 Pod 数从 250 降到 110，kubelet/docker/iptables 压力大幅下降；
2. 单物理机总容量反而提升（250 → 880）；
3. 故障域更小：一台 VM 异常只影响 110 个 Pod；
4. 维护更灵活：可逐台 VM 升级、重启、迁移，不影响整台物理机；
5. 有效规避 RKE1 + K8s 1.16.3 + docker 的老化架构瓶颈。

虚拟化开销

KVM/ESXi 本身开销通常 <5%，对 CPU/内存影响可忽略，多一跳虚拟网桥对一般业务也无明显影响。

---

四、配套优化建议

仅拆分 VM 还不够，建议同步调整以下配置：

1. 限制 kubelet max-pods 为 110

在 RKE1 cluster.yml 中配置：

services:
  kubelet:
    extra_args:
      max-pods: "110"

然后执行 rke up 生效。

2. kube-proxy 改用 ipvs 模式

iptables 模式在 Service 数量多时极易锁竞争，ipvs 可显著降低 iptables 压力：

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

3. 优化 conntrack 表

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=86400

建议写入 /etc/sysctl.d/99-k8s.conf 持久化。

4. 禁用 firewalld，避免与 kube-proxy/calico 抢占 iptables

systemctl stop firewalld
systemctl disable firewalld

5. 监控单节点 Pod 密度

# 查看每个节点当前 Pod 数
kubectl get pods -A -o jsonpath='{range .items[?(@.spec.nodeName!="")]}{.spec.nodeName}{"\n"}{end}' | sort | uniq -c | sort -rn

建议设置告警：当节点 Pod 数 > 90 时触发，提前扩容或拆分。

---

五、NUMA 与资源划分注意事项

如果物理机是 2 路或 4 路 CPU（多 NUMA），建议：

• 拆分时让每台 VM 尽量绑定单个 NUMA node 的资源，避免跨 NUMA 内存访问带来的性能损失；
• 对于 CPU 敏感型业务，可在 VM 内启用 numa 感知或设置 kubelet CPU manager policy；
• 内存大页、NUMA topology 等高级特性需要虚拟化层（KVM/ESXi）支持并开启。

---

六、长期建议

RKE1 + K8s 1.16.3 + docker 已属于较老架构：

• K8s 1.16 已停止维护；
• dockershim 在 K8s 1.24 中已移除；
• 高密度 Pod 场景更适合 containerd + 较新 K8s 版本。

如果业务未来有大规模扩容需求，建议规划迁移至：

• RKE2 / 其他基于 containerd 的发行版
• K8s 1.24+（或当前 Rancher 支持的稳定版本）
• 容器网络采用 Cilium/Calico eBPF 等高性能方案

---

七、结论

问题	建议
大物理机直接跑 110~250 Pod 是否合适？	不合适，单节点管理组件压力太大，易触发 PLEG/docker/iptables 问题
是否应拆分为虚拟机？	是的，建议每台 VM 作为一个 K8s 节点，单节点 Pod 数控制在 110 以内
推荐拆分	8 台 VM，20C / 94G，max-pods=110，单机总容量 880 Pod，稳定性最佳
必须同步优化	max-pods 限制、kube-proxy ipvs、conntrack、禁用 firewalld
长期方向	升级至 containerd + 较新 K8s 版本

---

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