2. KEDA 安装与部署
本章将带领你完成 KEDA 在生产环境中的安装与部署。KEDA 的部署方式灵活，支持 Helm Chart 和纯 YAML 两种主流方式。无论你选择哪种方式，最终都会获得一个由 KEDA Operator 和 KEDA Metrics Server 组成的运行环境。我们将逐一演示这两种方法，并验证安装状态。
2.1 安装方式概览
在开始安装前，先了解两种部署方式的适用场景：
| 部署方式 | 适用场景 | 优势 |
|---|---|---|
| Helm Chart | 生产环境、需要版本管理与回滚 | 参数化配置、依赖管理、一键升级/回滚 |
| YAML 部署 | 离线环境、测试环境、快速验证 | 无需 Helm、直接 kubectl apply、透明可控 |
推荐： 生产环境优先使用 Helm 部署，便于后续版本升级和配置变更。测试或离线环境可使用 YAML 方式。
2.2 使用 Helm 安装 KEDA
Helm 是 Kubernetes 的包管理工具。使用 Helm 安装 KEDA 前，请确保已添加 KEDA 官方 Helm 仓库。
步骤 1：添加 Helm 仓库
helm repo add kedacore https://kedacore.github.io/charts
helm repo update步骤 2：安装 KEDA
helm install keda kedacore/keda \
--namespace keda \
--create-namespace \
--version 2.14.0参数说明：
keda：Helm Release 名称。kedacore/keda：Chart 名称。--namespace keda：指定命名空间为keda。--create-namespace：如果命名空间不存在则自动创建。--version：指定 KEDA 版本，建议锁定版本避免意外升级。
步骤 3：验证 Helm 安装
helm list -n keda输出应显示 keda Release 状态为 deployed。
2.3 使用 YAML 部署 KEDA
对于无法使用 Helm 的环境，KEDA 官方提供了完整的 YAML 部署文件。你可以直接从 GitHub Release 页面下载。
步骤 1：下载部署文件
kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.14.0/keda-2.14.0.yaml
注意： 使用
--server-side 标志可以避免因资源冲突导致的 apply 失败，尤其在大型集群中推荐使用。
步骤 2：验证 YAML 部署
kubectl get all -n keda你应该看到以下核心资源：
- Deployment/keda-operator：KEDA 主控制器。
- Deployment/keda-metrics-apiserver：Metrics Server 组件。
- Service/keda-metrics-apiserver：Metrics API 服务。
2.4 验证 KEDA 安装状态
无论使用哪种方式安装，都需要验证 KEDA 的核心组件是否正常运行。以下是标准验证步骤：
检查 Pod 状态
kubectl get pods -n keda预期输出示例：
NAME READY STATUS RESTARTS AGE
keda-operator-7d8f9c6b9f-abc12 1/1 Running 0 5m
keda-metrics-apiserver-5f6b7c8d9e-xyz34 1/1 Running 0 5m检查 API 服务
kubectl get apiservice | grep keda预期输出：
v1alpha1.custom.metrics.k8s.io keda/keda-metrics-apiserver True 5m
v1alpha1.external.metrics.k8s.io keda/keda-metrics-apiserver True 5m这两个 API 服务是 KEDA 与 Kubernetes 核心交互的关键：
- custom.metrics.k8s.io：提供自定义指标。
- external.metrics.k8s.io：提供外部指标（如 Kafka、RabbitMQ 等）。
检查 CRD 是否注册
kubectl get crd | grep keda预期输出应包含 scaledobjects.keda.sh、scaledjobs.keda.sh、triggerauthentications.keda.sh 等 CRD。
2.5 KEDA Operator 与 Metrics Server 架构
KEDA 由两个核心组件构成：KEDA Operator 和 KEDA Metrics Server。理解它们的分工有助于后续排错和调优。
2.6 组件职责对比
| 组件 | 职责 | 关键资源 | 日志关键词 |
|---|---|---|---|
| KEDA Operator | 监听 CRD、管理 HPA、协调触发器 | Deployment, ScaledObject, ScaledJob | Reconciling ScaledObject, Creating HPA |
| KEDA Metrics Server | 实现 Metrics API、拉取外部指标 | Deployment, Service, APIService | Serving metrics, External metric |
排错提示： 如果 HPA 无法获取指标，首先检查
keda-metrics-apiserver Pod 日志，确认 Metrics Server 是否成功连接到事件源。如果 ScaledObject 状态异常，则检查 keda-operator Pod 日志。
2.7 验证 KEDA 功能：创建测试 ScaledObject
安装完成后，创建一个简单的 ScaledObject 来验证 KEDA 是否正常工作。以下示例使用 CPU 触发器（KEDA 内置支持）：
cat <<EOF | kubectl apply -f -
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: test-scaledobject
namespace: default
spec:
scaleTargetRef:
name: test-deployment
triggers:
- type: cpu
metadata:
type: Utilization
value: "50"
EOF验证 ScaledObject 状态：
kubectl get scaledobject test-scaledobject -o wide输出中 Ready 列应为 True，表示 KEDA 已成功接管该工作负载的弹性伸缩。