Talos系统升级至1.10.0版本后kube-proxy容器启动问题分析

在将Talos系统从1.9.5版本升级到1.10.0版本的过程中，部分用户遇到了kube-proxy容器无法正常启动的问题。该问题表现为kube-proxy容器在控制平面节点上持续处于Pending状态，而工作节点上的kube-proxy则启动正常。

问题现象

查看kube-proxy容器的详细状态时，系统报告了以下关键错误信息：

failed to generate container spec: failed to apply OCI options: failed to mkdir "/usr/lib/modules": mkdir /usr/lib/modules: read-only file system

这表明kube-proxy容器尝试访问宿主机上的/usr/lib/modules目录时遇到了权限问题，系统提示该目录为只读文件系统。错误发生在容器启动的初始化阶段，导致kube-proxy无法正常创建所需的目录结构。

问题根源

经过深入分析，发现该问题与Talos 1.10.0版本中的文件系统结构调整有关。在1.10.0版本中，Talos系统将/lib目录调整为/usr/lib的符号链接，这是为了遵循现代Linux发行版的目录结构标准。

然而，kube-proxy的DaemonSet配置中仍然指定挂载/usr/lib/modules目录作为hostPath卷。由于Talos系统的安全模型限制，/usr目录被挂载为只读文件系统，这就导致了kube-proxy容器无法在该目录下创建必要的子目录。

解决方案

解决该问题的方法相对简单：

1. 重新执行Kubernetes升级命令：

talosctl --talosconfig talosconfig upgrade-k8s --to 1.33.0

2. 系统会自动应用一个补丁，将kube-proxy的DaemonSet配置中的挂载点从/usr/lib/modules更改为/lib/modules：

-          path: /usr/lib/modules
+          path: /lib/modules

这个修改利用了Talos系统中/lib作为/usr/lib符号链接的特性，同时避开了/usr目录的只读限制。由于/lib/modules实际上指向相同的内容，kube-proxy的功能不会受到影响。

技术背景

这个问题揭示了几个重要的技术点：

1. 容器文件系统隔离：Kubernetes中的hostPath卷允许容器访问宿主机文件系统，但受限于宿主机的挂载选项和权限设置。

2. Talos安全模型：Talos作为专为Kubernetes设计的操作系统，采用了严格的安全策略，包括将关键目录设置为只读，以减少攻击面。

3. Linux目录结构演变：现代Linux发行版逐渐采用/usr合并的目录结构，将传统/lib和/bin等目录变为/usr对应目录的符号链接，这一变化需要相关软件适配。

最佳实践建议

为了避免类似问题，建议在升级Talos系统时：

1. 提前查阅版本变更说明，了解可能影响Kubernetes组件的重要变更。

2. 在测试环境中先行验证升级过程，特别是关注核心Kubernetes组件的状态。

3. 升级后立即检查所有系统组件的运行状态，而不仅仅是集群可用性。

4. 考虑使用自动化工具监控系统升级后的组件健康状态。

通过理解这些底层机制，运维人员可以更好地诊断和解决Talos系统升级过程中遇到的各类问题，确保Kubernetes集群的稳定运行。