K
Q

In k8s processes, "kube-controller-manager" is "child process" from docker conainer. Why k8s has that architecture?

3/24/2020

The process ID 21186 is runc. And 21257 is kube-controller-manager.

I can't understand why host's process is child process.

And, I didn't know docker container can run host's process.

Why k8s takes that architecture.

Other processes are same form.

Can you help please? Thank you

[root@instance-3 ~]# ps -ef | grep 21186
root     21186 10930  0 06:20 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/3fd66799d02cb2c2f195fd85fadf852b7a7c0905707e6c25d1fdec93c1dc850b -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root     21257 21186  1 06:20 ?        00:00:08 kube-controller-manager --aut....
-- user1371662
docker
kubernetes

Similar Questions

best way to edit go template (helm template) file
How do I setup up and deploy Kubeflow with Codefresh
OpenShift or Kubernetes - Create a Job from CronJob using curl command
eureka pod turn to pending state when running a period of time in kubernetes cluster

2 Answers

3/24/2020

This is how containerd an OCI compliant core container runtime works in kubernetes.

enter image description here

  1. Kubelet calls cri-containerd, via the CRI runtime service API, to create a pod;

  2. cri-containerd uses containerd to create and start a special pause container (the sandbox container) and put that container inside the pod’s cgroups and namespace (steps omitted for brevity);

  3. cri-containerd configures the pod’s network namespace using CNI;

  4. Kubelet subsequently calls cri-containerd, via the CRI image service API, to pull the application container image;

  5. cri-containerd further uses containerd to pull the image if the image is not present on the node;

  6. Kubelet then calls cri-containerd, via the CRI runtime service API, to create and start the application container inside the pod using the pulled container image;

  7. cri-containerd finally calls containerd to create the application container, put it inside the pod’s cgroups and namespace, then to start the pod’s new application container. After these steps, a pod and its corresponding application container is created and running.

https://kubernetes.io/blog/2017/11/containerd-container-runtime-options-kubernetes/

-- Arghya Sadhu
Source: StackOverflow
3/24/2020

While it isn't required, a very common deployment strategy for the Kubernetes control plane services is "static pods". These are put into a special folder that the Kubelet looks at on startup and it creates the pods from nothing (which is required since obviously we can't use the API to launch the API server). This is nice because it means that the control plane services are visible in Kubernetes and you can treat them mostly like normal pods (use kubectl logs, port-forward, etc).

-- coderanger
Source: StackOverflow