Kube-Hetzner集群升级至K3s 1.32后节点网络故障排查与修复

问题背景

在使用Terraform模块kube-hetzner部署的Kubernetes集群中，当控制平面节点升级到K3s 1.32版本后，部分节点出现异常状况。节点重启后陷入低级别错误状态，主要表现为flannel网络插件所需的subnet.env文件缺失，导致所有Pod卡在CreatingContainer状态。

故障现象分析

集群升级后出现以下典型症状：

1. 节点重启后无法正常启动网络组件
2. 所有Pod创建失败，报错信息显示网络设置失败
3. 系统日志中出现关键错误信息：

   remote_runtime.go:193] "RunPodSandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to setup network for sandbox \"84031c5d3b5c80af82ee80158713c6cf831a1ddc5c01e3ac71a9d5f11ca9aecd\": plugin type=\"flannel\" failed (add): loadFlannelSubnetEnv failed: open /run/flannel/subnet.env: no such file or directory"
   

4. K3s agent启动时出现权限警告：

   reflector.go:547] k8s.io/client-go@v1.30.5-k3s2/tools/cache/reflector.go:232: failed to list *v1.Node: nodes is forbidden: User "system:node:amplitude-storage-fsn1-cax21-xri" cannot list resource "nodes" in API group "" at the cluster scope: node 'amplitude-storage-fsn1-cax21-xri' cannot read all nodes, only its own Node object
   

根本原因

经过深入分析，发现问题源于Kubernetes 1.32版本引入的一项安全改进。该版本默认限制了节点的权限，节点用户(system:node)默认只能访问自己的Node对象，而无法列出集群中的所有节点。

对于使用flannel网络插件的集群来说，这是一个严重问题，因为flannel需要能够列出所有节点才能完成网络配置。具体来说：

1. flannel需要获取集群中所有节点的网络信息来生成subnet.env文件
2. 由于权限限制，flannel无法获取这些信息
3. 导致subnet.env文件无法生成
4. 进而导致所有Pod无法创建网络接口
5. 系统陷入死循环，无法自动恢复

解决方案

临时修复方案

通过创建ClusterRoleBinding为system:nodes组授予system:node ClusterRole的权限：

kubectl create clusterrolebinding node-listing \
  --clusterrole=system:node \
  --group=system:nodes

这个方案能够立即解决问题，因为它恢复了节点列出其他节点的权限，允许flannel正常工作。

长期建议

虽然上述方案可以解决问题，但从安全角度考虑，更精细化的权限控制更为理想。建议采用以下方案之一：

1. 精确权限控制：仅为flannel组件创建专用的ServiceAccount，并授予最小必要权限

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: flannel-node-reader
   rules:
   - apiGroups: [""]
     resources: ["nodes"]
     verbs: ["get", "list", "watch"]
   
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: flannel-node-reader
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: flannel-node-reader
   subjects:
   - kind: ServiceAccount
     name: flannel
     namespace: kube-system
   

2. CNI插件升级：考虑迁移到其他CNI插件如Cilium或Calico，这些插件可能对权限要求不同

3. K3s配置调整：在K3s配置中预先设置必要的RBAC规则

预防措施

为避免类似问题在未来升级时再次发生，建议：

1. 在非生产环境先测试主要版本升级
2. 仔细阅读Kubernetes和K3s的版本变更说明
3. 建立完善的监控系统，及时发现节点和网络异常
4. 考虑使用Pod安全策略和网络策略加强安全性

总结

Kubernetes 1.32版本的权限收紧是一项重要的安全改进，但可能对依赖特定权限的组件(如flannel)造成影响。在升级前，管理员应充分了解变更内容，并准备好相应的调整方案。对于使用kube-hetzner模块的用户，建议在升级到K3s 1.32或更高版本前，预先评估网络插件的权限需求，并做好相应的RBAC配置。