So your Kubernetes cluster’s certs just expired — and you tried to fix it using kubeadm certs renew all
…
But now, kubectl
gives you this frustrating error:
memcache.go:265] couldn't get current server API group list: the server has asked for the client to provide credentials

You’re not alone. This is a common pitfall when renewing expired certificates in kubeadm-based clusters.
🧠 Why This Error Happens
When your cluster certificates expire (usually after 1 year by default), running:
sudo kubeadm certs renew all
will regenerate the necessary cert files — but it doesn’t reload them into active components, nor does it update your local kubectl
config.
As a result, your CLI client (kubectl
) tries to authenticate using expired or mismatched credentials, and the API server rightfully refuses access.
✅ How to Fix It (The Right Way)
Here’s how you can resolve this step by step:
🔧 Step 1: Regenerate the kubeconfig file with the new certs
sudo kubeadm init phase kubeconfig admin
This regenerates the admin kubeconfig file at:
/etc/kubernetes/admin.conf
📁 Step 2: Update your local kubeconfig
If you’re running kubectl
as a non-root user (like ubuntu
, ec2-user
, or yourself), copy the new config into your home directory:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
This ensures your kubectl
client is using valid, updated credentials to talk to the API server.
✅ Step 3: Verify it works
kubectl get nodes
If your cluster is up and the new credentials are in use, you’ll see a list of healthy nodes again.
Problem solved — no more memcache.go
errors.

🔁 Bonus: What to Do Next
Consider increasing your cert duration next time:
Edit kubeadm-config.yaml
or set --certificate-renewal-duration-years
if using Kubespray or kubeadm
init scripts.
Keep a note to renew certs proactively (before expiry), or automate alerts to avoid surprises.
“Expired certs don’t warn you. They ambush you.”
— TechNoStress