Kubernetes Autoscaler项目中addon-resizer在K8s 1.30版本的RBAC权限问题解析

在Kubernetes生态系统中，Autoscaler项目中的addon-resizer组件负责自动调整工作负载资源请求，以确保集群资源得到合理分配。近期有用户报告在将Azure Kubernetes Service(AKS)从1.29升级到1.30版本后，addon-resizer组件开始出现RBAC权限相关的错误。

问题现象

升级到Kubernetes 1.30版本后，addon-resizer组件日志中频繁出现"Unauthorized"错误，主要涉及以下API资源的访问失败：

• 部署(Deployment)列表操作
• 节点(Node)列表操作
• Pod列表操作

这些错误表明组件失去了对关键Kubernetes资源的访问权限，导致其无法正常执行自动调整功能。

根本原因分析

经过深入分析，这个问题源于两个关键因素：

1. Kubernetes 1.30的RBAC权限模型变更：新版本可能加强了对某些API资源的访问控制要求，或者修改了默认的权限授予方式。

2. 共享服务账户架构：问题中提到的部署方式是将addon-resizer作为kube-state-metrics部署中的一个容器运行，两者共享同一个服务账户(ServiceAccount)。这种架构设计使得权限管理变得复杂，难以精确控制每个组件的最小权限。

解决方案

针对这个问题，推荐采取以下解决方案：

1. 升级addon-resizer版本：将组件升级到1.8.11或更高版本，这些版本针对新Kubernetes版本进行了优化和适配。

2. 独立部署架构：将addon-resizer从kube-state-metrics中分离出来，作为独立的部署运行。这种架构有以下优势：

   • 可以为每个组件单独配置服务账户和RBAC权限
   • 更容易遵循最小权限原则
   • 组件间故障隔离性更好
   • 便于单独升级和维护

3. 精细化RBAC配置：确保为addon-resizer配置了正确的ClusterRole和RoleBinding，特别是对于Deployment资源的get和update操作权限。

最佳实践建议

基于此案例，我们总结出以下Kubernetes组件部署的最佳实践：

1. 避免服务账户共享：关键组件应使用独立服务账户，便于权限管理和审计。

2. 遵循最小权限原则：只为组件配置其正常运行所需的最小权限集。

3. 及时组件升级：在升级Kubernetes集群版本时，应同步评估并升级相关组件版本。

4. 监控权限错误：在日志监控中设置对"Unauthorized"错误的告警，及时发现权限问题。

通过采用这些最佳实践，可以显著提高Kubernetes集群中组件运行的稳定性和安全性。