弹性 upstream 架构核心是解耦流量入口与后端伸缩：upstream 作为无状态调度中枢，需支持健康探针、动态服务发现与连接治理；后端须满足就绪探测、状态外置、快速启动；k8s 中通过 service/endpoints 自动同步实现扩缩闭环，并按 llm 场景细化 workload 打标与 gpu 感知扩缩。
构建具备弹性扩缩容能力的高性能 upstream 架构模板，核心在于解耦“流量入口”与“后端服务伸缩”，让 upstream 层（如 API 网关、Ingress Controller 或反向代理）稳定承接请求，同时后端服务能按需自动增减实例，并被 upstream 动态感知和负载分发。
明确 upstream 的角色定位
upstream 不是业务逻辑承载层，而是流量调度中枢。它应具备：健康探针自动剔除异常后端、支持平滑权重更新、低延迟 DNS/服务发现刷新（如基于 Kubernetes Endpoints 或 Service Mesh 的 xDS）、连接复用与熔断能力。避免在 upstream 侧做复杂路由或状态管理，把弹性决策交给下层。
- 推荐使用 Nginx Plus、Envoy 或 Traefik 作为 upstream 组件，原生支持动态上游更新和主动健康检查
- 若基于 Kubernetes，直接复用 Service 作为 upstream 抽象，由 kube-proxy 或 CNI 插件完成底层转发，无需自建 Nginx 集群
- 禁止将 upstream 与业务 Pod 打包部署——这会破坏伸缩独立性，导致扩容时 upstream 成为瓶颈
后端服务需满足弹性就绪条件
upstream 要能“安全扩缩”，后端必须做到可发现、可终止、无状态（或状态外置）、启动快。否则缩容会丢请求，扩容后无法及时纳管。
- Pod 必须声明 readinessProbe 和 livenessProbe，且 readinessProbe 在模型加载/缓存预热完成后才返回成功
- 所有状态（如 KV Cache、session、临时文件）必须落盘到外部存储（Redis、对象存储、共享 PV），不能依赖本地磁盘或内存
- 启动时间控制在 15 秒内；大模型服务建议预热镜像（含模型权重）、启用 lazy loading 或分片加载机制
- 使用 Headless Service + StatefulSet（仅当需固定网络标识）或普通 Service + Deployment（推荐）暴露后端
打通自动伸缩闭环：从指标到 upstream 更新
弹性不是“只扩不联”。扩容出的新实例，必须被 upstream 实时识别并纳入流量池，否则等于没扩。
- 在 Kubernetes 中，Deployment 扩容后，Endpoint Controller 自动同步 endpoints 列表，upstream（如 nginx-ingress-controller）监听该变更并热更新 upstream 配置
- 若使用自建 Nginx，需配合 Prometheus + nginx-upstream-check-module + 自研 reload 脚本，或改用支持动态配置的 OpenResty + etcd
- 关键动作要加幂等与灰度：例如每次更新 upstream 时，先探测新节点健康状态，再逐步切 5% 流量，1 分钟后无错误再全量切换
- 缩容前，upstream 应触发 graceful shutdown：停止分发新请求 → 等待现有连接超时或主动 drain（如 Envoy 的 /healthcheck/fail 端点）→ 再通知 K8s 删除 Pod
适配大模型推理的特殊考量
LLM 推理类 upstream 架构还需应对有状态缓存、Prefill/Decode 分离、GPU 资源绑定等现实约束。
- 对 vLLM/TGI 等支持多实例 KV Cache 共享的服务，upstream 应按 workload 类型打标（如 prefill-pool / decode-pool），分别配置不同 upstream 组
- GPU 节点池需单独设置 nodeSelector + tolerations，避免 CPU 型 upstream 错误调度到 GPU 节点；同时为 GPU 实例配置专用 autoscaler（如 Karpenter 支持 GPU-aware 扩容）
- 监控维度不能只看 CPU：重点采集 tokens/sec、pending request queue length、GPU memory used，用这些指标驱动 HPA 或自定义 scaler（如 KEDA）
- 使用 ClusterIP Service 暴露推理服务，而非 NodePort —— 后者在节点扩缩时易引发 IP 变更和连接中断
