skip to Main Content

I am attempting to install my first kubernetes cluster on Ubuntu 22.04 server. I’m following the instructions given at this link (https://www.cloudsigma.com/how-to-install-and-use-kubernetes-on-ubuntu-20-04/). Granted, this is actually for Ubuntu 20.04, but I presume it should be close enough.

I am at step #6, and I’ve just executed the "INIT" command (sudo kubeadm init –pod-network-cidr=10.255.0.0/16) on just the control node {Haven’t gotten to the worker node yet} . I notice that sometimes (fairly often) "kubectl" executions fail:

<nonrootuser>@k8s-cluster1-control1:~/kubernetes$ kubectl get pods -A
The connection to the server <controlNodeIPAddress>.1:6443 was refused - did you specify the right host or port?

When it does function I see:

<nonrootuser>@k8s-cluster1-control1:~/kubernetes$ kubectl get pods -A
NAMESPACE     NAME                                            READY   STATUS             RESTARTS         AGE
kube-system   coredns-6d4b75cb6d-qmcg7                        0/1     Pending            0                8m7s
kube-system   coredns-6d4b75cb6d-z6ks5                        0/1     Pending            0                8m7s
kube-system   etcd-k8s-cluster1-control1                      1/1     Running            13 (4m55s ago)   6m4s
kube-system   kube-apiserver-k8s-cluster1-control1            1/1     Running            16 (3m43s ago)   9m14s
kube-system   kube-controller-manager-k8s-cluster1-control1   1/1     Running            5 (3m9s ago)     5m53s
kube-system   kube-proxy-smp7q                                0/1     CrashLoopBackOff   4 (62s ago)      8m8s
kube-system   kube-scheduler-k8s-cluster1-control1            0/1     CrashLoopBackOff   20 (35s ago)     6m11s

According to this link (https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#pods-in-runcontainererror-crashloopbackoff-or-error-state), this isn’t normal, but they don’t provide much in attempting to debug this.

I am "VERY GREEN" to kubenetes, but have been using some for of Linux since 1998. I guess my issue is that I can’t find a lot of logging in attempts to debug (or just don’t understand it enough yet). Any pointers how I might proceed?

Thank you!!

P.S.
My kubeadm version is:

kubeadm version: &version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.1", GitCommit:"3ddd0f45aa91e2f30c70734b175631bec5b5825a", GitTreeState:"clean", BuildDate:"2022-05-24T12:24:38Z", GoVersion:"go1.18.2", Compiler:"gc", Platform:"linux/amd64"}

2

Answers


  1. Chosen as BEST ANSWER

    It appears that the "default" install of "containerd" (current version 1.6.6 as of today) from the Ubuntu "Jammy" repository does not create a config file (/etc/containerd/config.toml) that functions properly. Even removing the "disabled_plugins = ..." entry (i.e. everything within the file is commented out) does not provide a stable containerd process. My guess is that since the file is provided, the embedded defaults that containerd is built with are not used and the process is now clueless on how to run.

    Using the these instructions (https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/install-containerd-on-ubuntu-22-04.html), I was able to create a new defaule config file, modify it to enable "SystemdCgroup", and the restart containerd and Kubelet services.

    Since the restarts, all the pods that are expected to start have reached a "Running" state, and have not restarted (for over 3 hours).


  2. The accepted answer is correct. You have to tweak containerd as shown here.

    I’m just saving you some time with the commands you need to use for Containerd configuration for Kubernetes:

    sudo mkdir -p /etc/containerd/
    
    containerd config default | sudo tee /etc/containerd/config.toml
    
    sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml
    

    Then reboot the server (and not just containerd as suggested in the article).

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search