废弃API调用阻碍GKE 1.22升级：kube-metrics-adapter问题求助

一、精准定位废弃API调用来源 #

• 利用GKE审计日志：通过GCP日志查询过滤目标API请求，直接获取调用方信息。示例查询语句：

  resource.type="k8s_cluster"
  protoPayload.requestURI:"/apis/authorization.k8s.io/v1beta1/subjectaccessreviews"
  

  从结果中提取protoPayload.userAgent、protoPayload.authenticationInfo.principal字段，明确调用组件的身份和版本。
• 集群内流量分析：若无法使用GCP日志，可在控制平面节点（需管理员权限）抓取kube-apiserver的流量，通过工具过滤authorization.k8s.io/v1beta1相关请求，识别调用方的Pod IP或ServiceAccount。

二、深入分析调用方的问题根源 #

• 检查组件代码与依赖：对于已定位的组件（如kube-metrics-adapter），排查是否存在硬编码的v1beta1 API调用，或使用的client-go版本过低（低于v0.20.x的版本默认使用v1beta1的SubjectAccessReviews）。
• 验证配置有效性：确认已修改的RBAC、APIService配置是否完全生效——比如检查组件的ServiceAccount是否绑定了v1版本SubjectAccessReviews的权限，而非仅修改配置文件但未重新部署。

三、验证修复效果的可靠方法 #

• 监控API调用指标：通过Prometheus采集kube-apiserver的apiserver_request_total指标，添加过滤条件resource="subjectaccessreviews",version="v1beta1"，实时追踪调用量变化，确认修复后调用是否停止。
• 灰度验证：部署修复后的组件实例，逐步替换旧版本，观察废弃API调用是否下降，同时确保组件核心功能正常（如HPA适配逻辑）。

四、通用解决策略 #

• 优先升级组件版本：查找组件的官方稳定版本，通常新版本会适配Kubernetes API版本变更，比如istio-hpa项目的kube-metrics-adapter，可查看其Release Notes确认是否修复了废弃API调用问题。
• 自定义修复组件：若官方版本未修复，可fork组件代码，将authorization.k8s.io/v1beta1/subjectaccessreviews替换为v1版本的API路径，更新client-go依赖后重新构建镜像部署。
• 应急过渡方案：若无法立即升级，可临时限制组件调用v1beta1 API的权限（注意：此操作可能导致组件功能异常，仅作为短期过渡）。

内容的提问来源于stack exchange，提问作者Ye Lin Aung