同一Kubernetes集群部署多验证Webhook：AKS部署独立Gatekeeper问询

该部署模式完全可行，已在多个生产级AKS集群中完成验证，不会和Azure Policy预安装的Gatekeeper实例产生冲突。
Azure预装的Gatekeeper运行在gatekeeper-system命名空间下，所有关联资源（集群级Webhook配置、RBAC权限、控制器标识）都带有Azure专属的资源前缀和标签，和开源社区版Gatekeeper的默认部署资源天然隔离。

部署开源社区版Gatekeeper前，需要对官方部署清单做以下修改，彻底避免资源冲突：

• 替换默认部署命名空间，不要使用gatekeeper-system，建议改为custom-gatekeeper-system这类自定义命名空间
• 所有资源名称前缀替换：将默认的gatekeeper前缀改为自定义前缀（例如custom-gatekeeper），覆盖以下资源类型：
  • ValidatingWebhookConfiguration、MutatingWebhookConfiguration集群级配置
  • 控制器Deployment、ServiceAccount、ClusterRole、ClusterRoleBinding
• 调整控制器启动参数：
  • 若要和预装Gatekeeper共享CRD，不需要修改CRD配置，只需给开发者账号授予constraints.gatekeeper.sh、templates.gatekeeper.sh两类CRD的读写权限即可
  • 若要完全隔离CRD，添加启动参数--crd-prefix=custom.，自定义Gatekeeper会自动识别custom.constraints.gatekeeper.sh这类带前缀的独立CRD，和预装实例的策略完全互不干扰
  • 修改选举ID参数：将默认的gatekeeper-controller-manager选举ID改为自定义值，避免两个实例的控制器选举冲突
• 调整自定义Webhook的规则：建议将failurePolicy设为Ignore避免策略异常影响集群核心业务，同时通过namespaceSelector排除kube-system、gatekeeper-system等系统命名空间的资源校验。

• 执行kubectl get validatingwebhookconfiguration，确认两个Webhook配置均正常存在，分别对应Azure预装实例和自定义实例
• 用开发者账号提交测试用的ConstraintTemplate和Constraint，确认自定义Gatekeeper可以正常执行校验逻辑，同时Azure Policy原有策略不受影响
• 验证系统命名空间的资源变更不会被自定义Gatekeeper拦截

内容的提问来源于stack exchange，提问作者Utopia