2. KEDA 安装与部署：使用 Helm 安装 KEDA、KEDA Operator 配置、KEDA Metrics Server 配置、验证安装
本章是 KEDA 实战的起点。你将通过 Helm 完成 KEDA 的完整部署，理解 Operator 与 Metrics Server 的职责分工，并掌握安装验证的标准方法。正确的安装是后续事件源配置与容量规划的基础。
2.1 安装前准备：环境与工具检查
在安装 KEDA 之前，请确认以下前提条件已满足：
| 组件 | 最低版本 | 说明 |
|---|---|---|
| Kubernetes 集群 | v1.24+ | 支持 Kubernetes 原生 HPA v2，建议使用生产级集群 |
| Helm | v3.9+ | 用于安装和管理 KEDA Helm Chart |
| kubectl | v1.24+ | 与集群版本匹配，用于验证部署状态 |
| 集群管理员权限 | — | KEDA 需要创建 ClusterRole、ClusterRoleBinding 等集群级资源 |
推荐实践：建议在测试集群中先完成安装验证，再推广到生产环境。KEDA 本身为轻量级组件，资源开销极低（Operator 约 50m CPU / 100Mi 内存），不会对集群造成显著负担。
2.2 使用 Helm 安装 KEDA
KEDA 官方维护的 Helm Chart 托管在 kedacore 仓库。安装过程分为三步：添加仓库、更新索引、部署 Chart。
2.2.1 添加 Helm 仓库
helm repo add kedacore https://kedacore.github.io/charts
helm repo update2.2.2 安装 KEDA 到 keda 命名空间
helm install keda kedacore/keda \
--namespace keda \
--create-namespace \
--version 2.14.0参数说明：
--namespace keda：将 KEDA 组件部署到独立的keda命名空间，便于管理。--create-namespace：如果命名空间不存在则自动创建。--version：指定 Chart 版本，建议锁定版本避免意外升级。
2.2.3 自定义安装（生产推荐）
通过 values.yaml 文件覆盖默认配置，实现更精细的控制：
helm install keda kedacore/keda \
--namespace keda \
--create-namespace \
--values custom-values.yaml以下是一个典型的 custom-values.yaml 示例：
# custom-values.yaml
operator:
replicaCount: 2
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 256Mi
metricsServer:
replicaCount: 2
resources:
requests:
cpu: 50m
memory: 64Mi
limits:
cpu: 200m
memory: 128Mi
serviceAccount:
create: true
name: keda-operator
注意：生产环境中建议将
operator.replicaCount 和 metricsServer.replicaCount 设置为至少 2，以保证高可用。KEDA Operator 负责事件源监听与 ScaledObject 协调，Metrics Server 负责向 Kubernetes HPA 提供指标，两者均为关键路径组件。
2.3 KEDA 组件架构与职责
KEDA 安装后会在集群中部署两个核心组件：KEDA Operator 和 KEDA Metrics Server。理解它们的职责有助于后续排错与容量规划。
组件职责对比：
| 组件 | 职责 | 关键资源 | 故障影响 |
|---|---|---|---|
| KEDA Operator | 监听 ScaledObject / ScaledJob 资源，连接事件源获取指标，驱动 Metrics Server 更新 | Deployment、ClusterRole、ClusterRoleBinding | 事件源无法触发扩缩，已有 HPA 继续工作 |
| KEDA Metrics Server | 实现 external.metrics.k8s.io API，向 Kubernetes HPA 提供实时指标 |
Deployment、Service、APIService | HPA 无法获取指标，扩缩暂停 |
2.4 验证安装
安装完成后，通过以下步骤验证 KEDA 是否正常工作。
2.4.1 检查 Pod 状态
kubectl get pods -n keda预期输出应包含两个 Running 状态的 Pod：
NAME READY STATUS RESTARTS AGE
keda-operator-7d8f9c6b9f-abc12 1/1 Running 0 2m
keda-operator-metrics-apiserver-6b9f7c8d9d-xyz34 1/1 Running 0 2m2.4.2 检查 API Service 注册
kubectl get apiservice | grep keda应看到 v1beta1.external.metrics.k8s.io 状态为 True：
v1beta1.external.metrics.k8s.io keda/keda-operator-metrics-apiserver True2.4.3 验证指标端点可访问
kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq .正常返回应包含 kind: APIResourceList 和 resources: []（初始状态无指标）。
2.4.4 部署一个测试 ScaledObject
创建一个简单的 ScaledObject 验证端到端流程：
cat <<EOF | kubectl apply -f -
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: test-scaledobject
namespace: default
spec:
scaleTargetRef:
name: test-deployment
triggers:
- type: cron
metadata:
timezone: Asia/Shanghai
start: 0 * * * *
end: 59 * * * *
desiredReplicas: "3"
EOF验证 ScaledObject 状态：
kubectl get scaledobject test-scaledobject -n default输出中 READY 列应为 True，ACTIVE 列根据 cron 表达式显示当前是否激活。
验证清单：
- ✅ KEDA Operator Pod 处于 Running 状态
- ✅ KEDA Metrics Server Pod 处于 Running 状态
- ✅
external.metrics.k8s.ioAPIService 状态为 True - ✅ 测试 ScaledObject 的 READY 状态为 True
2.5 常见安装问题与排错
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| Pod 一直处于 Pending 状态 | 集群资源不足，或节点污点未容忍 | 检查节点资源，添加 tolerations 到 values.yaml |
| Metrics Server Pod CrashLoopBackOff | 证书问题或 API 服务冲突 | 检查日志：kubectl logs -n keda <pod-name>，确认 --secure-port 未被占用 |
| APIService 状态为 False | Metrics Server 未就绪或网络不通 | 检查 Service 和 Endpoint：kubectl get svc -n keda |
| ScaledObject 状态为 Unknown | Operator 无法连接事件源 | 检查事件源配置和网络策略 |
2.6 卸载 KEDA
如需卸载 KEDA，执行以下命令：
helm uninstall keda -n keda
kubectl delete namespace keda
注意：卸载 KEDA 前，请确保所有 ScaledObject 和 ScaledJob 资源已被删除，否则目标 Deployment 将失去自动扩缩能力，但不会影响已有副本数。KEDA 本身不修改 Deployment 的副本数，副本数由 HPA 控制。
2.7 本章小结
通过本章学习，你已完成 KEDA 的安装与部署，并掌握了以下关键能力：
- 使用 Helm 安装 KEDA 并自定义配置
- 理解 Operator 与 Metrics Server 的职责分工
- 通过 Pod 状态、APIService、ScaledObject 三步验证安装正确性
- 掌握常见安装问题的排错方法