KEDA需部署到Kubernetes集群而非Linux系统，应使用Helm安装并严格匹配集群版本（如v1.25.12集群选KEDA v2.12.1），配置国内镜像源，验证CRD与Pod状态，并确保Scaler启用、认证正确、指标可查。
KEDA 在 Linux 上不是“安装到系统”，而是部署到 Kubernetes 集群里；它不依赖宿主机 Linux 发行版，但对集群版本、CRD 支持、Metrics API 有明确要求。装错版本或跳过认证配置，ScaledObject 会一直 Pending 或报 no metrics found。
怎么用 Helm 在 Linux 环境部署 KEDA
你手头有 kubectl 和 helm（v3.8+），且集群能访问公网（或已镜像同步到内网 registry），这是最稳的路径。别用 kubectl apply -f 直接拉 master 分支 YAML —— 它可能不兼容你的 Kubernetes 版本。
- 先查清楚当前集群版本：
kubectl version --short，比如输出Server Version: v1.25.12 - 查 KEDA 兼容表：KEDA v2.12 支持 v1.24–v1.26，v2.10 只到 v1.26；若集群是 v1.21，得选 v2.8（官方已归档，但生产仍可用）
- 添加 Helm 仓库并安装（国内建议换镜像）：
helm repo add kedacore https://kedacore.github.io/charts helm repo update kubectl create namespace keda helm install keda kedacore/keda --namespace keda --version 2.12.1
- 验证是否就绪：
kubectl get pods -n keda，两个 Pod 必须都是Running状态；kubectl get crd | grep keda应返回scaledobjects.keda.sh等三个 CRD
为什么 ScaledObject 一直不触发扩容
90% 的问题出在三处：Scaler 没启用、认证没配对、指标查不到。KEDA 不报错，只沉默——它默认认为“指标为 0”就是“没事件”，于是维持 minReplicaCount 不动。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 确认对应 Scaler 是否已编译进 KEDA：比如用 RocketMQ，得确保安装时启用了
--set features.scalers.rocketmq=true（Helm 默认关部分 Scaler） -
TriggerAuthentication必须和ScaledObject中的triggerAuthenticationRef名字一致，且 Secret 必须在同命名空间（除非显式设scope） - RocketMQ 场景下，
metricType要填QueueLength还是GroupOffset？前者看队列积压数，后者看消费者组 lag，二者逻辑相反；填错会导致值恒为 0 - 手动查指标是否可读：
kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1/namespaces/default/rocketmq-queue-lengths?labelSelector=queue%3Dmy_topic"，如果返回空或 404，说明 Metrics Server 没拿到数据
如何让 Deployment 真正缩到 0 副本
KEDA 缩容到 0 不是靠 HPA，而是靠自己的 Operator 直接 patch replicas 字段。但前提是：Deployment 必须允许被“停用”，且没有其他控制器干扰。
-
minReplicaCount: 0是必要条件，但不够；必须确保ScaledObject中没写死fallback或advanced下的restoreToOriginalReplicaCount为 false - 如果 Deployment 同时被 HPA 管理（比如你额外写了另一个 HPA 对象），KEDA 无法接管缩容逻辑，副本数会被 HPA 锁死在 ≥1
- 缩到 0 后，新消息进来时，KEDA 会先拉起 1 个 Pod，等它 Ready（通过 readinessProbe）后再逐步扩；所以务必配好
readinessProbe，否则 Pod 起来就挂了，反复重启 - 注意：StatefulSet 默认不支持缩到 0，KEDA 会跳过；如需零副本，请改用 Deployment
RocketMQ 场景下最容易漏掉的配置项
阿里云 RocketMQ（或自建 5.x+）对接时，ScaledObject 表面看着对，实际连不上 Namesrv，因为 KEDA 默认不传 accessKey/secretKey，也不自动识别阿里云 RAM 角色。
-
TriggerAuthentication中的 Secret 必须包含rocketmq.accessKey和rocketmq.secretKey两个 key，不能叫别的名字 -
metadata里nameserver值必须是域名+端口格式，比如http://MQ_INST_1234567890abcdef.mq-internet-access.mq.aliyuncs.com:8080，少斜杠或错端口都会静默失败 - 若用阿里云实例 ID（
instanceId）方式连接，nameserver反而要留空，全靠instanceId+ AK/SK 解析；这点和本地 RocketMQ 完全不同 - 消息堆积阈值别设太低：RocketMQ 的
QueueLength是按 Topic+Group 统计的，一个 Group 有 8 个 queue，总堆积 100 条，平均每个 queue 才 12 条——设threshold: "20"就永远扩不起来
真正卡住的点往往不在 YAML 写法，而在 RocketMQ Consumer Group 是否已订阅该 Topic、ACL 是否放行查询权限、Namesrv 是否响应 queryTopicRouteInfo 请求——这些 KEDA 日志里不会明说，得去 kubectl logs -n keda deploy/keda-operator 里搜 rocketmq 和 error。
