3. KEDA 安装与配置：使用 Helm 在 Kubernetes 集群中安装 KEDA，配置 RBAC 与 TLS

KEDA（Kubernetes Event-Driven Autoscaling）作为事件驱动伸缩的核心组件，其安装与配置的规范性直接影响生产集群的稳定性与安全性。本章将围绕 Helm 安装、RBAC 权限隔离、TLS 通信加密三个关键环节展开，确保 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 创建命名空间与自定义 values 文件

建议将 KEDA 部署在独立命名空间 keda 中，并通过 values.yaml 文件管理配置：

kubectl create namespace keda

cat << 'EOF' > keda-values.yaml
# keda-values.yaml
namespace: keda

# 控制面资源限制
operator:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi

metricsServer:
  resources:
    requests:
      cpu: 100m
      memory: 128Mi
    limits:
      cpu: 500m
      memory: 512Mi

# 启用 RBAC 精细控制
rbac:
  create: true
  clusterRole: true

# 启用 TLS（证书需提前准备）
certificates:
  autoGenerated: true
EOF

3.2.3 执行安装

helm install keda kedacore/keda \
  --namespace keda \
  --version 2.14.0 \
  --values keda-values.yaml \
  --wait

3.3 RBAC 配置：最小权限原则

KEDA 需要跨命名空间读取 ScaledObject、ScaledJob 等 CRD 资源，并操作 HPA 对象。RBAC 配置需遵循最小权限原则，避免过度授权。

3.3.1 KEDA 自身 ServiceAccount 权限

安装时默认创建 keda-operator ServiceAccount，并绑定以下 ClusterRole：

3.3.2 用户/应用访问 KEDA CRD 的 RBAC

若需要让普通用户或 CI/CD 系统创建 ScaledObject，需单独绑定 Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: keda-scaledobject-creator
rules:
- apiGroups: ["keda.sh"]
  resources: ["scaledobjects", "scaledjobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: keda-scaledobject-creator-binding
subjects:
- kind: User
  name: "ci-bot@example.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: keda-scaledobject-creator
  apiGroup: rbac.authorization.k8s.io

3.4 TLS 通信加密配置

KEDA 的 Metrics API Server 与 Kubernetes API Server 之间的通信、以及 Admission Webhook 的调用均需 TLS 加密。生产集群必须启用 TLS，防止中间人攻击。

3.4.1 自动生成证书（测试环境）

在 values.yaml 中设置 certificates.autoGenerated: true，KEDA 安装时会自动生成自签名证书。此方式仅适用于开发/测试环境。

3.4.2 使用自定义证书（生产环境）

生产环境建议使用企业 CA 签发的证书或 cert-manager 管理证书生命周期。步骤如下：

1. 准备证书与密钥：将 tls.crt 和 tls.key 存入 Kubernetes Secret。
2. 创建 Secret：

kubectl create secret tls keda-tls \
  --cert=tls.crt \
  --key=tls.key \
  --namespace keda

3. 修改 values.yaml：

certificates:
  autoGenerated: false
  secretName: keda-tls

4. 升级 Helm Release：

helm upgrade keda kedacore/keda \
  --namespace keda \
  --values keda-values.yaml

3.4.3 验证 TLS 配置

通过 curl 测试 Metrics API Server 的 TLS 端点：

kubectl run curl-test --image=curlimages/curl --rm -it --restart=Never -- \
  curl -k https://keda-metrics-apiserver.keda.svc.cluster.local:443/health

返回 {"health":"ok"} 表示 TLS 通信正常。

3.5 KEDA 组件架构与通信关系

下图展示了 KEDA 安装后的核心组件及其交互流程：

3.6 安装后验证清单

完成安装与配置后，执行以下验证步骤确保 KEDA 正常运行：

1. Pod 状态检查：kubectl get pods -n keda 所有 Pod 均为 Running。
2. CRD 注册检查：kubectl get crd | grep keda.sh 应列出 scaledobjects、scaledjobs、triggerauthentications 等 CRD。
3. Metrics API 可用性：kubectl get --raw /apis/external.metrics.k8s.io/v1beta1 返回正常 JSON。
4. Webhook 连通性：创建测试 ScaledObject 时无证书错误。
5. RBAC 权限验证：使用非管理员账号尝试创建 ScaledObject，确认权限控制生效。