Kubernetes集群中长时后端任务的请求路由解决方案咨询

针对你的视频转换场景，以下是几种无需粘性会话、低开销的解决方案，适配Spring Boot和Kubernetes环境：

1. Headless Service + Pod直连请求 #

这是最直接的方案，让前端后续请求直接指向处理初始上传的Pod：

• 部署Headless Service：创建不带ClusterIP的Headless Service，每个Pod会获得独立的DNS记录（格式：{pod-name}.{service-name}.{namespace}.svc.cluster.local）

  apiVersion: v1
  kind: Service
  metadata:
    name: video-conversion-service
  spec:
    clusterIP: None # 标记为Headless
    selector:
      app: video-conversion
    ports:
      - port: 8080
        targetPort: 8080
  

• Spring Boot获取Pod标识：通过K8s环境变量或Downward API获取当前Pod的名称和服务域名，代码示例：

  @Value("${POD_NAME}")
  private String podName;
  
  @Value("${SERVICE_NAME:video-conversion-service}")
  private String serviceName;
  
  @Value("${NAMESPACE:default}")
  private String namespace;
  
  private String getPodDns() {
      return String.format("%s.%s.%s.svc.cluster.local", podName, serviceName, namespace);
  }
  

• 返回直连URL：处理初始上传请求时，生成任务ID，同时返回带Pod DNS的状态查询和下载URL（比如http://{pod-dns}/api/tasks/{taskId}/status），前端后续直接请求该地址。

注意：如果Pod在任务执行中被销毁（比如缩容、节点故障），前端会请求失败，需要在前端添加重试逻辑，或后端在Pod终止前将任务状态标记为失败。

2. 任务ID映射路由（轻量共享存储） #

用极小开销的共享存储（如Redis）记录任务ID与Pod的映射，通过API网关实现定向路由：

• 记录映射关系：初始上传请求到达任意Pod后，生成唯一任务ID，将任务ID -> Pod IP/名称的键值对存入Redis，同时返回带任务ID的状态URL（比如/api/tasks/{taskId}/status）
• 网关路由逻辑：用Spring Cloud Gateway或NGINX Ingress作为入口，拦截状态查询和下载请求，从Redis获取任务对应的Pod地址，将请求转发到该Pod。
• 清理映射：任务完成或超时后，删除Redis中的映射记录，避免内存占用。

优势：无需前端修改直连逻辑，兼容现有请求路径，仅需维护极小的映射数据，开销远低于存储视频文件。

3. StatefulSet + 稳定网络标识 #

如果你的视频转换Pod数量固定、任务生命周期较长，可以用StatefulSet替代Deployment：

• StatefulSet特性：每个Pod拥有稳定的网络标识（格式：{statefulset-name}-{ordinal}.{service-name}）和可选的稳定本地存储（LocalPV）
• 任务绑定策略：初始上传请求可通过负载均衡分配到任意StatefulSet Pod，后续前端请求直接使用该Pod的稳定DNS地址进行轮询和下载。
• Spring Boot适配：利用StatefulSet的稳定标识，可在应用中更可靠地管理任务数据和存储。

适合场景：Pod规模固定、对任务连续性要求较高的场景，避免Deployment中Pod IP/名称动态变化的问题。

4. 临时Service动态绑定（进阶方案） #

针对一次性任务，可动态创建临时Service指向处理上传的Pod，任务完成后销毁：

• K8s API权限配置：给Pod分配创建/删除Service的RBAC权限，确保Spring Boot应用可调用K8s API
• 动态创建Service：处理初始上传时，生成任务ID，调用K8s API创建一个临时Service（比如task-{taskId}-service），指向当前Pod
• 返回临时Service地址：将临时Service的DNS地址作为状态和下载URL返回给前端，任务完成后调用API删除该Service

注意：该方案需要应用具备K8s API操作能力，适合对资源控制严格的场景，避免长期闲置Service占用资源。

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