直接修改 maxpods 值可突破默认 110 限制,但需确认配置来源(命令行、环境变量、config.yaml 或 systemd drop-in)、生效方式及配套资源(内核参数、cni ip 分配能力)是否匹配,并验证 node 状态与资源水位。

直接改 maxPods 值就能突破默认 110 个 Pod 的限制,但不能只改数字——得看配置来源、生效方式和配套资源是否跟得上。
确认当前 maxPods 实际生效位置
Kubelet 启动参数可能来自多个地方,优先级从高到低通常是:
-
命令行参数(如
--max-pods=200),最优先,但通常不直接写在ExecStart里 -
/etc/sysconfig/kubelet(RHEL/CentOS)或/etc/default/kubelet(Ubuntu),通过KUBELET_EXTRA_ARGS注入 -
/var/lib/kubelet/config.yaml,kubeadm 集群默认配置文件,字段为maxPods: 110 -
systemd drop-in 文件,比如
/usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf中的Environment="KUBELET_CONFIG_ARGS=--config=..."
执行 systemctl status kubelet -l 查看实际加载的参数和配置路径,再检查对应文件是否存在 maxPods 字段。
修改 maxPods 的三种常用方式
选一种即可,推荐用 config.yaml 方式(清晰、易维护):
-
改 config.yaml:编辑
/var/lib/kubelet/config.yaml,添加或修改顶格字段:maxPods: 250(注意无缩进、无引号) -
加环境变量:在
/etc/sysconfig/kubelet中写入:KUBELET_EXTRA_ARGS="--max-pods=250",并确保kubelet.service中有EnvironmentFile=-/etc/sysconfig/kubelet -
改 systemd 参数:在
/usr/lib/systemd/system/kubelet.service.d/10-kubeadm.conf的[Service]下追加:Environment="KUBELET_EXTRA_ARGS=--max-pods=250"
改完后必须执行:systemctl daemon-reload && systemctl restart kubelet
验证是否生效且不引发新问题
重启后别急着部署,先做三件事:
- 运行
kubectl describe node <node-name> | grep -i pods</node-name>,确认输出中pods: 250已更新 - 检查
kubectl get pods -A --field-selector spec.nodeName=<node-name></node-name>数量是否仍在新上限内;若原已接近 110,需提前kubectl drain驱逐部分 Pod,避免重启后因超限导致 Pending - 观察节点资源水位:单节点 Pod 过多会快速耗尽
inotify watches、conntrack entries、文件句柄等系统资源。建议同步调大内核参数,例如:fs.inotify.max_user_instances=524288net.netfilter.nf_conntrack_max=10485760fs.file-max=1000000
注意网络插件与实际可用 IP 的匹配
maxPods 不是孤立指标,它受限于底层网络能分配的 IP 数量:
- Flannel(
/24子网)最多提供 254 个可用 IP(256 − 2),所以设maxPods > 254可能导致 Pod 无法获取 IP - Calico 默认每个节点分配 /26 子网(64 个 IP),若启用
ipam: host-local模式,实际可用数更少 - 使用 Cilium 或带 ENI 多 IP 支持的云网络时,上限可显著提升,但需确认 CNI 配置已启用相应能力
务必结合 kubectl get nodes -o wide 查看 PodCIDR,再比对子网掩码计算理论最大值。











