kubectl reports connection refused when it cannot establish a connection to the Kubernetes API endpoint in its current configuration. For AI platforms, that blocks inspection of inference pods, GPU scheduling, model rollouts and agent services—but it does not prove those workloads are down.

Confirm which cluster you are targeting

kubectl config current-context
kubectl config get-contexts
kubectl config view --minify --raw
echo "$KUBECONFIG"

Do not paste --raw output into tickets; kubeconfig can contain credentials. If the message points to localhost:8080, first suspect missing or unusable configuration rather than a remote cluster failure.

Select the intended context explicitly:

kubectl config use-context EXPECTED_CONTEXT
kubectl --context EXPECTED_CONTEXT cluster-info

Separate local configuration from network reachability

Extract the configured server URL safely, then test DNS and TCP reachability from the same machine. Check whether the required VPN, bastion or private network is active.

kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}{"\n"}'

Interpret errors precisely:

• connection refused: address reachable but nothing accepts the connection, or an intermediary rejects it;
• timeout: route, firewall, VPN or control plane does not respond in time;
• certificate error: TLS identity or trust problem;
• unauthorized/forbidden: connection works; investigate authentication or RBAC instead.

Restore provider-managed configuration

For managed clusters, regenerate kubeconfig with the provider’s current command rather than copying another user’s credentials. Confirm the intended account, project, region and cluster before overwriting local configuration.

For local clusters, verify that Docker Desktop, kind or minikube is actually running and that its context still exists.

Diagnose the control-plane path

If several operators fail against the same endpoint, inspect the API server or its load balancer through the provider or control-plane access path. Check recent network, certificate and cluster lifecycle changes.

Do not disable TLS verification or expose the API server publicly as a shortcut. Restore correct trust and network access.

AI production considerations

Once API access returns, verify the workloads that motivated the check:

kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl get pods -n AI_NAMESPACE -o wide

Look for GPU-node readiness, pending inference pods, failed image pulls and recent restarts. A recovered control plane does not automatically mean model serving is healthy.

Use AI Kubernetes troubleshooting for workload diagnosis, AI Security for cluster credentials and AI Operations for monitoring and incident ownership.

Prevent recurrence

• inventory context, cluster and environment ownership;
• monitor control-plane and load-balancer reachability;
• rotate credentials through supported workflows;
• document VPN and bastion requirements;
• keep a read-only diagnostic path for incidents;
• never store shared admin kubeconfig in a repository.

The fix is complete when the intended identity reaches the intended API endpoint and can perform only its authorized operations.