conntrack 写入失败

LXC 内的 kube-proxy 升级后反复退出，日志明确指出无法写入 /proc/sys/net/netfilter/nf_conntrack_max，报 permission denied。若该文件由宿主配置、在容器中只读，不应先改 CNI 或放开容器全部权限。

新目标值会触发写入

Kubernetes 1.36 的计算对按 CPU 扩展的 conntrack 上限增加了 1,048,576 的封顶。核对的 1.37.1 实现仍然如此。宿主原来设置了更高的值时，目标值变化可能让 kube-proxy 开始尝试覆盖它。

这条写入判断是“当前值不等于目标值”，不是“当前值小于目标值”。所以已有容量更大，也可能触发写操作；把宿主与容器中的实际值、日志目标值和节点 CPU 条件一起比较，不能拿不同节点的数字直接证明版本回归。

日志报文件不存在时，是另一条分支，需要核对模块与环境；它不等同于已经存在但只读。

由宿主管容量

确认宿主已设置适合真实连接负载的容量，而且这个容量由宿主统一管理后，可以让 kube-proxy 不再调整这项上限。在它实际读取的完整配置里修改以下部分：

conntrack:
  maxPerCore: 0

这是已有 KubeProxyConfiguration 的局部字段，不是可直接覆盖原配置的完整文件。值为零时会保留现有上限，并忽略 min；不能以为只把 min 设低，就不会触发写入。

先确认配置来自挂载文件、配置对象还是启动参数，按原部署方式重新启动目标 kube-proxy 读取修改。只改一份未被使用的配置，不会改变启动行为。

只跳过这一组调整

这项设置跳过 nf_conntrack_max 及相连的 hashsize 调整，不会关闭连接跟踪，也不会屏蔽全部 sysctl 写入。其他 TCP、UDP 超时配置仍可能尝试修改对应内核项；日志若换成另一项失败，需要继续核对该项所有权。

宿主随后承担容量维护责任。检查实际连接数和容量余量，不把一个节点的 CPU 数或上限原样套到其他宿主。为避开报错而降低宿主容量，可能让原本正常的连接跟踪不足。

验收目标节点上的 kube-proxy 能持续运行，现有上限保持预期值，Service 转发恢复正常。配置回退也应与宿主策略配套；这里不要求对 /proc 改权限，也不应为一次启动错误授予容器完整宿主权限。