KServe中如何配置代理容器转发X-Forwarded-For等请求头

在KServe的实际生产部署中，收集完整的推理日志对于监控和审计至关重要。许多用户会遇到一个常见问题：当通过KServe的代理容器(agent container)转发日志时，关键的HTTP头信息如X-Forwarded-For会丢失。本文将深入分析这个问题并提供解决方案。

问题背景

KServe的代理容器默认会过滤掉部分HTTP头信息，这导致在配置日志收集系统（如Logstash）时，一些重要的请求元数据无法被记录。特别是以下两类信息经常需要保留：

1. 客户端真实IP（通过X-Forwarded-For头传递）
2. 请求追踪ID（如X-Request-Id）

这些信息对于分析请求来源、排查问题以及构建完整的审计追踪链条都非常重要。

技术原理

KServe的代理容器基于Istio的Sidecar设计模式工作，它会在请求到达推理服务前进行预处理。默认配置下，代理会出于安全考虑过滤掉某些敏感的HTTP头。但用户可以通过显式配置来保留特定的头信息。

解决方案

配置metadata-headers参数

代理容器支持通过--metadata-headers参数指定需要保留的HTTP头。这是一个逗号分隔的列表，支持标准和小写形式的头名称。

args:
  - --metadata-headers=x-forwarded-for,x-request-id

在InferenceService中应用配置

在KServe的InferenceService资源定义中，可以通过修改代理容器的启动参数来实现配置：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: my-model
spec:
  predictor:
    containers:
    - name: kserve-container
      image: my-model-image
  logger:
    mode: all
    url: http://logstash-service:8080

注意：实际部署中需要通过修改KServe的全局配置或使用Mutating Webhook来注入这些参数，因为代理容器是由系统自动注入的。

实现建议

1. 全局配置：对于生产环境，建议通过修改KServe的ConfigMap来设置默认的metadata-headers
2. 安全考虑：只暴露必要的头信息，避免敏感信息泄露
3. 版本兼容性：该功能在KServe 0.10.0及以上版本都支持

验证方法

部署修改后，可以通过以下方式验证配置是否生效：

1. 发送带有X-Forwarded-For头的推理请求
2. 检查日志收集系统接收到的日志是否包含该头信息
3. 也可以通过代理容器的日志来调试头信息转发情况

总结

通过合理配置metadata-headers参数，KServe用户可以确保关键的请求头信息能够完整地传递到日志系统。这一功能对于构建企业级的MLOps监控体系非常重要，特别是需要满足合规性要求的场景。建议在生产部署前充分测试不同版本间的兼容性，并根据实际需求调整保留的头信息列表。