Istio 1.0.6侧车代理上游Pod重连问题排查求助

结合你描述的现象和日志，这是Istio 1.x早期版本针对gRPC连接处理的典型已知问题，我来帮你拆解原因并给出具体解决方案：

核心原因分析 #

Istio 1.0.6搭载的是旧版本Envoy，在gRPC连接池管理和上游故障检测上存在明显缺陷：

• 当abc-server重启后，客户端侧车的上游连接池仍保留着失效连接，但处理gRPC健康检查请求时，错误地返回200状态码（即使日志标记了UF上游失败），导致客户端误以为服务正常，没有触发自身重连逻辑。
• 旧版本Istio对gRPC连接复用、故障实例驱逐的逻辑不完善，无法及时清理失效的上游连接。

具体解决方案 #

1. 优先升级Istio版本（最彻底的解决方式）

Istio 1.0.x是2018年的老旧版本，后续1.1.x及以上版本修复了大量gRPC相关的连接问题，包括连接池失效、健康检查误判等。建议升级到至少1.1.x稳定版本，或直接切换到更近期的LTS版本，这会从根源上解决这类兼容性问题。

2. 配置DestinationRule优化连接池与故障检测（临时适配方案）

如果暂时无法升级，可通过DestinationRule强制Envoy正确检测上游故障并刷新连接池：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: abc-server-dr
  namespace: abc-namespace
spec:
  host: abc-server.abc-namespace.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
        connectTimeout: 1s
      http:
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xx: 1
      interval: 5s
      baseEjectionTime: 30s
      maxEjectionPercent: 100

这个配置的作用：

• 限制连接池大小，避免留存过多失效连接
• 缩短连接超时，快速感知上游故障
• 开启异常实例驱逐：只要收到1次上游失败就将实例从池中驱逐，30秒后再尝试重新连接

3. 调整gRPC客户端的重试策略

在你的Go gRPC客户端中添加针对Unavailable状态的重试逻辑，确保即使侧车返回错误的200，客户端也会主动触发重连：

import (
    "google.golang.org/grpc"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
)

// 创建带重试拦截器的客户端连接
func NewABCServerConn() (*grpc.ClientConn, error) {
    retryInterceptor := func(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
        // 最多重试3次
        for i := 0; i < 3; i++ {
            err := invoker(ctx, method, req, reply, cc, opts...)
            if err == nil {
                return nil
            }
            // 仅当错误为Unavailable时重试
            if s, ok := status.FromError(err); ok && s.Code() == codes.Unavailable {
                continue
            }
            return err
        }
        return status.Errorf(codes.Unavailable, "failed after 3 retries")
    }

    return grpc.Dial(
        "abc-server.abc-namespace:8086",
        grpc.WithInsecure(),
        grpc.WithUnaryInterceptor(retryInterceptor),
    )
}

4. 验证服务端健康检查正确性

确保abc-server的gRPC健康检查服务/grpc.health.v1.Health/Check能正确返回服务状态：服务重启过程中应暂时返回非健康状态，这样Istio侧车才能准确识别实例可用性。

总结 #

最推荐的方案是升级Istio版本，旧版本的兼容性问题较多；如果暂时无法升级，结合DestinationRule配置和客户端重试策略可以有效缓解该问题。

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