EKS集群Istio Sidecar自动注入失效如何调试排查

1. 先确认Webhook调用链路的实际行为，不要只看配置表面 #

• 检查注入Webhook的后端端点是否可用：执行kubectl get endpoints -n istio-system istio-sidecar-injector，确认返回的端点列表里存在正常Running状态的istiod Pod IP，不存在空端点、端点关联错误端口的问题。如果端点为空，APIServer根本发不出注入请求，在failurePolicy为Ignore的场景下会直接跳过注入，无显性报错。
• 从EKS控制平面审计日志抓Webhook调用记录：开启EKS控制平面的audit日志，筛选Pod创建请求对应的准入控制记录，重点确认3件事：请求是否匹配到istio-sidecar-injector这个MutatingWebhook、APIServer调用该Webhook时是否返回错误、Webhook返回的响应是否明确要求跳过注入。
• 手动对比注入逻辑：拿测试用的最小Pod配置，先执行istioctl kube-inject -f test-pod.yaml拿到本地注入的预期结果，再手动通过API调用istiod的注入接口，确认istiod本身的注入逻辑没有异常。

2. 排查MutatingWebhookConfiguration的隐性配置错误 #

很多时候手动回滚只改了可见的规则部分，漏了关键字段，直接执行以下操作做全量对比：

• 故障状态下导出当前Webhook配置：kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml > webhook-broken.yaml
• 生成重装后的预期Webhook配置：istioctl install -f <你的安装配置文件> --dry-run -o yaml | grep -A 500 "kind: MutatingWebhookConfiguration" > webhook-expected.yaml
• 逐字段对比两个文件的差异，重点排查几个高频出错点：
  • webhooks[].clientConfig.caBundle：是否和istiod实际使用的根CA一致，这个字段是长串base64内容，肉眼很容易漏看，CA不匹配会导致APIServer调用Webhook时TLS校验失败，直接跳过注入。
  • webhooks[].namespaceSelector/objectSelector：是否存在多余的标签匹配要求，比如额外要求Namespace带某个你没配置的标签、或者排除了带某个标签的Pod，导致规则匹配不上。
  • webhooks[].failurePolicy：是否被改成了Ignore，导致Webhook调用失败时没有任何报错直接放行未注入的Pod。
  • webhooks[].rules：匹配的API组、资源、操作范围是否被改窄，比如漏了pods资源的CREATE操作匹配。
• 排查其他MutatingWebhook的干扰：临时将非系统核心、非Istio的MutatingWebhook的failurePolicy改成Ignore，再创建测试Pod验证注入是否恢复，排除其他准入控制器提前修改Pod注解/标签、拦截请求导致Istio注入逻辑不触发的问题。

3. 定位未知配置变更的来源 #

你提到Webhook曾发生无原因变更，重装仅临时恢复，说明集群内存在组件在持续篡改Istio相关配置，按以下路径排查：

• 查看资源的管理字段溯源修改主体：执行kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml，查看metadata.managedFields字段，这里会记录每一次修改的操作账号、修改时间、改动的具体字段，顺着账号找对应的运行组件，常见的篡改源包括：
  • 残留的旧版本Istio Operator、Istio控制平面组件，后台同步错误的历史配置
  • ArgoCD、Flux、Ansible这类配置管理工具，同步了错误的历史版本配置覆盖你的手动修改
  • EKS平台附加组件管理逻辑，如果Istio是通过EKS Marketplace安装的，平台的自动reconcile逻辑可能会覆盖自定义配置
  • 集群内的安全合规控制器，自动修改Webhook的安全配置（比如轮换CA、修改failurePolicy）导致配置不匹配
• 检查istiod运行日志：执行kubectl logs -n istio-system -l app=istiod --tail=300 | grep -E 'inject|webhook|error'，排查是否存在配置加载失败、证书过期、权限不足的显性报错。
• 验证证书轮换状态：执行istioctl pc secret -n istio-system <任意istiod Pod名>，确认Webhook使用的服务证书在有效期内，自动轮换流程正常，证书过期会导致Webhook调用失败，而重装时会重新生成全套证书，所以会临时恢复。

4. 复现故障抓差异定位根因 #

通过重装恢复注入后，写个简单的定时任务每隔30秒导出一次Istio核心资源（MutatingWebhookConfiguration、istio-system命名空间下的Service、Secret、RBAC资源）的配置，直到故障再次复现，直接对比复现前后的配置差异，就能定位到具体是哪个字段被篡改导致的故障。

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