Kubernetes Autoscaler项目中VPA准入控制器在kube-system命名空间的限制问题分析

问题背景

在Kubernetes集群中，Vertical Pod Autoscaler（VPA）是一个重要的自动伸缩组件，它能够根据工作负载的资源使用情况自动调整Pod的CPU和内存请求。然而，在Azure Kubernetes Service（AKS）环境中，用户发现VPA的准入控制器无法正确处理kube-system命名空间中的Pod资源调整请求。

问题现象

当VPA尝试调整kube-system命名空间中的Pod资源时，会出现以下现象：

1. VPA推荐器（Recommender）能够正常生成资源调整建议
2. VPA更新器（Updater）会触发Pod的驱逐操作
3. 但准入控制器（Admission Controller）无法应用这些资源调整建议
4. 导致Pod被不断驱逐重启，但资源请求始终未被修改

根本原因分析

通过深入分析，发现问题的根源在于AKS对kube-system命名空间的特殊保护机制：

1. AKS默认会为kube-system命名空间添加特定标签：

   • control-plane: "true"
   • kubernetes.azure.com/managedby: aks

2. VPA的MutatingWebhookConfiguration配置中包含了namespaceSelector，它会排除带有这些标签的命名空间：

   namespaceSelector:
     matchExpressions:
     - key: kubernetes.io/metadata.name
       operator: NotIn
       values:
       - ""
     - key: kubernetes.azure.com/managedby
       operator: NotIn
       values:
       - aks
     - key: control-plane
       operator: NotIn
       values:
       - "true"
   

3. 这种设计是AKS的安全机制，旨在保护关键系统组件不被意外修改

解决方案

针对这一问题，社区提供了几种可行的解决方案：

方案一：禁用自动注册Webhook

通过为VPA准入控制器添加--register-webhook=false参数，禁用其自动注册MutatingWebhookConfiguration的功能。然后手动创建Webhook配置，确保不排除kube-system命名空间。

方案二：修改Webhook配置标签

社区已合并的PR增加了为MutatingWebhookConfiguration添加特定标签的功能，使得AKS能够识别并允许该Webhook操作kube-system命名空间。可以通过以下方式实现：

1. 为VPA准入控制器添加--webhook-label参数
2. 设置标签如admissions.enforcer/disabled: "true"

方案三：使用AKS管理的VPA

AKS提供了自己的VPA实现，已经内置了对kube-system命名空间的支持，可以直接使用。

技术实现细节

在VPA准入控制器的实现中，Webhook的注册是通过config.go文件中的相关逻辑完成的。新增的标签功能主要通过以下方式实现：

1. 在启动参数解析中添加webhook-label选项
2. 在创建MutatingWebhookConfiguration时应用这些标签
3. 确保标签在控制器重启后能够保持

最佳实践建议

对于需要在kube-system命名空间中使用VPA的用户，建议：

1. 评估是否真的需要调整系统组件的资源请求
2. 如果必须调整，优先考虑使用AKS管理的VPA方案
3. 如需使用上游VPA，建议采用方案二，并确保标签配置正确
4. 在生产环境部署前，充分测试验证功能

总结

Kubernetes Autoscaler项目中的VPA组件在AKS环境下处理kube-system命名空间时存在限制，这主要是由于平台的安全设计导致。通过理解其背后的机制，用户可以选择合适的解决方案来满足特定需求。社区已经提供了灵活的配置选项，使得用户能够在保证系统稳定性的同时，实现关键工作负载的自动资源调整。