memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server has asked for the client to provide credentials"
This specific memcache.go:265 log line confirms that kubectl is failing at the very first step of its execution: attempting to discover the cluster’s available APIs while using cached discovery data. [1] Because it cannot authenticate to fetch the API group list, the client application falls back to a generic unhandled discovery error. [2]
1. Clear Your Local Kubectl Cache
kubectl caches cluster API schemas locally in your home directory. If your cluster context changed or certificates were swapped, this cache can become corrupted and continue attempting connections with bad metadata.
- Wipe the cache directory: Run the following command on the machine throwing the error:
rm -rf ~/.kube/cache/ ~/.kube/http-cache/
- Test any basic command like kubectl get ns immediately afterward to see if it forces a clean authentication handshake.
2. Bypass and Refresh the Kubeconfig File
If clearing the cache does not work, the underlying credentials stored in your environment are definitively invalid.
- If running on the Master/Control-Plane Node: Re-link the primary administrative configuration directly to your active profile to override broken configs:
mkdir -p $HOME/.kube
sudo cp -f /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
export KUBECONFIG=$HOME/.kube/config
- If running inside a Pod or CI/CD pipeline: This error means the ServiceAccount token mounted at /var/run/secrets/kubernetes.io/serviceaccount/token has either expired, been deleted, or lacks RBAC permissions to view the core API groups (api-groups).
3. Diagnose the Exact API Response
To see exactly what credentials your client is sending (and why the server is rejecting them), bypass the cache layer completely and increase verbosity. [3]
- Run the discovery command while completely ignoring the local cache at a high debug level:
kubectl get nodes --no-cache -v=9
- What to look for in the output: Look at the Request Headers. If you do not see an Authorization: Bearer <token> or a client certificate payload (X509), your kubeconfig file is completely empty of actual credentials. If you do see them and get a 401 Unauthorized, your cluster control plane has invalidated that specific token or certificate.
To help narrow down the fix, let me know:
- Is this error happening on your local workstation, the cluster master node, or inside a pod/CI-CD pipeline?
- If you run cat ~/.kube/config, do you see valid lines under client-certificate-data or token?
[1] https://signoz.io [2] https://forums.suse.com [3] https://support.d2iq.com