Istio Sidecar未注入排查：命名空间标签及自动注入配置正常

以下是针对你遇到的Sidecar未注入问题的具体排查步骤：

• 检查Sidecar注入的MutatingWebhookConfiguration状态
  Istio的自动注入依赖MutatingWebhookConfiguration资源，首先确认该资源是否存在且配置正常：

  kubectl get mutatingwebhookconfiguration istio-sidecar-injector
  

  若资源不存在，说明istiod Helm Chart未正确创建该webhook；若存在，进一步查看其配置细节，重点检查clientConfig中的服务地址和CA证书是否有效：

  kubectl describe mutatingwebhookconfiguration istio-sidecar-injector
  

  注意查看Conditions字段是否有错误状态，或CA证书是否过期/不匹配。

• 确认Deployment无注入排除注解
  检查目标Deployment的Pod模板是否存在阻止注入的注解：

  kubectl get deployment <你的Deployment名称> -n app -o yaml
  

  查看spec.template.metadata.annotations中是否包含sidecar.istio.io/inject: "false"，若存在则会强制禁用Sidecar注入。

• 验证Istio全局注入配置是否生效
  虽然HelmRelease中配置了global.proxy.autoInject: enabled，但需要确认实际生效的Istio配置是否一致：

  kubectl get configmap istio -n istio-system -o yaml
  

  检查meshConfig.defaultConfig.autoInject字段值是否为enabled，同时确认meshConfig中没有针对app命名空间的全局排除规则。

• 查看注入相关日志
  检查istiod的日志，确认是否接收到了Sidecar注入请求，或是否存在注入错误：

  kubectl logs -n istio-system <istiod-Pod名称> | grep injection
  

  若日志中没有针对app命名空间Pod的注入记录，说明MutatingWebhook未触发；若存在错误日志（如证书验证失败、配置解析错误），则根据日志信息定位问题。

• 确认FluxCD的Helm配置已正确应用
  即使HelmRelease显示安装成功，也需验证实际生效的Helm values是否符合预期：

  helm get values istiod -n istio-system
  

  检查输出中global.proxy.autoInject是否为enabled，避免因配置覆盖或Flux同步延迟导致配置未生效。

• 再次核对命名空间标签
  重新确认app命名空间的标签是否正确：

  kubectl get namespace app -o yaml
  

  确保metadata.labels中存在istio-injection: enabled，且无拼写错误（如误写为下划线分隔的istio_injection）。

• 检查Pod关联的ServiceAccount配置
  若Pod使用的ServiceAccount带有注入排除注解，也会阻止Sidecar注入：

  kubectl get serviceaccount <Pod使用的ServiceAccount名称> -n app -o yaml
  

  查看metadata.annotations中是否存在sidecar.istio.io/inject: "false"。

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