KEDA在GKE集群中APIService不可用问题的分析与解决

问题背景

Kubernetes Event-driven Autoscaling (KEDA) 是一个基于事件的Kubernetes自动伸缩组件，它通过将事件源系统（如Prometheus、Kafka等）与Kubernetes的Horizontal Pod Autoscaler (HPA)集成，为应用提供精细化的自动伸缩能力。

在Google Kubernetes Engine (GKE) 环境中部署KEDA 2.16.1版本时，用户遇到了一个典型问题：v1beta1.external.metrics.k8s.io APIService处于FailedDiscoveryCheck状态，导致自动伸缩功能无法正常工作。

问题现象

当用户创建ScaledObject CRD后，关联的HPA会报告如下错误：

unable to get external metric stage/s0-prometheus/&LabelSelector{MatchLabels:map[string]string{scaledobject.keda.sh/name: communications-service,},MatchExpressions:[]LabelSelectorRequirement{},}: unable to fetch metrics from external metrics API: the server is currently unable to handle the request (get s0-prometheus.external.metrics.k8s.io)

检查APIService状态显示：

kubectl get apiservices v1beta1.external.metrics.k8s.io
NAME                              SERVICE                                AVAILABLE                      AGE
v1beta1.external.metrics.k8s.io   keda/keda-operator-metrics-apiserver   False (FailedDiscoveryCheck)   2m58s

根本原因分析

KEDA的核心组件包括Operator和Metrics Adapter两部分。Metrics Adapter作为一个独立的API服务器运行，负责提供外部指标数据。在GKE环境中，这个问题通常与网络配置有关：

1. 控制平面访问限制：GKE集群的控制平面需要能够访问Metrics Adapter服务（默认端口6443），但默认网络策略可能阻止了这种访问。

2. 服务账户权限：KEDA Metrics Adapter需要适当的服务账户权限才能与集群API服务器通信。

3. 证书配置：KEDA使用自签名证书进行内部通信，如果证书配置不当会导致握手失败。

解决方案

针对GKE环境的特定解决方案如下：

1. 调整网络策略：

   • 允许GKE控制平面的IP范围访问集群内KEDA Metrics Adapter服务的6443端口
   • 确保KEDA命名空间（默认为keda）的网络策略允许入站连接

2. 验证服务账户配置：

   • 检查keda-operator服务账户是否具有必要的RBAC权限
   • 确认ClusterRoleBinding正确关联了服务账户

3. 证书验证：

   • 检查KEDA生成的证书是否有效
   • 确保证书包含正确的SANs（Subject Alternative Names）以匹配服务DNS名称

实施步骤

1. 确定GKE控制平面的IP范围
2. 创建或修改网络策略，允许控制平面IP访问keda命名空间
3. 验证KEDA部署配置：

   # 检查values.yaml中的关键配置
   metricsServer:
     enabled: true
     useCertManager: false  # 在GKE中通常使用自签名证书
   

4. 重启KEDA组件使配置生效

验证方法

问题解决后，可以通过以下方式验证：

1. 检查APIService状态：

   kubectl get apiservices v1beta1.external.metrics.k8s.io
   

   应显示为"True"

2. 查询外部指标：

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

   应返回指标列表而非错误

3. 观察HPA事件：

   kubectl describe hpa <your-hpa-name>
   

   不应再出现"FailedGetExternalMetric"警告

最佳实践建议

1. 网络隔离策略：在严格的安全策略环境中，建议为KEDA组件创建专用的网络策略，而不是完全开放端口。

2. 版本兼容性：确保KEDA版本与Kubernetes版本兼容，特别是GKE的特殊发行版。

3. 监控配置：为KEDA组件设置监控，及时发现APIService不可用等问题。

4. 证书管理：对于生产环境，考虑使用cert-manager管理KEDA证书而非依赖自签名证书。

总结

KEDA在GKE环境中APIService不可用的问题通常源于网络访问限制。通过合理配置网络策略和服务账户权限，可以确保KEDA Metrics Adapter能够正常提供服务。这个问题也提醒我们，在云托管Kubernetes环境中部署组件时，需要特别注意控制平面与工作负载之间的网络通信需求。