RKE1 + Kubernetes 1.16.3 64 核 / 2048 GB 大内存节点拆分建议

一、机器规格与特点

CPU：64 核
内存：2048 GB（2 TB）
特点：CPU 相对较少、内存极大，属于典型的大内存型物理机
当前环境：RKE1 + Kubernetes 1.16.3 + docker

这种配置下，瓶颈通常不是内存，而是：

单节点 Pod 数量过多导致的 kubelet PLEG、docker、iptables 压力；
64 核 CPU 相对 2048 GB 内存偏少，如果 Pod CPU 需求高，CPU 会先耗尽。

二、为什么不建议整台机器作为一个 K8s 节点

即使内存高达 2TB，如果作为单个 K8s 节点运行 110~250 个 Pod，仍然会遇到 RKE1 + 1.16 + docker 的老问题：

问题	说明
PLEG 失活	kubelet 通过 docker 查询所有容器，Pod 越多越容易超过 3 分钟阈值
docker RPC 超时	docker daemon 单进程，高并发下容易锁竞争、响应慢
iptables 锁竞争	kube-proxy iptables 模式规则数随 Pod 增长，`xtables lock` 冲突加剧
故障域过大	单节点异常会影响大量 Pod

因此，无论内存多大，单节点 max-pods 仍建议控制在 110 以内。

三、推荐拆分方案

目标：max-pods=110，充分利用 64C/2048G。

方案	VM 规格	VM 数量	单机总 Pod 容量	适用场景
A（推荐）	32C / 1TB	2	220	内存密集型业务；贴合 2-socket NUMA
B	16C / 512GB	4	440	平衡型；故障域更小
C	8C / 256GB	8	880	大量小 Pod；管理节点数较多

最推荐：方案 A（2 台 32C/1TB VM）

推荐理由：

NUMA 友好：64 核通常是 2 路 CPU，每台 32C/1TB VM 正好落在一个 socket 上，避免跨 NUMA 内存访问；
单节点 110 Pod，压力可控，docker/PLEG/iptables 不会过载；
单台 1TB 内存，可支撑大内存 Pod（如 Redis、ES、大数据中间件等）；
管理简单：只有 2 个 K8s 节点，运维成本低。

方案 B / C 选择建议

大量小 Pod（每个 Pod 0.1~0.2 核、几百 MB 内存）→ 选方案 C；
平衡型混合负载，希望容量和稳定性兼顾 → 选方案 B；
内存密集型、CPU 适中的业务 → 选方案 A。

四、CPU 容量测算

按推荐方案 A（2 台 32C VM，max-pods=110）计算：

指标	数值
单 VM CPU	32 核
单 VM Pod 上限	110
平均可用 CPU/Pod（理论）	32 / 110 ≈ 0.29 核
扣除 20% 系统预留后	≈ 0.23 核/Pod

结论：这台机器适合 每个 Pod 平均 CPU 需求 ≤ 0.2~0.3 核 的场景。如果 Pod 普遍需要 1 核以上，64 核 CPU 会很快成为瓶颈，无论内存多大。

五、RKE1 配置建议

在 cluster.yml 中配置：

yaml

services:
  kubelet:
    extra_args:
      max-pods: "110"
      # 大内存节点保留足够系统资源，避免 OOM
      kube-reserved: "cpu=1,memory=4Gi"
      system-reserved: "cpu=500m,memory=4Gi"
      eviction-hard: "memory.available<2Gi"
  kubeproxy:
    extra_args:
      proxy-mode: "ipvs"

然后执行：

bash

rke up --config cluster.yml

六、操作系统级优化

bash

# 1. 调大 conntrack 表（大内存 + 多连接场景）
sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=86400

# 2. 禁用 firewalld，避免与 kube-proxy/calico 抢占 iptables
systemctl stop firewalld
systemctl disable firewalld

# 3. 持久化写入 sysctl
cat <<EOF >> /etc/sysctl.d/99-k8s.conf
net.netfilter.nf_conntrack_max=1048576
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=86400
EOF
sysctl --system

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

64 核物理机通常为 2 路 CPU / 2 NUMA node，每台 1TB 内存：

方案 A 的 2 台 VM 应分别绑定到一个 NUMA node，避免跨 NUMA 访问带来的性能损失；
在虚拟化层（KVM/ESXi）设置 VM 的 CPU/Memory affinity 或 NumaTopology；
如果业务对 NUMA 不敏感，也可让 hypervisor 自动调度，但大内存应用建议显式绑定。

八、长期建议

RKE1 + K8s 1.16.3 + docker 已停止维护：

dockershim 在 K8s 1.24 中已移除；
高密度 Pod 场景更适合 containerd + 较新 K8s 版本；
大内存节点建议评估 RKE2 或基于 containerd 的发行版，以获得更好的性能和稳定性。

九、总结

问题	建议
64C/2048G 是否适合单节点跑很多 Pod？	不适合，建议拆分 VM
推荐怎么拆？	2 台 32C/1TB VM，每节点 max-pods=110
为什么这样拆？	贴合 NUMA、内存充足、单节点压力可控、管理简单
适合什么业务？	内存密集型应用；Pod CPU 平均需求应 ≤ 0.2~0.3 核
需要同步做什么？	限制 max-pods、kube-proxy 改 ipvs、调 conntrack、禁用 firewalld、设置资源预留与 NUMA 绑定

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

RKE1 + Kubernetes 1.16.3 64 核 / 2048 GB 大内存节点拆分建议 ​

一、机器规格与特点 ​

二、为什么不建议整台机器作为一个 K8s 节点 ​

三、推荐拆分方案 ​

最推荐：方案 A（2 台 32C/1TB VM） ​

方案 B / C 选择建议 ​

四、CPU 容量测算 ​

五、RKE1 配置建议 ​

六、操作系统级优化 ​

七、NUMA 与资源划分注意事项 ​

八、长期建议 ​

九、总结 ​