OpenShift启用Istio sidecar注入后Pod多次重启问题求助

AI 小北

2026-8-30

问题背景

OpenShift集群部署集成Istio的Red Hat OpenShift Service Mesh Operator后，Helm Chart添加sidecar.istio.io/inject: 'true'注解开启Sidecar注入时，部分Pod需要重启2~3次才能正常运行；移除该注解后Pod无重启异常。
查看Pod事件可观测到如下错误：

Startup probe failed: HTTP probe failed with statuscode: 503
Readiness probe failed: Get "http://10.253.20.228:15021/healthz/ready": dial tcp 10.253.20.228:15021: connect: connection refused
Startup probe failed: Get "http://10.253.20.228:8080/actuator/health/liveness": dial tcp 10.253.20.228:8080: connect: connection refused

已尝试调大startup/liveness/readiness探针所有可配置参数、添加initialDelaySeconds配置，追加以下注解均未解决问题：

status.sidecar.istio.io/port : "0"
sidecar.istio.io/rewriteAppHTTPProbers: "false"
sidecarInjectorWebhook.rewriteAppHTTPProbe: "true"

根因说明

该问题本质是同Pod内容器启动时序不匹配+Sidecar就绪逻辑未对齐导致的探针误判：

OpenShift/Kubernetes默认不保证同Pod内多容器的启动顺序，kubelet并行启动业务容器和istio-proxy Sidecar时，若业务容器或Sidecar的健康检查先执行，会出现端口未监听的connection refused错误。
istio-proxy启动后需要和istiod控制面完成xDS配置同步才能正常转发流量，同步完成前所有经过代理的请求都会返回503，此时探针检测会判定业务异常。
之前配置的注解存在逻辑冲突：status.sidecar.istio.io/port: "0"会直接禁用Sidecar的探针重写能力，sidecar.istio.io/rewriteAppHTTPProbers: "false"关闭了业务探针的Sidecar感知逻辑，错误的配置组合进一步放大了启动时序问题。

解决方案

按优先级从高到低执行以下操作：

开启Sidecar启动阻塞配置（优先推荐，适配OpenShift Service Mesh 2.1及以上版本）
给业务工作负载添加如下注解，强制istio-proxy完全初始化完成后再启动业务容器，从根源消除启动时序差：
```
proxy.istio.io/config: |
  holdApplicationUntilProxyStarts: true
```
该配置会在Sidecar注入阶段自动给istio-proxy添加postStart阻塞逻辑，直到Envoy完成初始化、15021健康端口正常返回就绪状态后，才会放行业务容器的启动流程。
清理冲突注解，开启正确的探针重写
删除之前添加的三个无效/冲突注解，仅保留如下探针重写配置：
```
sidecar.istio.io/rewriteAppHTTPProbers: "true"
```
配置开启后Istio会自动改写业务容器的HTTP探针规则，将探针请求先转发到Sidecar的健康检查端点，只有Sidecar和业务容器同时就绪时探针才会返回成功，避免Sidecar未就绪阶段的探针误判。
适配Spring Boot类应用的探针规则（从端口看业务使用了Spring Boot Actuator组件）
不要盲目调大全量探针的延迟参数，按如下规则调整探针配置：
- 单独配置startupProbe，设置failureThreshold: 30、periodSeconds: 2，预留最长60s的启动窗口覆盖Sidecar和业务的初始化时间
- livenessProbe和readinessProbe不设置initialDelaySeconds，在startupProbe成功后再生效，避免启动阶段存活探针误杀容器
  配置参考：
```
startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  failureThreshold: 30
  periodSeconds: 2
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  periodSeconds: 5
  failureThreshold: 3
```
排查控制面健康状态
执行如下命令检查istiod控制面运行状态，排除控制面异常导致Sidecar无法同步配置的问题：
```
# 替换为实际的Service Mesh控制面命名空间，默认为istio-system
oc get pods -n <istio-system>
oc logs -n <istio-system> <istiod-pod名称> | grep -i 'error\|xds'
```
若存在istiod反复重启、日志报xDS连接失败的问题，先修复控制面异常再验证业务Pod启动状态。

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