![]() ![]() It's important to note that this is not a diagram of the process tree but rather a diagram showing which components start and monitor each other. ![]() We have a process architecture something like the following. Systemd is started as PID 1 so the OS will make sure it is always running, systemd makes sure the Kubelet is running, and the Kubelet makes sure our containers with the control plane components are running. But how? The Kubelet will monitor the control plane components but what monitors Kubelet and make sure it's always running? This is where we use systemd. Root 4147 4.4 2.1 473372 82456 ? Ssl 05:18 1:08 /usr/bin/kubelet -kubeconfig=/etc/kubernetes/nf -require-kubeconfig=true -pod-manifest-path=/etc/kubernetes/manifests -allow-privileged=true -network-plugin=cni -cni-conf-dir=/etc/cni/net.d -cni-bin-dir=/opt/cni/bin -cluster-dns=100.64.0.10 -cluster-domain=cluster.local -v=4 # ps aux | grep /usr/bin/kubelet | grep -v grep kubeadm doesn't mention anything about the Kubelet but we can verify that it's running: We can see that kubeadm created the necessary certificates for the API, started the control plane components, and installed the essential addons. generated token: "d97591.135ba38594a02df1" created keys and certificates in "/etc/kubernetes/pki" created "/etc/kubernetes/nf" created "/etc/kubernetes/nf" created API client configuration created API client, waiting for the control plane to become ready all control plane components are healthy after 21.451883 seconds waiting for at least one node to register and become ready first node is ready after 0.503915 seconds created essential addon: kube-discovery, waiting for it to become ready kube-discovery is ready after 17.003674 seconds created essential addon: kube-proxy created essential addon: kube-dns Kubernetes master initialised successfully! You can now join any number of machines by running the following on each node: kubeadm join -token d97591.135ba38594a02df1 10.240.0.2 Let's look at what happens when we run kubeadm. This is exactly what kubeadm sets us up to do. It uses the API server but it doesn't depend on it so we can actually use the Kubelet to manage the control plane components. kubeadm and the kubeletįortunately, Kubernetes has a component called the Kubelet which manages containers running on a single host. ![]() This will make sure they are always running but won't make it easy to upgrade the components later. One way to make sure the control plane components are always running is to use systemd. But there are a number of things you have to think about, like how do you make sure each of them are always running? How do you update the components easily with as little impact to the system as possible? You could install them directly on the host machine by downloading them and running them but if they crash then you'd have to restart them manually. These components need to be installed on your master and can be installed in a number of ways. The API server depends on etcd so an etcd cluster is also required. The Kubernetes control plane consists of the Kubernetes API server ( kube-apiserver), controller manager ( kube-controller-manager), and scheduler ( kube-scheduler). The documentation for kubeadm outlines how to set up a cluster but as I was doing that I found how kubeadm actually sets up the master to be really interesting so I wanted to share that here. kubeadm really makes this easier so I suggest you give it a try. One of the most frequent criticisms of Kubernetes is that it's hard to install. Kubeadm is a new tool that is part of the Kubernetes distribution as of 1.4.0 which helps you to install and set up a Kubernetes cluster. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |