K8s 1.17集群部署Istio 1.8.1后sidecar注入webhook调用超时无法创建Pod

前置场景对齐 #

• 运行环境：Kubernetes 1.17.14-gke.400 集群，采用minimal安装模式部署Istio 1.8.1，启用CNI组件部署在kube-system命名空间，配置的排除命名空间列表为kube-system、istio-system、backend
• 故障现象：部署sleep示例时Pod创建失败，触发sidecar-injector webhook调用超时，两类报错分别为：
  • 请求已送达目标服务但响应超时：Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istiod.istio-system.svc:443/inject?timeout=30s: context deadline exceeded
  • 连接建立阶段超时：Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istiod.istio-system.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
• 已验证的非故障项：istiod服务本身运行正常，从集群节点/工作负载手动curl访问inject端点可正常返回400状态码；kube-system、istio-system命名空间未配置自定义网络规则。

核心矛盾定位 #

两类超时报错的触发链路和手动curl通畅的核心差异，是问题排查的关键：

• 手动curl的流量路径：从节点本地/集群Pod直接发往istiod Pod IP，不经过托管API Server的跨域路由、CNI的外层拦截链，因此链路通畅
• API Server的webhook调用路径：从托管的API Server入口发往集群内的istiod Service，链路经过VPC跨域路由、节点网络栈、CNI拦截规则、网络策略四层校验，任意一层出现规则不匹配、链路延迟过高都会触发超时

排查与解决步骤 #

• 校验Webhook配置的基础正确性
  执行kubectl get mutatingwebhookconfiguration istio-sidecar-injector -o yaml，重点检查两个字段：
  • caBundle字段的证书内容是否与istiod当前签发的CA证书完全匹配：如果证书不匹配，API Server会在TLS握手阶段长时间等待，触发连接超时类报错，这也是手动curl因为忽略证书校验能连通、但API Server严格校验证书时不通的常见原因
  • timeoutSeconds参数：低版本GKE 1.17的托管API Server到集群内Service的跨域路由默认延迟较高，可将原30s的超时值调整为60s，兼容链路延迟
• 排查CNI组件的规则拦截副作用
  Istio 1.8版本的CNI组件会在节点内核生成流量拦截规则，虽然你配置了命名空间排除规则，但CNI的规则匹配是基于流量经过的网络栈层级，不是仅基于目标命名空间：
  1. 登录任意集群节点，执行iptables-save | grep ISTIO，检查是否存在源IP为GKE托管API Server出口段的流量被REJECT/LOG_DROP的规则。这类被拦截的流量因为istiod Pod没有sidecar代理承接，会被CNI规则直接丢弃，导致API Server的连接请求超时；而本地发起的curl请求不经过CNI的拦截链，因此可以正常连通
  2. 若存在拦截规则，重新安装Istio时增加配置参数：--set values.cni.excludeSourcePrefixes[0]=<GKE API Server出口IP段>，将API Server来源的流量纳入CNI的豁免列表，跳过透明流量拦截
• 校验Service与Endpoint的匹配规则
  执行kubectl get svc -n istio-system istiod -o wide和kubectl get endpoints -n istio-system istiod -o wide，确认：
  • Service暴露的443端口映射到的目标端口与istiod Pod实际监听的15017端口一致
  • Service的端口命名格式与GKE默认网络策略的匹配规则一致：GKE默认自动放行API Server流量的规则，是基于端口名包含https、webhook的关键字做匹配，如果端口名被修改为无匹配关键字，会导致默认放行规则失效，触发连接超时
• 网络策略的兜底验证
  临时在istio-system命名空间创建一个全放行的入站网络策略，允许所有来源的443端口入站流量：如果调整后webhook调用不再超时，说明之前的默认网络策略粒度不足，未覆盖API Server到istiod的访问路径。

内容的提问来源于stack exchange，提问作者Michael St Clair