直接修改 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，确认输出中pods: 250已更新 - 检查
kubectl get pods -A --field-selector spec.nodeName=<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，再比对子网掩码计算理论最大值。
