Running microk8s.status takes forever while it comes instantly when executing with sudo. Other commands like microk8s.kubectl come instantly as normal user.
Before, I added the user to the microk8s group and relogged in.
on ubuntu 18.04
the same with microk8s.kubectl get all
it seemed to be my WSL Debian terminal. After restarting it all is smooth again. Super weird. So it's 99% not related to microk8s, so I'll close this ticket.
I also have encountered similar delays running microk8s.status, microk8s.inspect, or anything similar unless I run it with sudo. In my case, I'm using Ubuntu 18.04 as the host on a laptop that should have ample resources. I can run microk8s in a new VM, add my user to the microk8s group, and performance is normal, but for some reason the problem is present only on my laptop on what should be a fairly generic 18.04 desktop installation. I wanted to add a comment to this issue just in case others encounter it. Unlike the original poster, I'm not using WSL.
inspection-report-20191231_105717.tar.gz
Ah good to know. I haven't experienced this since I restarted my WSL Debian terminals but if I do I'll come back again.
I reopen the ticket, just to have more visibility and if the issue doesn't show up anymore, I will close again!
Is running microk8s.kubectl also very slow? Underneath microk8s.status is primarily running kubectl. Thanks
Yes, running something like microk8s.kubectl get pods has similar slow performance (on the order of ~3 minutes) whereas running sudo microk8s.kubectl get pods takes less than one second.
@mrhoads thanks. If you try to run an external kubectl (not microkk8s.kubectl) pointing to your microk8s cluster is it also slow?
You can get the kubeconfig by doing this microk8s.kubectl config view --raw > $HOME/.kube/config. After that you can use kubectl get
Can you also attach the inspect tarball?
for the record and what I remember,
microk8s.status was slow/never endingmicrok8s.kubetctl get all was slow/never endingmicrok8s.kubectl was fine though(all as normal user)
@balchua thanks for the info. I've attached the inspect tarball. I see similar differences in using kubectl as a snap or the kubectl binary from here. It's not as long as running something like microk8s.status, but is still a noticeable difference (like 1.5 minutes for kubectl get pods as a regular user and ~1 second for sudo kubectl get pods).
Also just for what it's worth, I'm OK with just using sudo for now, especially if @2jj isn't seeing issues now and if others aren't reporting it. Thanks for your help.
Thanks @2jj and @mrhoads these are all good info.
I couldn't reproduce this issue. The performance of using microk8s.status with or without sudo is the same for me.
I'm having the same issue under 18.04.
Actually, wiping out ~/.kube (which was owned by root) fixed the problem.
Removing ~/.kube did the trick for me. Something in ~/.kube/cache/discovery was owned by root. kubectl responsiveness without sudo is now very quick.
Thanks @bobbyrward and @mrhoads for finding a solution.
thanks @mrhoads for this solution, I have run sudo chown -R $USER. ~/.kube and the magic happened!
Thank you everyone. Was running microk8s in a ubuntu VM ... and was facing same issues. Followed the above suggestion of chown - R $USER .kube .... and it fixed the long-timing issues immediately.
Hi, I am trying to configure microk8s on my Ubuntu machine to learn about Kubernetes.
I installed microk8s on Ubuntu 20.04 from snap (with the command sudo snap install microk8s --classic --channel=1.18/stable), following the instructions from microk8s website.
I added my user to microk8s group, chownd the .kube folder and logged out and logged in.
Then I run:
sudo microk8s status --wait-ready
and it just hangs, without showing any information, nor progress (I don't know if it's pulling the required containers or settings things up etc.).
Is there any way I can debug what's going on, or if I installed it the wrong way?
Thanks a lot for the help!
@lucacerone wait-ready will check two things a) the apiserver responds b) there is a node available.
Try microk8s.inspect and attach the tarball in an issue so we take a look.
@ktsakalozos microk8s status --wait-ready just hangs forever
`[appz@appz3 ~]$ microk8s inspect
Inspecting services
Service snap.microk8s.daemon-cluster-agent is running
Service snap.microk8s.daemon-flanneld is running
Service snap.microk8s.daemon-containerd is running
Service snap.microk8s.daemon-apiserver is running
Service snap.microk8s.daemon-apiserver-kicker is running
Service snap.microk8s.daemon-proxy is running
Service snap.microk8s.daemon-kubelet is running
Service snap.microk8s.daemon-scheduler is running
Service snap.microk8s.daemon-controller-manager is running
Service snap.microk8s.daemon-etcd is running
Copy service arguments to the final report tarball
Inspecting AppArmor configuration
Gathering system information
Copy processes list to the final report tarball
Copy snap list to the final report tarball
Copy VM name (or none) to the final report tarball
Copy disk usage information to the final report tarball
Copy memory usage information to the final report tarball
Copy server uptime to the final report tarball
Copy current linux distribution to the final report tarball
Copy openSSL information to the final report tarball
Copy network configuration to the final report tarball
Inspecting kubernetes cluster
Inspect kubernetes cluster
WARNING: IPtables FORWARD policy is DROP. Consider enabling traffic forwarding with: sudo iptables -P FORWARD ACCEPT
The change can be made persistent with: sudo apt-get install iptables-persistent
Building the report tarball
Report tarball is at /var/snap/microk8s/1608/inspection-report-20200915_235000.tar.gz
`
@rasoolasik could you attach the tarball created by microk8s inspect? Thank you.
Most helpful comment
Actually, wiping out ~/.kube (which was owned by root) fixed the problem.