开启Istio自动注入的K8s命名空间重部署Nginx遇502错误求助

问题背景 #

在Kubernetes集群的eshop-bg-poc命名空间中，开启了Istio自动注入，运行着eshop-bgpoc-nginx服务，副本数配置为最小3个、最大5个。执行Nginx重新部署操作时，会出现持续数秒的502 Bad Gateway错误；关闭该命名空间的Istio自动注入后，重新部署则不会再出现这个问题。需说明的是，该服务未配置任何Virtual Service和Destination Rule。

问题根源 #

这是Istio的一个已知问题：当服务没有配置Virtual Service和Destination Rule时，Istio默认的流量路由逻辑在处理滚动更新时，无法确保新Pod的Sidecar完全完成服务发现同步、就绪后再终止旧Pod。旧Pod被终止后，流量会被转发到尚未就绪的新Pod Sidecar，从而导致502错误。

可行解决方案 #

1. 给Nginx Pod配置就绪探针 #

添加就绪探针可以确保只有当Nginx本身和Istio Sidecar都完全就绪后，Pod才会被纳入服务的流量池，避免流量被提前转发到未就绪的实例：

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 5

2. 配置Virtual Service和Destination Rule #

通过Destination Rule设置流量策略（比如连接池、异常实例驱逐），让Istio更智能地处理滚动更新时的流量分发：

# Destination Rule 示例
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: eshop-bgpoc-nginx
  namespace: eshop-bg-poc
spec:
  host: eshop-bgpoc-nginx
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 100
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 3
      interval: 10s
      baseEjectionTime: 30s

3. 调整Deployment滚动更新策略 #

修改Deployment的滚动更新参数，限制滚动过程中不可用的Pod数量，给Sidecar足够的时间完成服务同步：

strategy:
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0
  type: RollingUpdate

4. 临时关闭命名空间的Istio自动注入 #

如果是紧急恢复场景，可以临时关闭eshop-bg-poc命名空间的Istio自动注入，代价是该命名空间内的服务将失去Istio的流量管理能力：

kubectl label namespace eshop-bg-poc istio-injection-

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