Cannot reach the cluster API

Use this page when kubectl cannot connect to your cluster’s API server, or when 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. If the cluster is suspended (status disabled), resume it from the console. A suspended cluster does not accept API requests. If resuming fails with an error such as Could not reach the server. Please try again, retry once. If it fails again, contact support.

2. Check the status page. Cloudfleet announces platform maintenance and incidents 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, not a cluster issue. Make sure you use the latest Cloudfleet CLI version. In headless environments, use token-based authentication.

   If browser authentication windows keep opening on their own, a background tool queries the cluster and starts the login flow each time. Common causes are IDE Kubernetes plugins, dashboards like Lens, or a reconnecting tunnel. 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 can be briefly unavailable or relocated. You then see:

• 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 restart when connectivity returns

These interruptions self-heal, typically within minutes. Note two 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 behavior on the Basic tier.

If your workloads cannot tolerate control plane interruptions, use a Pro cluster. A Pro cluster replicates its control plane 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 slowly, or you see HTTP 429 responses and lease renewal timeouts, the control plane is likely overloaded by cluster workloads, not 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