Istio Virtual Service子集无法将请求路由到指定Pod求助

问题排查与解决方案 #

核心问题：请求头未从FastAPI传递到Users服务

你发起的curl请求将x-user-testing头发送给了FastAPI网关，但FastAPI作为中间层，默认不会把HTTP请求头转发给后端的gRPC服务。Istio的VirtualService规则作用在服务间的调用链路（即FastAPI → Users）上，而非用户→FastAPI的链路，因此如果FastAPI不传递这个头，VirtualService的匹配条件永远不会触发。

解决方案1：修改FastAPI代码，传递请求头到gRPC服务

在FastAPI调用Users gRPC服务的逻辑中，需要从HTTP请求中提取x-user-testing头，并将其添加到gRPC请求的metadata中。示例代码如下：

from fastapi import FastAPI, Request
import grpc
from your_users_proto import users_pb2, users_pb2_grpc

app = FastAPI()

@app.get("/users")
async def get_users(request: Request):
    # 提取HTTP请求头
    testing_header = request.headers.get("x-user-testing")
    # 构建gRPC channel和stub
    channel = grpc.insecure_channel("users:9090")
    stub = users_pb2_grpc.UsersStub(channel)
    # 构建metadata并传递头
    metadata = []
    if testing_header:
        metadata.append(("x-user-testing", testing_header))
    # 发起gRPC请求
    response = stub.GetUsers(users_pb2.GetUsersRequest(), metadata=metadata)
    return {"users": response.users}

其他排查验证步骤

1. 确认Istio Sidecar注入状态
   检查所有相关Pod是否已注入Istio Sidecar（每个Pod应包含业务容器和istio-proxy容器）：

   kubectl get pods -l app=users
   kubectl get pods -l app=fastapi
   

   若未注入，需确认目标Namespace开启了Sidecar自动注入，或手动执行注入命令。

2. 验证v2版本镜像正确性
   你的users-v2 Deployment使用的镜像与v1完全一致（users:v0.0.1），这会导致即使路由到v2，服务行为也和v1无差异。请替换为v2版本的专属镜像（如users:v0.0.2）。

3. 直接测试服务间调用
   进入FastAPI的Pod内部，用grpcurl直接调用Users服务并携带头，验证路由规则是否生效：

   kubectl exec -it <fastapi-pod-name> -- /bin/bash
   # 安装grpcurl（若未预装）
   apt-get update && apt-get install -y grpcurl
   # 调用gRPC服务并传递头
   grpcurl -H "x-user-testing: tester" users:9090 users.UsersService/GetUsers
   

   若此请求能路由到v2，说明VirtualService配置正确，问题确实出在FastAPI未传递请求头。

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