Ubuntu Server struggles with Kubernetes installation after Docker – new stack

I have bones to choose with someone. To be honest, I don’t know who to direct this anger at, but there are major issues with using Ubuntu Server as the base for his Kubernetes right now.

Over the past few days, I have tried many times to get Kubernetes up and running on Ubuntu Server 22.04, but failed after many attempts. You can now successfully install Kubernetes on Ubuntu Server, as you have done many times before. The only difference is that instead of using Docker, you should use a runtime like containerd. However, when I try to initialize the cluster (every time) I get an error.

It doesn’t matter if I’m from a fresh install or have been sudo kubeadm reset, times out and is not initialized. I’ve tried this 3 times (each on a new instance of Ubuntu Server 22.04) with no success.

This issue could have caused problems installing the latest version of containerd on Ubuntu Server, but after trying a new deployment with an older version of containerd, I still had the same issue.

I was frustrated with this little experiment. His Kubernetes cluster on Ubuntu Server 22.04 is straightforward. it’s not. I can run a single instance just fine, and even use it to deploy apps. But the moment you want to go the cluster route, things go seriously wrong.

See also  Casio releases Pro TREK with biomass plastic and twin-layer Lcd

Drill down

The interesting thing about this error is that the kubelet is running. However, when running:

sudo systemctl status kubelet

I get an error similar to:

Aug 04 13:56:19 kubecontroller kubelet[550949]: E0804 13:56:19.613305  550949 kubelet.go:2424] "Error getting node" err="node "kubecontroller" not found"

Aug 04 13:56:19 kubecontroller kubelet[550949]: E0804 13:56:19.714099  550949 kubelet.go:2424] "Error getting node" err="node "kubecontroller" not found"

Aug 04 13:56:19 kubecontroller kubelet[550949]: E0804 13:56:19.814923  550949 kubelet.go:2424] "Error getting node" err="node "kubecontroller" not found"

The next rabbit hole involved the ~./kube/config file. Even after double checking the permissions on that file, I still had the problem. Fix the issue and restart the kubelet.

sudo systemctl restart kubelet

guess what? Now the kubelet won’t start.

Let’s pull the hair!

Do a quick system reboot to see if it washes away any lingering discomfort. After the machine reboots, Initialization After running the command, you can view more troubleshooting information, such as:

sudo kubeadm init

guess what? New errors like:

error execution phase wait-control-plane

k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run.func1    cmd/kubeadm/app/cmd/phases/workflow/runner.go:235

k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).visitAll    cmd/kubeadm/app/cmd/phases/workflow/runner.go:421

k8s.io/kubernetes/cmd/kubeadm/app/cmd/phases/workflow.(*Runner).Run    cmd/kubeadm/app/cmd/phases/workflow/runner.go:207

k8s.io/kubernetes/cmd/kubeadm/app/cmd.newCmdInit.func1    cmd/kubeadm/app/cmd/init.go:153

k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).execute    vendor/github.com/spf13/cobra/command.go:856

k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).ExecuteC    vendor/github.com/spf13/cobra/command.go:974

k8s.io/kubernetes/vendor/github.com/spf13/cobra.(*Command).Execute    vendor/github.com/spf13/cobra/command.go:902

k8s.io/kubernetes/cmd/kubeadm/app.Run    cmd/kubeadm/app/kubeadm.go:50

main.main    cmd/kubeadm/kubeadm.go:25

runtime.main    /usr/local/go/src/runtime/proc.go:250

runtime.goexit    /usr/local/go/src/runtime/asm_amd64.s:1571

Obviously, it’s zero help. And no matter how much time I spend with my friend’s girlfriend Google, I can’t find an answer to what’s bothering me.

Back to the beginning. Same result with another install. And of course the official Kubernetes documentation is completely useless.

What conclusions can be drawn? (If Ubuntu Server is your go-to) what can you do?

It’s all about Docker

Once upon a time, deploying a Kubernetes cluster on Ubuntu Server was pretty easy and rarely (if ever) failed. What’s the difference?

In a nutshell… Docker.

The second Kubernetes removed Docker support, making deploying a cluster on Ubuntu Server an absolute nightmare. With that in mind, what can you do? You can always install microk8s via snap with the following command:

See also  Galaxy S21 Ultra vs Z Fold 3 Camera Comparison: Which Is Best?

sudo snap install microk8s --classic --channel=1.24

Of course, as we all know, snap installs can be slow and not as responsive as standard installs. But… when in Rome.

Once installed, add the user to the required group using:

sudo usermod -a -G microk8s $USER

Change the permissions of the .kube directory as follows:

sudo chown -f -R $USER ~/.kube

Log out, log back in, and run the following commands:

microk8s status --wait-ready

Big bada boom, everything is working. You can deploy NGINX apps using:

microk8s kubectl create deployment nginx --image=nginx

But this is not a cluster. Ah, but the microk8s takes care of it. On the controller node, issue the following command:

microk8s add-node

You will see the join command to run on other machines with microk8s installed, like this:

microk8s join 192.168.1.43:25000/bad12d3d8966b646442087d6a1edde436/6407f3e21772

Ah, but I think you’ll get an error like this:

Contacting cluster at 192.168.1.43

Connection failed. Invalid token (500).

Reboot both machines and rerun the add-node command. –skip verification No commands, no dice.

Set hostnames on both machines, make sure those hostnames are mapped in /etc/hosts and double check that the time is correct on both machines. do not trade at all.

However, for some reason after the second reboot of both machines the node was able to join the controller. This process took much longer than it should have, but I associate it with using the snap version of the service.

after running microk8s kubectl get nodeI now see both nodes in the cluster.

Haza.

reason to make it difficult

Who cares… it’s not a big deal. seriously. Kubernetes is already a difficult platform to use. To make it just as difficult to get up and running, you quickly notice the simplicity of Docker Swarm.

Sure, we could have moved to RHEL-based servers for Kubernetes deployments, but Ubuntu Server has been our go-to for years. Don’t get me wrong, I don’t mind microk8, but it won’t work with something like Portainer (for those kinds of things, Portainer is my go-to). For that, you need to add the Portainer addon as follows:

microk8s enable community

microk8s enable portainer

Great… just not. what’s wrong now After enabling Portainer, it will tell you to access it via the node port, whose address you can get using the following command:

export NODE_PORT=$(kubectl get --namespace portainer -o jsonpath=".spec.ports[1].nodePort" services portainer)

Wait a second… kubectl It’s not installed because I’m using microk8s. You should change the command to:

export NODE_PORT=$(microk8s kubectl get --namespace portainer -o jsonpath=".spec.ports[1].nodePort" services portainer)

Then you need to run the command (again, change the command below to include microk8s):

export NODE_IP=$(microk8s kubectl get nodes --namespace portainer -o jsonpath=".items[0].status.addresses[0].address")  echo https://$NODE_IP:$NODE_PORT

The last command reports the address used to access Portainer.

Wouldn’t it be great if it worked? It wasn’t.

guess what? This is all from the official documentation (minus the addition of the microk8s part of the command, which was conveniently omitted).

For those responsible for these technologies, this shouldn’t be too difficult. I understand that there may be some friction between Kubernetes and Canonical, but when it spills over into userspace, the real frustration falls on admins and developers.

Please, please, please fix these problems. That way, users who prefer Ubuntu Server will be able to take advantage of his Kubernetes as easily as before.

The New Stack, a wholly owned subsidiary of Insight Partners, is an investor in the company mentioned in this article: Docker.

Image by Monique Stokman from Pixabay.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.