Cannot reach the cluster API

This page covers the situations where kubectl cannot connect to your cluster’s API server or the Cloudfleet Console reports the cluster as unavailable.

First checks

1. Check the cluster state in the console. Open the Cloudfleet Console and look at the cluster’s card. A cluster that is suspended (status disabled) must be resumed from the console before it accepts any API requests. If resuming fails with an error such as “Could not reach the server. Please try again”, retry once and then contact support.

2. Check the status page. Platform maintenance and incidents are announced at status.cloudfleet.ai.

3. Verify your kubeconfig and authentication. Refresh the cluster context and confirm who the cluster sees:

   bash Copy

   cloudfleet clusters kubeconfig CLUSTER_ID
   kubectl auth whoami

   Authentication errors are usually a CLI or profile issue rather than a cluster issue. Make sure you are on the latest Cloudfleet CLI version. In headless environments, use token-based authentication.

   If browser authentication windows keep opening on their own, a background tool is querying the cluster and triggering the login flow each time: IDE Kubernetes plugins, dashboards like Lens, or a reconnecting tunnel are common culprits. Stop the tool, or temporarily move ~/.kube/config aside to find it.

Brief interruptions on Basic clusters

Basic clusters run their control plane as a single instance on shared infrastructure with a best-effort SLA. During hardware maintenance or a hardware failure, the control plane may be briefly unavailable or relocated, which shows up as:

• kubectl timeouts or connection reset by peer for one to a few minutes
• in-cluster errors such as Get "https://10.96.0.1:443/api": dial tcp 10.96.0.1:443: connect: no route to host
• controllers that use leader election restarting once connectivity returns

These interruptions self-heal, typically within minutes. Two important points:

• Your workloads keep running. A control plane interruption does not stop pods that are already running. Applications with sensible replica counts and health checks are not affected beyond the reconnect.
• Because Basic control planes share infrastructure, multiple Basic clusters can be affected at the same time. This is expected on the Basic tier.

If your workloads cannot tolerate control plane interruptions, use a Pro cluster: its control plane is replicated across multiple availability zones on dedicated resources with a 99.95% uptime SLA. See Cluster types.

API server pressure looks like an outage

If the API server responds but slowly, or you see HTTP 429 responses and lease renewal timeouts, the control plane is likely overloaded by cluster workloads rather than down. See Control plane pressure and API throttling.

When to contact support

Open a support ticket with your cluster ID if:

• the cluster is unreachable for more than a few minutes and the status page shows no incident
• resuming a suspended cluster fails repeatedly
• Deployments stop progressing cluster-wide (kubectl rollout status waits on “deployment spec update to be observed” and no new ReplicaSets appear); this indicates a control plane component issue only Cloudfleet can fix
• the Kubernetes Service IP 10.96.0.1 has no endpoints while the external API endpoint works