Kubernetes 请求、调度与扩缩容：SLB、Ingress、Service、HPA 和 KEDA

理解 Kubernetes 最重要的是分清数据面和控制面：用户请求沿网络组件进入 Pod；Scheduler 和自动扩缩容控制器负责调整系统状态，它们不转发每一条 HTTP 请求。

请求如何进入 Pod

用户
  -> DNS
  -> 云 SLB/ALB
  -> Gateway/Ingress Controller
  -> Service
  -> EndpointSlice 中的健康 Pod
  -> 容器端口

SLB/ALB 提供集群外入口和云网络能力；Ingress 或 Gateway 根据域名、路径等规则选择 Service；Service 提供稳定虚拟地址，并把流量送往动态变化的后端 Pod。

Ingress 资源只是规则，真正执行规则的是 Ingress Controller。当前 Kubernetes 官方建议新能力优先考虑 Gateway API，Ingress API 仍可用但已冻结演进。

Deployment 期望 3 个副本
  -> 控制器创建待调度 Pod
  -> Scheduler 根据资源、亲和性、污点等选择 Node
  -> Node 上的 kubelet 启动容器
  -> 就绪探针成功
  -> Pod 进入 Service 后端集合

Scheduler 调度 Pod，不调度用户请求。Pod 反亲和性可以尽量把副本分散到不同 Node 或可用区，减少单节点故障的影响。

完整链路：

流量或 Lag 上升
  -> HPA/KEDA 增加 Deployment 副本
  -> 新 Pod Pending
  -> 若节点资源不足，节点扩容器增加 Node
  -> Scheduler 放置 Pod
  -> 探针通过后开始接收流量或消费消息

数据面会把不健康后端从可用端点中移除；控制面则发现期望副本不足并在其他节点重建 Pod。若应用使用本地临时数据，Pod 重建并不等于数据恢复，因此状态服务还需要持久卷、复制和备份策略。