KEDA 企业消息队列弹性消费

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

本文缩写（英文全称与中文含义）

缩写	英文全称／名称	中文含义
API	Application Programming Interface	应用程序编程接口
AWS	Amazon Web Services	亚马逊云服务
DLQ	Dead-Letter Queue	死信队列
GCP	Google Cloud Platform	Google 云平台
HA	High Availability	高可用
HPA	Horizontal Pod Autoscaler	Pod 水平自动扩缩容器
IRSA	IAM Roles for Service Accounts	通过 Kubernetes 服务账号关联 AWS IAM 角色
KEDA	Kubernetes Event-driven Autoscaling	Kubernetes 事件驱动自动扩缩容
PDB	Pod Disruption Budget	Pod 中断预算，约束自愿驱逐
SA	Service Account	服务账号，供程序或工作负载使用的身份
SQS	Simple Queue Service	AWS 消息队列服务

场景：真实订单 worker 根据 SQS 积压扩容，限制数据库/下游压力。前置：基线、worker Deployment、预生产队列/DLQ、IRSA、可扩容节点。不能对同一 Deployment 同时保留手写 HPA。

身份与安装#

KEDA operator 只需该队列的 sqs:GetQueueAttributes 等实际 scaler 查询权限；worker 单独角色有 Receive/Delete/ChangeMessageVisibility，二者不共用权限。以下用 provider: aws 的 IRSA 身份，避免已弃用的 scaler identityOwner: operator 用法。AWS 身份

helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm search repo kedacore/keda --versions
export KEDA_VERSION='2.20.0' # 本文渲染基线；先核对集群兼容矩阵
helm show values kedacore/keda --version "$KEDA_VERSION" > keda-defaults.yaml

保存 keda-values.yaml：

下载完整 keda-values.yaml；替换 REPLACE_ 环境输入后保存到当前目录。配置包含资源预算、双副本、单节点故障分散和中断预算。资源是压测起点，不能替代容量测试。

Chart 创建的 SA 名须与 IRSA trust 匹配（检查 rendered manifest）；根据该版本 HA 文档核对 leader election、metrics API 聚合路由和 webhook，确认渲染后的资源、PDB 和反亲和性均存在。

helm upgrade --install keda kedacore/keda -n keda --create-namespace --version "$KEDA_VERSION" -f keda-values.yaml --wait --timeout 10m
kubectl get apiservice v1beta1.external.metrics.k8s.io

Hands-on：受控积压扩容#

保存 orders-scaledobject.yaml，保留最小 2 副本避免冷启动，12 副本上限由数据库连接和消费速率压测得出：

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata: {name: orders-sqs, namespace: orders}
spec:
  podIdentity:
    provider: aws
---
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata: {name: orders-worker, namespace: orders}
spec:
  scaleTargetRef: {name: orders-worker}
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 2
  maxReplicaCount: 12
  fallback: {failureThreshold: 3, replicas: 4}
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 300
          policies: [{type: Pods, value: 1, periodSeconds: 60}]
  triggers:
    - type: aws-sqs-queue
      authenticationRef: {name: orders-sqs}
      metadata:
        queueURL: REPLACE_PREPRODUCTION_QUEUE_URL
        awsRegion: REPLACE_REGION
        queueLength: "20"
        scaleOnInFlight: "true"

kubectl apply -f orders-scaledobject.yaml
kubectl -n orders get scaledobject,hpa
kubectl -n orders describe scaledobject orders-worker

queueLength 是每副本目标积压，并非每秒处理量；包含 in-flight 时需要评估长任务对扩容的影响。cooldownPeriod 主要管回到零，1→N 的缩容行为由 HPA 控制，不能只调 cooldown。SQS scaler

企业验收与恢复#

先投入一批合成账户的真实格式订单，记录入队数量/幂等键、期望结果和账务总额；逐级增加到批准峰值。观察积压年龄、可见/in-flight/DLQ、replicas、节点扩容及数据库连接。要求最终处理结果与输入一致，重复投递不产生重复副作用。

演练单个 worker 优雅终止、消费超过 visibility timeout、下游限流、KEDA 查询角色拒绝：分别验证续租、重投、退避、DLQ 和 fallback/告警。fallback 不修复队列不可达，至少保留人工容量预案。

恢复时先暂停压力与可能重复发布的生产者；通过所选版本的暂停注解或受控删除 ScaledObject，明确 HPA 的清理行为，再固定到安全副本。不要以清空队列消除告警；保留失败消息供重放审计。GCP Pub/Sub 场景替换 scaler 和 Workload Identity，业务幂等与退出协议不变。

配置复核#

安装前按配置验收渲染并检查；节点资源不足导致反亲和性 Pending 时先扩容，不删除保护条件。