GKE集群未使用batch/v1beta1却收到已移除API调用警告的疑问

即使确认集群内没有v1beta1版本的CronJob资源，仍可能存在其他客户端在调用已移除的API，以下是具体排查和解决步骤：

1. 定位API调用来源 #

利用GCP审计日志可以精准找到发起调用的客户端：

• 在GCP控制台日志资源管理器中使用过滤条件：

  resource.type="k8s_cluster"
  protoPayload.requestUrl:"/apis/batch/v1beta1/cronjobs/"
  

  查看日志里的authenticationInfo.principal（调用身份）、sourceIp（调用IP）和完整protoPayload.userAgent，确定调用方。
• 也可以通过gcloud命令行查询：

  gcloud logging read "resource.type=k8s_cluster AND protoPayload.requestUrl:/apis/batch/v1beta1/cronjobs/" --limit=20 --format="table(protoPayload.userAgent, authenticationInfo.principal, sourceIp, timestamp)"
  

2. 排查集群内第三方工具/控制器 #

警告里的用户代理v2.2.0大概率对应集群内部署的旧版本工具：

• 搜索集群内镜像版本包含v2.2.0的Pod：

  kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name} : {.spec.containers[*].image}{"\n"}{end}' | grep v2.2.0
  

• 重点检查kube-state-metrics、Prometheus Operator、Argo CD这类工具的版本，很多旧版本会硬编码调用旧API。

3. 检查外部客户端的kubectl版本 #

集群外的旧版本kubectl也会触发这类调用：

• kubectl在v1.21之后才默认使用batch/v1的CronJob API，v1.20及更早版本执行kubectl get cronjobs会自动调用batch/v1beta1。
• 检查相关环境的kubectl版本：

  kubectl version --client
  

  版本过低的话，升级到v1.21+即可解决。

4. 警告延迟说明 #

GKE的API废弃警告基于近30天的调用统计生成，即使修复了所有调用来源，警告可能还会持续1~7天，直到统计周期更新后才会消失。

内容的提问来源于stack exchange，提问作者Arun Babu