We usually use Kubectl to manage our Kubernetes cluster. When we need an Nginx service, we can use the following command to create it:

kubectl create deployment nginx --image nginx
Copy the code

Returns:

deployment.apps/nginx created
Copy the code

Wait a moment and a Pod containing an Nginx container will start successfully. So what happens inside Kubernetes after we execute the above command?

Core components

Before we get into what’s happening internally, we need to understand the roles and roles of the following four core components in the Kubernetes cluster:

  • Kube-apiserver: The Kubernetes API server validates and configures data for API objects such as Pods, Services, and so on. The API server services REST operations and provides a front end to the shared state of the cluster through which all other components interact.

  • Kube-controller-manager: control plane component that runs controller processes. Logically, each controller is a separate process, but to reduce complexity, they are all compiled into the same executable and run in the same process, so it will be called a Manager. It includes DeploymentController, ReplicaSetController, JobController, and more.

  • Kube-scheduler: The control plane component that monitors newly created Pods on an unspecified running node and selects nodes for Pods to run on. Scheduling decisions consider resource requirements for individual pods and Pod collections, hardware/software/policy constraints, affinity and anti-affinity specifications, data location, interference between workloads, and deadlines.

  • Kubelet: An agent that runs on every node in the cluster. It ensures that containers are running in a Pod. Kubelet receives a set of PodSpecs provided to it through various mechanisms, ensuring that the containers described in those PodSpecs are running and healthy.

Simplify the core process

With that in mind, let’s take a look at what’s going on inside Kubernetes:

  1. The user makes a request to kube-Apiserver via Kubectl to create a Deployment object.

  2. Kube-apiserver creates a Deployment object after authenticating (AuthN), authorizing (AuthZ), admission Control, validation, and so on on the above request.

  3. The above Deployment create event is listened on by DeploymentController through its internal DeploymentInformer, and then, according to the logic set inside DeploymentController, It will create a ReplicaSet object. Source syncDeployment

  4. The above ReplicaSet creation event will be monitored by the ReplicaSetController through its internal ReplicaSetInformer, and based on the internal logic of the ReplicaSetController, It creates a Pod object where the Pod spec. nodeName field is null; Source syncReplicaSet

  5. The above Pod creation event is listened on by Scheduler’s internal PodInformer, which selects an appropriate Node, such as Node-a, based on its internal scheduling algorithm. And update the Pod spec.nodename field. Source code for the Schedule

  6. NodeName matches Pod spec. nodeName. Kubelet will then start the Pod container in A certain sequence of steps. And writes the started container information to the Pod’s Status. Source syncPod

As mentioned above, DeploymentController, ReplicaSetController, and many other independent control loops communicate by listening for changes in objects on kube-Apiserver that trigger events via various Informer, Execute its corresponding business logic. This is designed to reduce stress on apiserver.

Kubelet the process of creating a Pod

The Pod creation process can be roughly divided into four steps (actually seven, with the three preceding steps omitted). Source SyncPod) :

  1. Create a sandbox for Pod, the Infrastructure Container (image name k8s.gcr. IO /pause), whose main purpose is to create and share process namespaces.

  2. Create Ephemeral Containers (Alpha feature, not turned on by default) as specified in the Pod specification. Ephemeral Containers are special Containers that run temporarily in an existing Pod to perform user-initiated operations, such as troubleshooting. Instead of building applications, you can use temporary containers to examine services.

  3. Create Init Containers as specified in the Pod specification, which are special Containers that run before the application Containers within the Pod start. The Init container can contain utilities and installation scripts that do not exist in the application image.

  4. Create the regular Containers specified in the Pod specification in turn.

reference

  • An In-depth Analysis of Kubernetes by Zhang Lei
  • Michael Hausenblas, Stefan Schimanski, Kubernetes Programming
  • Kubernetes components
  • Explain how Kubernetes Deployment is implemented
  • Details on the implementation principle of Kubernetes ReplicaSet
  • Explain the implementation principle of Kubernetes Pod
  • Kubernetes CRI analysis – Kubelet creates Pod analysis

More and more

For more classic examples: github.com/jxlwqq/kube…