MicroK8s 1.32升级后kill-host-pods权限错误分析与解决方案

问题背景

在将MicroK8s集群从旧版本升级到1.32后，系统日志中开始频繁出现权限错误信息。这些错误每5秒就会记录一次，主要涉及kill-host-pods.py脚本执行失败，错误提示用户system:node:myhostname没有权限在集群范围内列出pod资源。

错误现象

具体错误表现为：

1. API服务器返回403 Forbidden错误
2. 用户system:node:myhostname被拒绝执行list pods操作
3. 错误信息明确指出该用户只能通过spec.nodeName字段选择器来列出/监视pod

根本原因分析

这个问题源于Kubernetes 1.32版本引入的一项新安全特性。在Kubernetes 1.32中，默认启用了AuthorizeNodeWithSelectors特性门控，该特性对节点(kubelet)的API访问权限实施了更严格的限制。

在旧版本中，节点(kubelet)可以相对自由地访问API资源。但在1.32中，出于安全考虑，节点的权限被限制为只能访问与其自身相关的资源。具体到这个问题，节点只能列出或监视那些spec.nodeName字段匹配自身节点名称的pod。

影响范围

这个变更主要影响以下场景：

1. 任何需要节点(kubelet)访问全局pod列表的操作
2. 依赖于节点广泛权限的自定义脚本或工具
3. MicroK8s特有的kill-host-pods.py维护脚本

解决方案

目前有两种可行的解决方案：

临时解决方案

在kube-apiserver的启动参数中添加：

--feature-gates=AuthorizeNodeWithSelectors=false

这个方案会禁用新的安全限制，恢复到旧版本的行为模式。但这不是推荐的长久之计，因为它降低了集群的安全性。

长期解决方案

更合理的做法是修改kill-host-pods.py脚本，使其在查询pod时添加节点选择器条件。例如将查询命令从：

kubectl get pod -o json -A

改为：

kubectl get pod -o json --field-selector spec.nodeName=$(hostname)

这样既符合新的安全模型，又能实现原有功能。

最佳实践建议

1. 对于生产环境，建议采用第二种方案，保持安全限制的同时调整应用逻辑
2. 定期检查集群中的自定义脚本和工具，确保它们符合最新的Kubernetes安全规范
3. 升级前仔细阅读版本变更说明，特别是安全相关的变更
4. 考虑使用RBAC为特殊需求配置精确的权限，而不是放宽全局限制

总结

Kubernetes 1.32通过AuthorizeNodeWithSelectors特性加强了节点权限管理，这是安全加固的一部分。MicroK8s用户遇到这个问题时，应该优先考虑调整应用逻辑来适应新的安全模型，而不是简单地禁用安全特性。这种变化体现了Kubernetes向更安全的默认配置发展的趋势，开发者和管理员需要相应调整自己的工具和实践。