Detailed explanation of Kubernetes pod orchestration and lifecycle

K8S Master Basic Architecture

The operation of the K8S cluster depends on the communication between the Master node and the Node node. In order to better understand the Pod life cycle in Part 4, we first give a simple architecture diagram of the K8S Master. In subsequent articles, we will analyze the relationship between the Master, Node, and Pod.

Master architecture diagram:

in:

The API Server provides an HTTP REST interface, which is the only entry point for adding, deleting, modifying, and checking all resources in k8s, and is also the entry point for cluster control;

Scheduler is the process responsible for resource scheduling;

Controller Manager is the automation control center for all resource objects;

Etcd provides data storage services for resource objects

Each component has many knowledge points. Here we just need to have a macro impression. In subsequent articles, we will analyze them one by one.

Pod Orchestration Concept

At the end of the previous article, we mentioned the precautions when migrating applications to k8s. Let me reiterate here that when we want to migrate applications on virtual machines to k8s, we need to use Pod to build our application modules. At this point, it is more important to divide our application modules, because containers and virtual machines have different design patterns, but in order to better understand and compare the relationship between the two, we can imagine the following correspondence:

k8s-----operating system

Pod - Virtual Machine

Container-Process

1. k8s is equivalent to the operating system of a physical machine, and k8s management of Pod is equivalent to the operating system of a physical machine managing a virtual machine

2. Pod is equivalent to a virtual machine. A Pod may contain multiple containers, corresponding to many processes in the virtual machine.

3. A container is equivalent to a process. The essence of a container is actually a process.

With this concept, it may be more vivid to understand Pod. Let's go back to our application migration. Assuming our application exists:

web service, log analysis, MySQL database

Three key modules, among which:

Web services and log analysis have a "super close relationship" because the log analysis module consumes the logs generated by the web service module, so they must be deployed on the same server. On the contrary, the web service and MySQL database can be accessed via TCP-IP, so there is no need to deploy them on the same machine. If we run this application in a container, the web service needs to be packaged in the same Pod as the log analysis module, and the MySQL database service can be deployed in a separate Pod. When our application is migrated to k8s, it may have the following structure:

Arranging different processes or tasks in the same Pod is essentially a Pod arrangement concept.

What are the properties of the Pod object and the properties of the container?

From the above analysis, it is not difficult to see that the container is an element belonging to the Pod. From the YAML file, the container is a field in the entire YAML file of the Pod. Now let's look at the important properties of Pods and containers.

First look at the properties of the Pod:

1. All attributes related to scheduling, network, storage, and security are basically related to Pod.

Scheduling, of course, goes without saying. Pod is the smallest scheduling unit of k8s; network, containers in the same Pod share the Pod's network; storage, different containers can share the Pod's storage by mounting volumes on the Pod; security is also controlled based on the Pod dimension.

2. All attributes related to the Linux Namespace of the container are also at the Pod level.

The original intention of Pod design is to share Namespace between containers.

3. All containers in a Pod must share the host's Namespace at the Pod level.

This is easier to understand. Because the Pod needs to share the host's Namespace, the containers in the Pod must share the same Namespace, so this setting must be at the Pod level.

Let's look at two important properties of Container:

1. ImagePullPolicy: This attribute defines the image pulling policy. Its default value is always, which means that an image is pulled every time a Pod is created. It has two other values, never and ifnotpresent. These two are easier to understand. One is to never pull the image, and the other is to pull the image only when the image does not exist. One thing to note here is that if our version number is configured as latest, then ImagePullPolicy will be set to the default value always.

2. Lifecycle: As the name implies, it performs certain actions during the life cycle of the container. It has two common parameters, postStart and preStop, which are specific operations performed after the container starts or before the container ends.

Pod Lifecycle

The life cycle of a Pod is mainly reflected in the status part of the Pod API. The life cycle of a Pod includes the following processes from start to end:

1. Pending, indicating that the Pod's yaml file has been handed over to k8s and saved in etcd (etcd is the meta-information repository in k8s). But it was not created due to reasons such as unsuccessful scheduling.

2. Running. This word is misleading. It means that the Pod has been successfully scheduled and bound to a specific node server. Not all containers in the Pod are running normally, but at least one is running.

3. Succeeded: This status means that all containers have been started and exited.

4. Failed: This is easy to understand. It means that at least one of the containers in the Pod exited with a non-zero status, that is, it exited abnormally.

5.Unknow. This is an abnormal state, indicating that the current Pod status cannot be reported to the kube-apiserver normally. This may be a problem with the communication between the master and slave nodes.

The following is a Pod in the running state:

[root@VM-16-13-centos ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
mysql-pd7jr 1/1 Running 0 118d
myweb-60r22 1/1 Running 0 80d

[root@VM-16-13-centos ~]#
 [root@VM-16-13-centos ~]# kubectl get pod mysql-pd7jr -o yaml
apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  ...
status:
  ...
  hostIP: 127.0.0.1
  phase: Running
  podIP: 172.17.0.2
  startTime: 2020-11-20T09:01:39Z

The above is a detailed explanation of the orchestration and life cycle of kubernetes pod. For more information about the orchestration and life cycle of kubernetes pod, please pay attention to other related articles on 123WORDPRESS.COM!