How are the pods kube-apiserver,etcd-kmaster,kube-controller and scheduler re-created after deleting-CodePudding

Following is the basic k8 setup deployed using kubeadm tool. when I delete pods like etcd,api-server,sheduler and controller it re-created immediately. I am wodering who is really monitoring these pods as these are not part of replicaset or deployments and these are just stand alone pods.

root@kmaster:~# oc get all -n kube-system <br/>
NAME                                           READY   STATUS    RESTARTS        AGE
pod/calico-kube-controllers-7659fb8886-jfnfq   1/1     Running   7 (120m ago)    3d18h
pod/calico-node-7xkvm                          1/1     Running   1 (3d7h ago)    3d18h
pod/calico-node-q8l4d                          1/1     Running   54 (120m ago)   3d18h
pod/calico-node-v698m                          1/1     Running   51 (119m ago)   3d18h
pod/coredns-78fcd69978-ftmwz                   1/1     Running   7 (120m ago)    3d18h
pod/coredns-78fcd69978-kg9r5                   1/1     Running   7 (120m ago)    3d18h
pod/etcd-kmaster                               1/1     Running   7 (120m ago)    3d18h
pod/kube-apiserver-kmaster                     1/1     Running   7 (120m ago)    3d18h
pod/kube-controller-manager-kmaster            1/1     Running   7 (120m ago)    44m
pod/kube-proxy-jcl8n                           1/1     Running   1 (3d7h ago)    3d18h
pod/kube-proxy-tg8x9                           1/1     Running   7 (120m ago)    3d18h
pod/kube-proxy-x58b8                           1/1     Running   7 (119m ago)    3d18h
pod/kube-scheduler-kmaster                     1/1     Running   7 (120m ago)    3d18h

NAME               TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
service/kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   3d18h

NAME                         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
daemonset.apps/calico-node   3         3         2       3            2           kubernetes.io/os=linux   3d18h
daemonset.apps/kube-proxy    3         3         2       3            2           kubernetes.io/os=linux   3d18h

NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/calico-kube-controllers   1/1     1            1           3d18h
deployment.apps/coredns                   2/2     2            2           3d18h

NAME                                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/calico-kube-controllers-7659fb8886   1         1         1       3d18h
replicaset.apps/coredns-78fcd69978                   2         2         2       3d18h
root@kmaster:~#

CodePudding user response：

These pods are typically supervised by the Kubelet, directly on the node.

Static Pods are always bound to one Kubelet on a specific node. The main use for static Pods is to run a self-hosted control plane: in other words, using the kubelet to supervise the individual control plane components.

See Static Pods.

CodePudding user response：

To extend the answer of Jonas a little bit:

Kubernetes can manage applications that are core components of Kubernetes such as the kube-apiserver, kube-scheduler and so on. On every node kubelet runs as a systemd service.

One job that Kubelet has, is to regularly check the folder /etc/kubernetes/manifests on every master/control-plane node and run any Pods that are defined in there. These Pods are referred to as static-pods.

If you wanted to you could create your own static-pod by creating a new file on the node:

$ cat <<EOF >/etc/kubernetes/manifests/my-static-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-static-pod
  labels:
    foo: bar
spec:
  containers:
    - name: nginx
      image: nginx
EOF

After a short while Kubelet will run your Pod in the same way as the Kubernetes components.

Since they are managed by Kubelet you actually cannot delete them by executing something like kubectl delete pod >some-static-pod>. The reason is that all kubectl commands go to the kube-apiserver. However, static-pods are special in the way that they are not managed by the Kubernetes API but by Kubelet itself. kubectl delete pod <some-static-pod> may appear to delete the desired Pod but that is not the case. The Pod still continues to run on the node.

To delete a static-pod the file on the node needs to be removed:

$ rm /etc/kubernetes/manifests/my-static-pod.yaml