2. KEDA 安装与部署：使用 Helm 安装 KEDA、使用 YAML 部署 KEDA、验证 KEDA 组件状态、KEDA Operator 与 Metrics Server

KEDA 的部署方式灵活，生产环境推荐使用 Helm 进行声明式管理，开发测试环境可选择 YAML 快速部署。本章将详细拆解两种部署路径，并深入分析 KEDA 核心组件——Operator 与 Metrics Server 的职责与交互流程。

2.1 部署方式对比

特性 Helm 部署 YAML 部署
版本管理 支持版本回滚与升级 需手动管理资源清单
参数定制 通过 values.yaml 灵活配置 需直接修改 YAML 文件
依赖管理 自动处理 CRD 与 RBAC 需按顺序手动 apply
适用场景 生产环境、CI/CD 集成 快速验证、离线环境

2.2 使用 Helm 安装 KEDA

Helm 是 Kubernetes 的包管理工具，KEDA 官方 Helm Chart 托管在 kedacore 仓库中。安装前确保集群已安装 Helm v3+。

步骤一：添加 KEDA 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.14.0 \
  --set metricsServer.useHostNetwork=true
参数说明：metricsServer.useHostNetwork=true 适用于需要 Metrics Server 直接暴露主机端口的场景（如自建集群）；托管集群（AKS/EKS/GKE）通常无需此参数。

步骤三：验证 Helm Release 状态

helm list -n keda
# 输出示例：
# NAME  NAMESPACE  REVISION  UPDATED                  STATUS    CHART        APP VERSION
# keda  keda       1         2025-03-20 10:30:00      deployed  keda-2.14.0  2.14.0

2.3 使用 YAML 部署 KEDA

对于无法访问 Helm 仓库或需要离线部署的场景，可以直接使用 KEDA 官方提供的 keda-2.14.0.yaml 统一资源清单。

步骤一：下载或获取 YAML 清单

# 在线获取
kubectl apply --server-side -f https://github.com/kedacore/keda/releases/download/v2.14.0/keda-2.14.0.yaml

# 或先下载到本地再 apply
wget https://github.com/kedacore/keda/releases/download/v2.14.0/keda-2.14.0.yaml
kubectl apply --server-side -f keda-2.14.0.yaml
注意：YAML 部署方式会一次性创建所有 CRD、RBAC、Deployment、Service 等资源。如果集群已有旧版本 KEDA，建议先卸载旧版本再 apply，避免 CRD 冲突。

步骤二：确认资源创建

kubectl get all -n keda
# 预期输出包含：
# pod/keda-operator-xxx
# pod/keda-metrics-apiserver-xxx
# service/keda-metrics-apiserver
# deployment.apps/keda-operator
# deployment.apps/keda-metrics-apiserver

2.4 验证 KEDA 组件状态

部署完成后，需要从 Pod 状态、CRD 注册、Metrics API 三个维度验证 KEDA 是否正常工作。

2.4.1 Pod 与 Deployment 状态

kubectl get pods -n keda -o wide
# 期望所有 Pod 处于 Running 状态，READY 列为 1/1

2.4.2 CRD 注册验证

kubectl get crd | grep keda
# 应包含：
# clustertriggerauthentications.keda.sh
# scaledjobs.keda.sh
# scaledobjects.keda.sh
# triggerauthentications.keda.sh

2.4.3 Metrics API 可用性

kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" | jq .
# 返回 JSON 中应包含 "resources": []，表示 API 端点已注册
快速健康检查命令： 
kubectl -n keda rollout status deployment/keda-operator
kubectl -n keda rollout status deployment/keda-metrics-apiserver

2.5 KEDA Operator 与 Metrics Server 架构解析

KEDA 由两个核心组件构成：Operator 和 Metrics Server。理解两者的分工是后续配置事件源与水位校准的基础。

KEDA 核心组件架构图 外部事件源 Kafka / RabbitMQ / AWS SQS ScaledObject CRD 实例 KEDA Operator 监听 ScaledObject / 驱动 HPA Kubernetes HPA 自动扩缩 Deployment KEDA Metrics Server 暴露 external.metrics.k8s.io 组件交互说明 Operator 监听 ScaledObject 变化 → 创建/更新 HPA → Metrics Server 提供外部指标 → HPA 根据指标扩缩 Deployment

2.5.1 KEDA Operator

  • 职责：监听 ScaledObject 和 ScaledJob 资源的变化，根据事件源水位动态创建或更新 Kubernetes HPA。
  • 核心逻辑：从事件源（如 Kafka Lag、RabbitMQ 队列深度）获取指标值，计算期望副本数，并驱动 HPA 调整 Deployment 的副本数。
  • 高可用：Operator 默认以 Deployment 形式运行，支持多副本部署，通过 leader election 保证只有一个活跃实例。

2.5.2 KEDA Metrics Server

  • 职责：实现 Kubernetes external.metrics.k8s.io API，将事件源指标转换为 HPA 可消费的指标格式。
  • 工作方式：Metrics Server 启动时注册 API 服务，HPA 通过该 API 查询指标值，无需修改 Kubernetes 核心组件。
  • 性能：支持指标缓存与并发查询，避免每次 HPA 轮询都直接访问事件源。
关键区别：Operator 负责“控制逻辑”（监听 CRD、驱动 HPA），Metrics Server 负责“数据平面”（暴露指标 API）。两者缺一不可，共同构成 KEDA 的完整闭环。

2.6 部署后验证清单

检查项 命令 预期结果
Pod 状态 kubectl get pods -n keda 所有 Pod 为 Running
CRD 注册 kubectl get crd | grep keda 4 个 CRD 存在
Metrics API kubectl get --raw "/apis/external.metrics.k8s.io/v1beta1" 返回 200 OK
Operator 日志 kubectl logs -n keda deployment/keda-operator 无 ERROR 级别日志
Metrics Server 日志 kubectl logs -n keda deployment/keda-metrics-apiserver 无连接拒绝错误

完成上述验证后，KEDA 已成功接入集群。下一阶段将进入事件源配置与队列水位校准的核心内容。

← 上一章 📖 返回目录 下一章 →