kubectl gave up waiting on the API server. Two flavors: unreachable entirely (network/firewall/cert) or reachable-but-slow (overloaded control plane, huge list requests).
kubectl config view --minify shows the actual server URL; the cluster IP may be private (VPN off), the port moved (kind/minikube restart), or a corporate proxy intercepts the connection.
kubectl get all or fetching many objects with -o wide across a big cluster hits the default request timeout. The API is reachable; the request is just heavy.
kubectl config current-context && kubectl config view --minify | grep server
nc -zv -w 5 <server-host> 6443 ; curl -k --max-time 5 https://<server>:6443/version
kubectl get pods --all-namespaces --request-timeout=60s --v=8 2>&1 | tail -5
docker ps | grep -E 'kind|kindest|minikube' ; minikube status 2>/dev/null || kind get clusters 2>/dev/null
kubectl's default request timeout is none for gets (waits on the server) — the 'context deadline exceeded' you see in CI usually comes from --request-timeout set explicitly, or the client SDK's deadline. After a VPN switch, cached cluster IPs may route differently: re-run with --v=8 and read where the TCP dial actually goes.
get all issues many list requests; on a loaded control plane or huge cluster the aggregate exceeds the timeout. Scope namespaces, raise --request-timeout, or use the watch/server-side methods instead.
curl -k https://<server>:6443/version — instant answer = network fine, it's request weight. Connection timeout = network/routing/VPN. Then dig into the failing layer, not kubectl.
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.