必须修改/etc/sysctl.conf或/etc/sysctl.d/并执行sysctl --system，因kubeadm init和kubelet依赖持久化内核参数（如ip_forward、bridge-nf-call-iptables、somaxconn等），临时设置重启即失效，会导致control-plane卡住、跨节点通信失败、连接拒绝等问题。
内核参数不调优，kubeadm init 可能卡在 [wait-control-plane]，或后续出现 connection refused、no route to host、Pod 无法跨节点通信等现象——这不是网络插件的问题，而是内核根本没准备好承载 Kubernetes 的连接密度和资源调度模型。
为什么必须改 /etc/sysctl.conf 而不是只用 sysctl -w
临时生效的 sysctl -w net.core.somaxconn=1024 在重启后丢失，而 Kubernetes 组件（如 apiserver、kube-proxy）启动早于用户登录，依赖的是持久化内核配置。若仅临时设置，节点重启后 kubelet 可能因连接队列溢出反复崩溃，日志里频繁出现 accept4: too many open files 或 Operation not permitted。
-
sysctl -p加载的是/etc/sysctl.conf和/etc/sysctl.d/*.conf，必须写入文件才真正“部署就绪” - CentOS 8/Rocky 9 默认启用
systemd-sysctl.service，它只读取/etc/sysctl.d/下的配置；建议统一写入/etc/sysctl.d/99-kubernetes.conf避免被 distro 默认值覆盖 - 修改后务必执行
sysctl --system（而非仅sysctl -p），确保加载全部目录且触发 systemd 重载
net.ipv4.ip_forward=1 和 net.bridge.bridge-nf-call-iptables=1 缺一不可
这两个参数是 Pod 网络通信的底层开关：ip_forward 允许 Linux 主机转发 IP 包（否则 flannel 或 calico 的网桥流量直接被丢弃）；bridge-nf-call-iptables 决定网桥流量是否经过 iptables 链——Kubernetes 的 Service ClusterIP、NodePort 严重依赖此路径做 DNAT/SNAT。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 缺
ip_forward=1：Pod 能 ping 同节点其他 Pod，但跨节点不通，tcpdump显示包进不了网桥 - 缺
bridge-nf-call-iptables=1：Service 访问失败，iptables -t nat -L KUBE-SERVICES有规则但不命中，kube-proxy日志报can't find service - 注意：若系统启用了
nftables（如 Ubuntu 22.04+ 默认），还需额外设置net.bridge.bridge-nf-call-nftables=1，否则 iptables 规则不生效
fs.file-max 和 fs.inotify.max_user_watches 的实际影响阈值
Kubernetes 对文件句柄和 inotify 实例的消耗远超传统应用：每个 Pod 的容器 rootfs、volume mount、kubelet watch API、CNI 插件监听网络事件都会快速耗尽默认值。CentOS 8 默认 fs.file-max=1879048，跑满 50 个 Pod 就可能触发 Too many open files。
-
fs.file-max=52706963是生产级推荐下限，适用于 ≥100 节点集群；小集群可设为1000000，但需配合ulimit -n调整 kubelet 进程限制 -
fs.inotify.max_user_watches=524288是 Flannel/Calico 必需值；低于此值，kubelet会反复报错inotify_add_watch failed: no space left on device，导致 NodeReady 状态反复切换 - 不要只改
sysctl，还要检查/proc/sys/fs/inotify/max_user_instances（建议 ≥8192），否则单用户创建 inotify 实例数仍受限
net.netfilter.nf_conntrack_max 和 net.ipv4.tcp_max_tw_buckets 的协同关系
这两个参数共同决定连接跟踪表容量。nf_conntrack_max 是总槽数，tcp_max_tw_buckets 是 TIME-WAIT 状态连接的最大缓存数。Kubernetes 中大量短连接（如 kubelet 心跳、Prometheus 抓取、Service 转发）极易填满 conntrack 表，引发 nf_conntrack: table full, dropping packet。
-
nf_conntrack_max至少设为10485760（1000 万），按每节点 10 万连接估算；若用ipvs模式，需更高（因为 ipvs 自己也维护连接状态） -
tcp_max_tw_buckets建议设为6000~12000，过大会拖慢回收，过小会导致 TIME-WAIT 连接被强制 RST，表现为偶发性连接超时 - 必须同步调整
net.netfilter.nf_conntrack_buckets（哈希表桶数），推荐值 =nf_conntrack_max / 4，否则哈希冲突飙升，性能断崖下降
真正容易被忽略的不是参数值本身，而是验证闭环：改完参数后，必须确认 sysctl --system 执行成功、systemctl restart systemd-sysctl 无报错、cat /proc/sys/net/netfilter/nf_conntrack_count 初始值接近 0，且 kubelet 启动日志中不再出现 failed to run iptables-restore 或 cannot allocate memory —— 参数写了不等于生效，生效了不等于被组件正确使用。
