The connection to the server localhost:8080 was refused

KubernetesKubernetes

Fix "connection to the server localhost:8080 was refused": check KUBECONFIG, then kubectl config get-contexts and use-context. Covers no kubeconfig and sudo.

easy fix·6 min read

By Vishvesh Patel·DevOps Engineer·Updated 21 September 2026

Run these in order. Each one tells you what its output means before you change anything.

• Check whether kubectl has any config at all

If this prints an empty config or errors, kubectl found no kubeconfig and fell back to its built-in default of localhost:8080. Nothing is listening there, hence "connection refused". This is the cause the large majority of the time.

• See which file kubectl is actually reading

An unset KUBECONFIG means ~/.kube/config, and if that file does not exist you have found it. A set KUBECONFIG pointing at a path that no longer exists produces exactly the same symptom.

• List contexts and select the one you want

If contexts exist but none is marked current, kubectl has a config and no idea which cluster to use. Selecting one fixes it immediately.

The connection to the server localhost:8080 was refused almost never means a server is down. It means kubectl could not find a kubeconfig, so it fell back to its compiled-in default of localhost:8080 and nothing is listening there.

The port is the tell. You never configured 8080, and no modern cluster serves on it. Kubernetes API servers listen on 6443. Seeing localhost:8080 in the error is kubectl telling you it is guessing.

If you get this, the diagnosis is done:

or an empty config:

Then check where kubectl was looking:

Three outcomes, each with a different fix:

Get one from wherever the cluster lives. The command differs per provider, and each of these writes or merges into ~/.kube/config for you:

This one is nastier because there is no warning. kubectl does not tell you the file is missing, it just behaves as though you have no config.

A stale export in ~/.zshrc or ~/.bashrc is the usual source, often left behind after a cluster was deleted. Either fix the path or unset it:

KUBECONFIG also accepts several paths separated by :, merged left to right:

That is useful, but if any one path is wrong you get partial config and confusing results rather than an error.

No asterisk in CURRENT means nothing is selected. Pick one:

Running sudo kubectl get pods reads root's home directory, not yours, so it looks for /root/.kube/config and finds nothing. This is a very common cause on a machine where the rest of the container tooling needs sudo.

kubectl does not need root. Drop the sudo.

These three messages look different and have genuinely different causes. It is worth knowing which one you have:

The connection to the server localhost:8080 was refused. No config found. Everything above.

You must be logged in to the server (Unauthorized). Config found, cluster reached, credentials rejected. Usually an expired token or an exec credential plugin that cannot run. Check the users section of your config:

If that names aws or gke-gcloud-auth-plugin, the binary must be on your PATH. For EKS specifically, an expired session shows up here and aws sso login or refreshing credentials fixes it.

Unable to connect to the server: dial tcp ...: i/o timeout. Config found, correct address, nothing answered. The API server is genuinely unreachable: a private endpoint that needs a VPN, a security group that does not allow your IP, or a cluster that is actually down. Confirm the address first:

Then test reachability independently of kubectl:

A timeout there is a network problem, not a kubectl problem.

A pipeline hitting localhost:8080 means the kubeconfig was never written into the job. Runners start clean, so a config on your laptop is irrelevant.

If you inject the config as a base64 secret instead, write it before the first kubectl call and keep the permissions tight:

chmod 600 matters because some credential plugins refuse a world-readable kubeconfig.

Why does kubectl try to connect to localhost:8080?

Because that is its compiled-in default when it finds no kubeconfig. kubectl looks at the KUBECONFIG environment variable first, then ~/.kube/config. If neither yields a usable file it assumes an unsecured API server on the local machine at port 8080, which was how very old clusters worked. Nothing listens there on a modern setup, so the connection is refused. Seeing port 8080 in the message is therefore a reliable signal that the problem is missing configuration rather than a broken cluster.

How do I tell kubectl which kubeconfig to use?

Set the KUBECONFIG environment variable to the file path, or pass --kubeconfig /path/to/config on a single command. KUBECONFIG also accepts several paths separated by colons, merged left to right, which is how people keep one file per cluster. Be careful with that: if one path in the list does not exist, kubectl merges what it can and gives no warning, so you get a partial config and confusing results rather than a clear error.

Why does kubectl work for me but not with sudo?

Because sudo runs as root and root has a different home directory. Your config is at ~/.kube/config, which resolves to /root/.kube/config under sudo, and that file usually does not exist. kubectl does not need root privileges to talk to an API server, so the fix is simply to drop the sudo. If you genuinely need it, pass the path explicitly with sudo kubectl --kubeconfig ~/.kube/config, remembering that ~ will still expand to root's home unless you write the path out in full.

What is the difference between connection refused and i/o timeout?

Refused means something actively rejected the connection, which on localhost:8080 means nothing is listening. Timeout means the packets went out and nothing came back, so the address is plausible but unreachable: a private API endpoint needing a VPN, a security group that does not allow your IP, or a cluster that is down. Check the address kubectl is using with kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}', then test it with curl to separate a network problem from a kubectl problem.

Why does my kubeconfig work locally but fail in CI?

CI runners start from a clean image with no kubeconfig, so anything on your laptop is irrelevant. The job has to obtain credentials itself, either by calling the provider (aws eks update-kubeconfig, gcloud container clusters get-credentials) or by writing a config from a stored secret before the first kubectl command. If you write one from a secret, chmod 600 it: some credential plugins refuse to use a kubeconfig that is readable by other users.

Free, comprehensive DevOps tutorials and learning roadmaps. Master Docker, Kubernetes, CI/CD, and more.

Get notified about new tutorials and features.

• Roadmaps

• Interview Prep

• Certifications

• Company

© 2026 DevOpsLesson. All rights reserved.