在Mutating Webhook中能否修改资源对象的命名空间？

该操作完全可行，你遇到的报错是Kubernetes API Server的前置校验逻辑触发的，该校验发生在Mutating Webhook被调用之前，所以还没走到你的Webhook修改逻辑就被拦截了。

当你创建命名空间级资源时，API Server会优先比对两个命名空间值：

1. 请求URL路径中携带的命名空间（由kubectl命令的-n参数或kubeconfig默认命名空间决定）
2. 请求体中资源的metadata.namespace字段
   二者不一致就会直接返回你遇到的BadRequest错误，不会把请求转发到Mutating Webhook。

1. 提交资源时对齐命名空间值 #

要通过API Server的前置校验，提交资源时必须保证上述两个命名空间值一致，两种实现方式二选一即可：

• 不在CRD的YAML中填写metadata.namespace字段，通过kubectl create -f crd.yaml -n <任意占位命名空间>提交即可，此时请求体的命名空间会被kubectl自动补全为命令指定的命名空间，二者天然一致
• 保持YAML中填写的metadata.namespace值和kubectl命令-n参数指定的值完全相同

2. 调整MutatingWebhookConfiguration配置 #

你需要确保你的Webhook准入配置包含如下设置：

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
webhooks:
- name: <你的Webhook名称>
  rules:
  - apiGroups: ["<你的CRD所属API组>"]
    apiVersions: ["<你的CRD版本>"]
    operations: ["CREATE"]
    resources: ["<你的CRD复数名称>"]
    scope: "Namespaced"
  admissionReviewVersions: ["v1"]
  sideEffects: None
  # 按需配置namespaceSelector或objectSelector过滤需要处理的资源
  # namespaceSelector:
  #   matchLabels:
  #     xxx: xxx

同时要给Webhook对应的ServiceAccount授予对应CRD资源的读写权限。

3. Webhook逻辑调整 #

在Webhook的Mutate逻辑中，直接覆盖请求对象的metadata.namespace字段为你期望的值即可，不需要修改其他关联字段，API Server会在Webhook调用完成后自动完成后续的命名空间权限校验、配额校验等逻辑。你也可以按需在Webhook中提前校验目标命名空间是否存在，提前返回错误给用户。

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