GKE集群全命名空间大量Pod出现MountVolume.SetUp失败错误，寻求排查方案

我之前在GKE集群里碰到过一模一样的问题，当时也是全集群多命名空间的Pod都报MountVolume.SetUp failed for volume "<volume-name>-token-m4rtn" : failed to sync secret cache: timed out waiting for the condition这个错误，折腾了好一阵才找到根源，给你分享下我的排查步骤和方向：

核心方向：聚焦kubelet与控制平面的通信/同步问题 #

这个错误本质是kubelet在同步Secret缓存时超时了，而默认的ServiceAccount Token卷依赖于集群的Secret同步机制，所以优先排查kubelet和控制平面（apiserver、etcd）的交互是否正常。

1. 先查kubelet的状态与日志 #

kubelet是抛出这个错误的组件，先看节点上的kubelet是否正常工作：

• 用kubectl get nodes检查所有节点的状态，有没有NotReady或者Unhealthy的节点；
• 针对异常节点，用kubectl describe node <node-name>查看节点事件，有没有和Secret、Volume挂载相关的告警；
• 直接查看kubelet日志：kubectl logs -n kube-system kubelet-<node-name>（GKE中kubelet默认在kube-system命名空间），重点搜索secret cache、timeout、apiserver、etcd相关的关键词，看是不是有连接失败、超时的具体报错。

2. 检查控制平面组件状态 #

GKE的控制平面（apiserver、etcd等）如果出问题，会导致全集群的同步故障：

• 运行kubectl get pods -n kube-system，查看kube-apiserver-*、etcd-*这些核心组件的Pod状态，有没有重启、CrashLoopBackOff或者Pending的情况；
• 如果是GKE托管集群，还可以去GCP控制台的集群监控页面，看控制平面的CPU、内存、请求延迟指标，判断是不是apiserver负载过高或者etcd性能瓶颈。

3. 验证节点到控制平面的网络连通性 #

kubelet需要和apiserver通信才能同步Secret缓存，网络不通是常见诱因：

• 先通过kubectl cluster-info拿到apiserver的地址；
• 在任意节点上（可以通过kubectl debug node/<node-name> -it --image=busybox进入节点调试环境），用wget --spider <apiserver-url>或者telnet <apiserver-ip> 443测试连通性；
• 检查GCP VPC的防火墙规则，确保节点所在的子网允许和控制平面的IP段通信（GKE默认会创建对应的规则，但如果手动修改过可能会出问题）。

4. 排查集群资源过载情况 #

资源耗尽会导致kubelet或者控制平面无法正常处理请求：

• 查看节点资源使用：kubectl top nodes，看CPU、内存使用率是不是接近100%；
• 查看控制平面的资源（托管集群在GCP控制台查看），如果apiserver的请求队列堆积，也会导致同步超时；
• 检查是否有大量的Pod创建/删除操作，突发的资源请求可能会压垮控制平面。

5. 排查最近的集群变更 #

很多时候这类全集群问题都是变更导致的：

• 回忆下最近有没有升级GKE集群版本、修改网络配置、安装新的集群插件（比如网络插件、准入控制器、日志采集工具）；
• 如果是升级后出现的问题，可以查看GKE的版本发布说明，看有没有已知的兼容性问题；
• 检查是否有修改过kubelet的配置（比如通过kubectl get cm kubelet-config -n kube-system -o yaml查看），比如secretCacheTTL这类缓存参数被修改过，导致超时时间过短。

6. 验证ServiceAccount与Secret的基础状态 #

虽然是全集群问题，但可以随机选一个命名空间验证基础资源是否正常：

• 查看默认ServiceAccount：kubectl get sa default -n <target-namespace>；
• 找到对应的Token Secret：kubectl get secret <volume-name>-token-m4rtn，检查Secret是否存在、状态是否正常，有没有过期（Token Secret的默认有效期是1年，不过GKE现在默认用TokenRequest模式，不会生成持久Secret，但老集群可能还是用Secret模式）。

我当时的解决案例 #

我碰到的情况是集群突然有大量Pod创建请求，导致apiserver负载飙升，响应延迟超过了kubelet的Secret同步超时时间，后来通过GCP控制台调整了托管控制平面的节点规模，同时优化了Pod的创建速率，问题就解决了。

内容的提问来源于stack exchange，提问作者David Essien