In this scenario you'll learn how to bootstrap a Kubernetes cluster using Kubeadm.
Kubeadm solves the problem of handling TLS encryption configuration, deploying the core Kubernetes components and ensuring that additional nodes can easily join the cluster. The resulting cluster is secured out of the box via mechanisms such as RBAC.
More details on Kubeadm can be found at https://github.com/kubernetes/kubeadm
Getting Started With CRI-O and Kubeadm
Step 1 - Initialise Master
Kubeadm has been installed on the nodes. Packages are available for Ubuntu 16.04+, CentOS 7 or HypriotOS v1.0.1+.
The first stage of initialising the cluster is to launch the master node. The master is responsible for running the control plane components, etcd and the API server. Clients will communicate to the API to schedule workloads and manage the state of the cluster.
The following will use CRI-O, a lightweight container runtime for Kubernetes. There is currently a bug meaning that CRI-O needs to be restarted before beginning. Execute the workaround with
systemctl restart crio
The command below will initialise the cluster with a known token to simplify the following steps. The command points to an alternative Container Runtime Interface (CRI), in this case, CRI-O.
kubeadm init --cri-socket=/var/run/crio/crio.sock --kubernetes-version $(kubeadm version -o short)
In production, it's recommend to exclude the token causing kubeadm to generate one on your behalf.
Notice, there are no Docker containers running.
Instead, everything is managed via CRI-O. The status of which can be explored via
Because CRI-O is built for Kubernetes it means there are no Pause containers. This is just one of the many advantages of having a container runtime designed for Kubernetes.
By default, the
crictl CLI is configured to communicate with the runtime by the config file at