3. KEDA 安装与配置：使用 Helm 安装 KEDA、命名空间与 RBAC 配置、验证安装状态

在生产级 Kubernetes 集群中部署 KEDA，推荐使用 Helm 作为包管理工具。Helm 能够将 KEDA 的所有组件（Operator、Metrics Server、Admission Webhooks）打包为一个可重复部署的 Chart，并自动处理命名空间、RBAC、ServiceAccount 等资源。本章将按照“前置检查 → 添加仓库 → 安装配置 → 验证状态”的标准化流程，完成 KEDA 的生产级部署。

3.1 前置检查与环境准备

在安装 KEDA 之前，需要确认集群满足以下条件：

3.2 使用 Helm 安装 KEDA

KEDA 官方维护的 Helm Chart 位于 kedacore 仓库。安装过程分为三步：添加仓库、更新索引、自定义配置安装。

3.2.1 添加 Helm 仓库

helm repo add kedacore https://kedacore.github.io/charts
helm repo update

3.2.2 安装 KEDA（生产推荐配置）

以下命令将 KEDA 安装到独立的 keda 命名空间，并启用高可用副本与资源限制：

helm install keda kedacore/keda \
  --namespace keda \
  --create-namespace \
  --set podIdentity.azureWorkload.enabled=false \
  --set podIdentity.aws.enabled=false \
  --set podIdentity.gcp.enabled=false \
  --set operator.replicaCount=2 \
  --set metricsServer.replicaCount=2 \
  --set webhooks.replicaCount=2 \
  --set operator.resources.requests.cpu=100m \
  --set operator.resources.requests.memory=128Mi \
  --set operator.resources.limits.cpu=500m \
  --set operator.resources.limits.memory=256Mi \
  --set metricsServer.resources.requests.cpu=50m \
  --set metricsServer.resources.requests.memory=64Mi \
  --set global.rbac.create=true

3.3 命名空间与 RBAC 配置解析

KEDA 安装完成后，会在 keda 命名空间下创建以下核心资源：

KEDA 的 RBAC 设计遵循最小权限原则：Operator 仅拥有操作 Deployment、HPA、ScaledObject 等必要资源的权限，不会获得集群管理员权限。如果需要在多租户场景下限制 KEDA 的作用范围，可以通过 --set global.rbac.create=false 关闭自动 RBAC 创建，然后手动绑定到特定命名空间的 ServiceAccount。

3.4 验证安装状态

安装完成后，执行以下命令验证 KEDA 各组件是否正常运行：

3.4.1 检查 Pod 状态

kubectl get pods -n keda

# 期望输出（所有 Pod 均为 Running 状态）
NAME                                           READY   STATUS    RESTARTS   AGE
keda-operator-7d8f9c6b8f-2jklp                 1/1     Running   0          2m
keda-operator-7d8f9c6b8f-x3mno                 1/1     Running   0          2m
keda-metrics-apiserver-5c4b7d6c9f-abcde        1/1     Running   0          2m
keda-metrics-apiserver-5c4b7d6c9f-fghij        1/1     Running   0          2m
keda-admission-webhooks-6b8c7d9e4f-klmno       1/1     Running   0          2m
keda-admission-webhooks-6b8c7d9e4f-pqrst       1/1     Running   0          2m

3.4.2 验证 CRD 是否注册

kubectl get crd | grep keda

# 期望输出
clustertriggerauthentications.keda.sh       2025-01-15T10:00:00Z
scaledjobs.keda.sh                          2025-01-15T10:00:00Z
scaledobjects.keda.sh                       2025-01-15T10:00:00Z
triggerauthentications.keda.sh              2025-01-15T10:00:00Z

3.4.3 验证 Metrics API 是否可用

kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq .

# 期望输出（返回资源列表，即使为空也表示 API 注册成功）
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "external.metrics.k8s.io/v1beta1",
  "resources": []
}

3.5 KEDA 组件架构与数据流

下图展示了 KEDA 安装完成后各组件之间的协作关系，以及事件驱动伸缩的完整数据流：

3.6 生产级配置清单

以下清单总结了生产环境安装 KEDA 时的关键配置项，建议在部署前逐项确认：