如何停止Kubernetes控制飞机吊舱？

Question

Just curious, with mesos I'm used to being able to do systemctl stop mesos-master and systemctl start mesos-master (if I need to bounce it for some reason). With k8s, there are multiple components to 'stop' in the control plane, such as apiserver, controller-manager, etc.

When creating a cluster with kubeadm, it runs the control plane as pods (no replica set, or anything like that, perhaps because I only have a single master at the moment).

What's the best way to stop the things in the control plane and then start them again, without tearing down the cluster?

Answer 1

Kubernetes cluster is divided itself into micro-service which means each components should be independent of each other.If one of the component fail it should not affect other components in order to avoid terrible cascading effect.

Let's begin with Linux Kernel . It makes sure that Systemd is healthy and doing its job. Now Kubeadm make sure that Kubelet (In master Node) is running as systemd service . You can check it by following command

systemctl status kubelet

Kubelet(in the master node) make sure that control plane components which are etcd,kube-apiserver,kube-controller-manager and kube-scheduler running as pod by docker engine however, they are systemd service.As they are using host networking and host socket in their manifest files. You can check their status by using systemctl and journalctl .

 systemctl status kube-apiserver

Pods in the Worker nodes, use Pod Network by using CNI Plugins.

Now K8s cluster is alive and Kube-apiServer and other components are healthy. you can feed all other k8s resources such as deployment , replicaSet, service etc and will be deployed to the worker nodes. It will work according to your desire which will be a desired state in etcd.

Once deployed resources(pods ,service etc) are running in the worker nodes.Master node's responsibility is to make sure desired state === current State .

If Master Node is dead , Worker node will be orphan which means your current state would be final state.

Answer to your question

You can start each components in the Master node but keeping in the mind the dependancy of them.

Examples

If Kube api-server fails , other components (kube-scheduler,kube-controller-manager) won't be able to talk with etcd (source of the truth).

Kube-Controller-manager is further divided into controllers such as replicaSet Controller, Deployment Controller, Service Controller , etc. They mind their own business and make sure that desired state === current state. The interesting thing is If one of the controllers fails in Kube-controller-manager will stop all of the controllers and terminate itself. Now Kubelet will make it up agian.

In conclusion,We need to make sure that our Master node does not have any single point of failure that's why we always wish to have highly available control plane.

Answer 2

The Kubernetes control plane pods are often deployed as Static Pods . These are not managed by any kind of Deployment controller, but are defined in static (hence the name) configuration files that are placed in a configuration directory (like for example /etc/kubelet.d/ or /etc/kubernetes/manifests , depending on how your cluster is set up). These definition files are picked up by the Kubelet running on the Kubernetes master node that creates the respective pods.

According to the documentation, you can stop/delete static pods simply by removing the respective configuration files, and start/create them again by creating new files:

Running kubelet periodically scans the configured directory ( /etc/kubelet.d in our example) for changes and adds/removes pods as files appear/disappear in this directory.

 [joe@my-node1 ~] $ mv /etc/kubelet.d/static-web.yaml /tmp [joe@my-node1 ~] $ sleep 20 [joe@my-node1 ~] $ docker ps // no nginx container is running [joe@my-node1 ~] $ mv /tmp/static-web.yaml /etc/kubelet.d/ [joe@my-node1 ~] $ sleep 20 [joe@my-node1 ~] $ docker ps CONTAINER ID IMAGE COMMAND CREATED ... e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago 

To temporarily disable/enable these pods, simply move the definition files to a safe location and back again:

$ mv /etc/kubelet.d/*.yaml /tmp   # Disable static pods
$ mv /tmp/*.yaml /etc/kubelet.d   # Re-enable static pods