# kubectl cluster-info: Usage, Options & CI Errors

> kubectl cluster-info shows control-plane endpoints and checks connectivity. Use it as a CI preflight; the dump subcommand and connection-refused error.

Source: https://latchkey.dev/learn/command-reference/kubectl-cluster-info  
Updated: 2026-06-25

Confirm kubectl can reach the cluster - and where its endpoints are.

kubectl cluster-info prints the control-plane and core service URLs and, in doing so, verifies basic connectivity. It is the lightweight preflight to run at the top of a deploy job.

## What it does

kubectl cluster-info reports the API server and add-on (DNS, etc.) endpoints. Because it makes a real API call, a clean exit proves your kubeconfig and credentials reach the cluster. cluster-info dump emits a large diagnostic bundle (nodes, pods, logs) for offline debugging.

## Common usage

```Terminal
kubectl cluster-info                                  # preflight check
kubectl cluster-info dump --output-directory=./k8s-dump
kubectl cluster-info dump -A > cluster-dump.txt
```

## Common errors in CI

A failing cluster-info at the start of a job is a gift - it surfaces a broken kubeconfig before you waste minutes. "To further debug and diagnose cluster problems, use kubectl cluster-info dump" followed by "connection refused" / "i/o timeout" means the API server is unreachable: wrong endpoint, missing VPN/network path, or an expired token. cluster-info dump is heavy. Never run it on every job, only as an on-failure artifact, or it bloats logs and slows the pipeline.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl cluster-info: Usage, Options & CI Errors?

kubectl cluster-info prints the control-plane and core service URLs and, in doing so, verifies basic connectivity. It is the lightweight preflight to run at the top of a deploy job.

### What it does?

kubectl cluster-info reports the API server and add-on (DNS, etc.) endpoints. Because it makes a real API call, a clean exit proves your kubeconfig and credentials reach the cluster. cluster-info dump emits a large diagnostic bundle (nodes, pods, logs) for offline debugging.

### Common errors in CI?

A failing cluster-info at the start of a job is a gift - it surfaces a broken kubeconfig before you waste minutes. "To further debug and diagnose cluster problems, use kubectl cluster-info dump" followed by "connection refused" / "i/o timeout" means the API server is unreachable: wrong endpoint, missing VPN/network path, or an expired

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt