Couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp 127.0.0.1:8080: connect: connection refused

Asking for help? Comment out what you need so we can get more information to help you!

Cluster information: 1 master node 1 worker node

root@k8s-master1:~/.kube# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master1 Ready control-plane 152m v1.28.2
k8s-worker01 Ready 150m v1.28.2

Kubernetes version: v1.28.2
Cloud being used: (put bare-metal if not on a public cloud)
Installation method: on vmware workstation , 1 master node 1 worker node
Host OS: Ubuntu 22.04.2 LTS
CNI and version:
CRI and version:

only getting this error on worker node
root@k8s-worker01:~# kubectl get nodes
E0919 14:57:21.242964 414467 memcache.go:265] couldn’t get current server API group list: Get “http://localhost:8080/api?timeout=32s”: dial tcp 127.0.0.1:8080: connect: connection refused
E0919 14:57:21.243436 414467 memcache.go:265] couldn’t get current server API group list: Get “http://localhost:8080/api?timeout=32s”: dial tcp 127.0.0.1:8080: connect: connection refused
E0919 14:57:21.245295 414467 memcache.go:265] couldn’t get current server API group list: Get “http://localhost:8080/api?timeout=32s”: dial tcp 127.0.0.1:8080: connect: connection refused
E0919 14:57:21.246960 414467 memcache.go:265] couldn’t get current server API group list: Get “http://localhost:8080/api?timeout=32s”: dial tcp 127.0.0.1:8080: connect: connection refused
E0919 14:57:21.248726 414467 memcache.go:265] couldn’t get current server API group list: Get “http://localhost:8080/api?timeout=32s”: dial tcp 127.0.0.1:8080: connect: connection refused

1 Like

I am also facing the same issue.

I am also facing the same issue. Is it an environmental issue?

E1002 09:52:24.327737 9431 memcache.go:265] couldn’t get current server API group list: Get “http://localhost:8080/api?timeout=32s”: dial tcp [::1]:8080: connect: connection refused

You have to set KUBECONFIG environment variable with the path of the k8s config file

$ echo $KUBECONFIG
empty

$ kubectl get pods
E1002 10:16:21.854341  105845 memcache.go:265] couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s": dial tcp [::1]:8080: connect: connection refused

$ KUBECONFIG=$HOME/.kube/config

$ kubectl get pods
No resources found in default namespace.

1 Like

On the control plane server configure kubectl using commands in the output and you are all set:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

2 Likes

I am facing the same issue. But I can’t resolve on Ubuntu 22.04.3. All is configured well, the first time I set the variable KUBECONFIG and called “kubectl get nodes” it was showing me the expected output “No resources found in default namespace.”, but the next times " couldn’t get current server API group list: Get “http://localhost:8080/api?timeout=32s ”: dial tcp 127.0.0.1:8080: connect: connection refused" again. It’s so weird.

2 Likes

In my case, this was caused by using sudo with the kubectl command. Without sudo it worked fine again.

Hopefully this helps someone else.

1 Like

export KUBECONFIG=/etc/kubernetes/admin.conf

or

mkdir ~/.kube
cp /etc/kubernetes/admin.conf ~/.kube/config

1 Like

Resolved on debian 12. If you check your KUBECONFIG with a cat /etc/kubernetes/admin.conf, you shoud see the same configuration if you run this command : sudo kubectl config view . If not, if the config is null/empty it means that the environment cannot be accessed only with sudo but with sudo -E

The sudo -E option preserves the user environment, which includes the KUBECONFIG variable you set. So when you run sudo -E kubectl config view, it uses the KUBECONFIG variable from your user environment, allowing kubectl to find and use your admin.conf file.
Always use sudo -E with kubectl commands you run, if you want to use the KUBECONFIG configuration.

2 Likes

Worth noting that it seems to me there is typically no reason to use sudo with kubectl. kubectl isn’t a privileged command, in a *nix sense - it doesn’t interact with files with root only perms, or bind to ports under 1025 (or any ports for that matter), or anything like that. It isn’t normally in /sbin/ or anything.

Yes it can do a lot, but specifically on the k8s cluster. The authn/authz is all a matter for k8s, not for standard *nix permissions. That is why the ~/.kube/config file has client cert and key in it. The typical way to control what unix users can use kubectl is to control which users get that config file including the cert/key.

If you did want to gate it behind sudo, I think the way would be to set up the root user (or other user if using sudo -u <username> <command>) with the proper ~/.kube/config file, then you would not need to use -E with sudo (which is not great to do).

I say all this, because I know I had to think about it a bit before I figured out why such a ‘powerful’ command wasn’t behind sudo by default. Definitely could be a bit confusing for a new user!

(on the other hand, I am also new to k8s, I could have gotten something wrong here, if I did let me know)

1 Like

Hi. This commands we might execute only master node ?

Thank you very much, my kubectl is working fine now, I executed these commands on master

which commands did you try? I’m having similar issues and I’m on Debian 12 on WSL2 but I’m getting a different url: “https://kubernetes.docker.internal:6443/api?timeout=32s

Firstly check why this error arised.
In my case it was minikube, so ran command ‘minikube logs --problems’ to identify problem.

Then ran “Windows PowerShell” as administrator and perfromed ‘minikube start’.
It worked for me.