RKE2集群中启用PodNodeSelector准入控制器的注意事项

问题背景

在Kubernetes集群管理中，准入控制器(Admission Controller)是一种强大的机制，它能够在API请求被持久化之前拦截请求，进行验证或变更操作。其中PodNodeSelector是一个常用的准入控制器，它允许管理员通过节点选择器(Node Selector)来限制Pod可以被调度到哪些节点上。

问题现象

在RKE2集群(v1.32.3+rke2r1版本)中，当尝试通过修改配置文件启用PodNodeSelector准入控制器时，节点无法正常启动。具体表现为在/etc/rancher/rke2/config.yaml中添加如下配置后：

kube-apiserver-arg:
  - enable-admission-plugins=NodeRestriction,PodNodeSelector

执行systemctl restart rke2-server命令后，服务无法正常启动，节点状态异常。

根本原因分析

通过深入排查发现，问题的根源并非RKE2本身，而是集群中已部署的Gatekeeper组件。Gatekeeper是一个基于OPA(Open Policy Agent)的Kubernetes策略控制器，它通过动态准入控制Webhook来实现策略执行。

当API服务器尝试启动时，它会调用所有已注册的准入控制Webhook。由于Gatekeeper服务(监听8443端口)尚未就绪，导致API服务器无法完成启动过程，进而造成整个节点启动失败。具体表现为：

1. API服务器尝试调用Gatekeeper的Webhook服务(https://gatekeeper-webhook-service.gatekeeper-system.svc:443/v1/mutate)
2. 由于Gatekeeper未就绪，连接超时(1秒超时设置)
3. API服务器启动流程被阻塞
4. RKE2节点无法完成初始化

解决方案

针对这一问题，有以下几种解决方案：

1. 临时方案：在API服务器启动参数中暂时禁用Gatekeeper Webhook

   kube-apiserver-arg:
     - enable-admission-plugins=NodeRestriction,PodNodeSelector
     - admission-control-config-file=/path/to/config.yaml
   

   在config.yaml中配置Webhook的失败策略为Ignore。

2. 推荐方案：如果不再需要Gatekeeper功能，可以完全卸载该组件：

   helm uninstall gatekeeper -n gatekeeper-system
   

3. 长期方案：确保Gatekeeper组件在API服务器启动前就已就绪，可以通过调整部署顺序或添加init容器来实现。

最佳实践建议

在RKE2集群中启用新的准入控制器时，建议遵循以下步骤：

1. 首先检查集群中已安装的准入控制Webhook

   kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations
   

2. 在非生产环境测试配置变更

3. 使用渐进式启用策略，先在小范围节点上测试

4. 确保关键组件(如Gatekeeper)的高可用性

5. 监控API服务器的启动日志，及时发现潜在问题

总结

在Kubernetes集群管理中，准入控制器的配置需要谨慎处理。特别是在RKE2这样的发行版中，当集群已经部署了其他策略管理工具(如Gatekeeper)时，更需要注意组件间的启动依赖关系。通过理解系统各组件的工作原理和交互方式，可以有效避免类似问题的发生，确保集群的稳定运行。