KEDA 不能在 Linux 主机上直接安装，因为它是一个依赖 Kubernetes API Server、CRD、Webhook 等核心能力的控制器，仅支持通过 Helm 在 K8s 集群中部署，无独立二进制或 systemd 服务。
KEDA 不能直接在 Linux 主机上“安装”，它是一个 Kubernetes 原生组件，必须部署在运行中的 K8s 集群内；单独在裸机 Linux 上装 KEDA 没有意义，也起不来。
为什么不能在 Linux 主机上直接装 KEDA？
-
KEDA是一个 Kubernetes 控制器（Controller）+ 自定义资源（ScaledObject,TriggerAuthentication等），依赖 K8s API Server、CRD 注册机制、Webhook、Metrics API 聚合层等核心能力 - 它不提供独立二进制或 systemd 服务，没有
keda-server或keda-cli这类本地可执行文件 - 所有官方文档、Helm Chart、Operator 都面向 K8s 集群部署场景，不存在 “Linux 下安装 KEDA” 的 valid path
常见误解来源：看到 helm install 在 Linux 终端里执行，就以为是“装在 Linux 上”——实际是把 Helm client 运行在 Linux，操作远端 K8s 集群。
真正要做的：在 K8s 集群中用 Helm 部署 KEDA
前提是你的 Linux 机器能访问目标 K8s 集群（即 kubectl get nodes 可通），且已安装 helm CLI。
-
添加仓库并更新：
helm repo add kedacore https://kedacore.github.io/charts helm repo update
-
查看可用版本（注意兼容性！）：
helm search repo keda --versions
> ✅ 关键点：TKE 1.26 集群只能用 KEDA v2.12.x（对应 Chart 2.12.1），v2.13+ 会因 CRD 或 API 版本不兼容导致CustomResourceDefinition创建失败或控制器 CrashLoopBackOff -
准备
values.yaml（国内必须改镜像）：image: keda: repository: docker.io/imroc/keda metricsApiServer: repository: docker.io/imroc/keda-metrics-apiserver webhooks: repository: docker.io/imroc/keda-admission-webhooks
> ⚠️ 不改镜像会导致ImagePullBackOff：默认镜像托管在ghcr.io，国内拉取极慢甚至超时 -
执行部署（命名空间自动创建）：
helm upgrade --install keda kedacore/keda \ --namespace keda --create-namespace \ --version 2.12.1 \ -f values.yaml
-
验证是否就绪：
kubectl get pods -n keda kubectl get crd | grep keda
应看到keda-controller,keda-metrics-apiserver,keda-admission-webhooks全部 Running，且出现scaledobjects.keda.sh等 CRD
配置 ScaledObject 时容易踩的坑
-
scaleTargetRef.name必须和目标 Deployment/StatefulSet 的metadata.name完全一致，大小写敏感，不能填 label 值 -
triggers.type: kubernetes-workload的podSelector是 label selector 字符串（如'app=a'），不是 JSON/YAML 对象；单引号必须保留，否则 YAML 解析失败 -
pollingInterval: 15单位是秒，但最小有效值为 5；设成 1 会被 KEDA 忽略并 fallback 到 30 - 使用
type: memory或type: cpu触发器前，确保集群已部署metrics-server；否则 KEDA 日志报failed to get metric for trigger，且kubectl describe so xxx显示FailedGetMetrics -
minReplicaCount若设为 0，需确认工作负载支持缩容到 0（如 Deployment 默认支持，Job 不支持）
KEDA 的核心复杂点不在安装步骤，而在于触发器语义与实际业务流量节奏的对齐——比如 Kafka 触发器的 lagThreshold 设太低会导致抖动扩缩，设太高又响应迟钝；这些参数没日志、没 UI、全靠反复压测和 kubectl get so -o wide 观察 TRIGGERS 和 AGE 列变化来调优。
