The API server rejected your credential — expired token, stale kubeconfig, or a certificate issue. The error text tells you which of the three.
OIDC/kubelogin tokens, cloud CLI credentials, or CI tokens refreshed by a step you skipped. `kubectl auth can-i` fails identically.
Admin rotated API server certs or changed auth modes; your stored client cert/token is now invalid.
You're authenticated fine — against a different cluster than you meant. kubectl current-context before anything else.
kubectl config current-context && kubectl config view --minify
# EKS: aws eks update-kubeconfig --name <cluster> ; GKE: gcloud container clusters get-credentials ...
kubelogin get-token --oidc... # or kubectl oidc-login per your setup
kubectl auth whoami 2>/dev/null || kubectl auth can-i --list
Almost every 401 is 'it's you, not the cluster': unless multiple people report it simultaneously, assume your credential, refresh it, and only then look at the API server.
Expired credentials: short-lived tokens (OIDC refresh failed), an expired client cert, or a token revoked server-side. The kubeconfig's user stanza names the auth method — expired is the default suspicion for previously-working setups.
Depends on the provider: cloud CLIs regenerate kubeconfig (gcloud container clusters get-credentials, aws eks update-kubeconfig), OIDC setups re-run the kubelogin/kubectx oidc-login flow. Long-lived: regenerate the token in the dashboard and update kubeconfig.
Kustomize base with probes, PDBs, and zero-downtime rollouts already wired.
Kubernetes Production Blueprints — $27 →One-time. Yours to modify. Instant download from the NinjaOps template store.