<p>I am attempting to install my first kubernetes cluster on Ubuntu 22.04 server.  I'm following the instructions given at this link (<a href="https://www.cloudsigma.com/how-to-install-and-use-kubernetes-on-ubuntu-20-04/" rel="nofollow noreferrer">https://www.cloudsigma.com/how-to-install-and-use-kubernetes-on-ubuntu-20-04/</a>).  <em>Granted, this is actually for Ubuntu 20.04, but I presume it should be close enough</em>.</p>
<p>I am at step #6, and I've just executed the &quot;INIT&quot; 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) &quot;kubectl&quot; executions fail:</p>
<pre><code>&lt;nonrootuser&gt;@k8s-cluster1-control1:~/kubernetes$ kubectl get pods -A
The connection to the server &lt;controlNodeIPAddress&gt;.1:6443 was refused - did you specify the right host or port?
</code></pre>
<p>When it does function I see:</p>
<pre><code>&lt;nonrootuser&gt;@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
</code></pre>
<p>According to this link (<a href="https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#pods-in-runcontainererror-crashloopbackoff-or-error-state" rel="nofollow noreferrer">https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#pods-in-runcontainererror-crashloopbackoff-or-error-state</a>), this isn't normal, but they don't provide much in attempting to debug this.</p>
<p>I am &quot;<em><strong>VERY GREEN</strong></em>&quot; 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?</p>
<p>Thank you!!</p>
<p>P.S.
My kubeadm version is:</p>
<pre><code>kubeadm version: &amp;version.Info{Major:&quot;1&quot;, Minor:&quot;24&quot;, GitVersion:&quot;v1.24.1&quot;, GitCommit:&quot;3ddd0f45aa91e2f30c70734b175631bec5b5825a&quot;, GitTreeState:&quot;clean&quot;, BuildDate:&quot;2022-05-24T12:24:38Z&quot;, GoVersion:&quot;go1.18.2&quot;, Compiler:&quot;gc&quot;, Platform:&quot;linux/amd64&quot;}
</code></pre>

<p>It appears that the &quot;default&quot; install of &quot;containerd&quot; (current version 1.6.6 as of today) from the Ubuntu &quot;Jammy&quot; repository does not create a config file (/etc/containerd/config.toml) that functions properly.  Even removing the &quot;disabled_plugins = ...&quot; 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.</p>
<p>Using the these instructions (<a href="https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/install-containerd-on-ubuntu-22-04.html" rel="noreferrer">https://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/install-containerd-on-ubuntu-22-04.html</a>), I was able to create a new defaule config file, modify it to enable &quot;SystemdCgroup&quot;, and the restart containerd and Kubelet services.</p>
<p>Since the restarts, all the pods that are expected to start have reached a &quot;Running&quot; state, and have not restarted (for over 3 hours).</p>
