The grievances between Docker and k8s (6)-"Container Orchestration" staged a "Terminator" blockbuster

Please indicate the source for reprinting: Grape City official website , Grape City provides developers with professional development tools, solutions and services, and empowers developers.

In the previous section, we introduced the basic content of Pod and how Kubernetes handles the relationship between containers and containers from the perspective of God. But Pod alone is not enough. For most users, how to schedule and manage their own applications is the real core problem, and the solution to this content is the ultimate killer of Kubernetes.

Orchestration management between Pods

Let us start from an example, suppose the current user needs are:

How to deploy a movable type application for private cloud customers in the form of 3-machine load balancing?

Docker's "classical" approach

In the version previously developed by the movable type grid development group, the implementation method is roughly like this: use three different physical machines, first run the user's application into a container, and then install it on these three physical machines, outside of the three servers Buy another load balancing service, and finally through the domain name resolution configuration, the traffic is directed to three different server machines.

It sounds simple.

But in reality, we will encounter other issues to consider, such as: What if we only have two servers? What if the container in a server is down? What if the CPUs of the two servers are full?

The content of these scheduling aspects seems very simple, but it takes a long time to code and debug to implement. And after one pass, the final result may be just a Docker Swarm.

Container orchestration in Kubernetes

Now we regard the above requirements as our ultimate goal, and see how kubernetes performs container orchestration step by step to solve this problem. I believe that after reading this part of the content, the above problems will be solved.

The core content of container orchestration done by Kubernetes is actually Pod orchestration. How to make these Pods work together is the core of orchestration. In the previous section, we learned together that what kubernetes does is abstract various relationships, which are actually relationships between Pods. Kubernetes abstracts Pod relationships into the following types, and defines relative controllers for these relationships to facilitate orchestration management:

l Collaborative relationship between stateless Pod replicas-Deployment

l Topological relationship between stateful Pod replicas-StatefulSet

l Containerized daemon-DaemonSet

l Offline business-Job and CronJob

These concepts may seem to make you a little bit incomprehensible. In fact, these contents are just different ways of managing Pod by different controllers mentioned above.

Due to space limitations and depth of understanding of this part of the content, here we will only share the most commonly used controller in kubernetes-Deployment in the movable type public cloud version development group.

Deployment controller function introduction

Let's first explain what a controller is: a controller is a program in kubernetes that manages the objects to be arranged. We call the mode of one object managing another object as the controller mode.

All objects to be arranged in kubernetes are managed through the controller mode.

Its core is an infinite loop, in which the state of the current arrangement object is constantly judged, and if the expected state is not met, it is updated. The following pseudo code describes the working principle of a controller:

The function of the Deployment controller is to maintain multiple identical stateless Pod copies running in a prescribed number, and support horizontal expansion and rolling updates.

With this control, in order to achieve our final demand-the movable type grid service in load balancing, this Pod can be managed through Deployment. We can make our Pod always exist in the form of 3 copies in the kubernetes cluster through Deployment.

 
We only need to use Deployment to arrange the Pod we defined, and the number of copies is required to be 3. The Deployment control loop will constantly determine whether the number of copies of our Pod is 3, if not, it will trigger the horizontal expansion function to adjust. Eventually achieve the desired state (number of copies == 3).

Demonstration of the working principle of Deployment

Having introduced so much, we start from an example to show you how Deployment works.

Since the mirror configuration of the movable type grid is too complicated, here we use a multi-copy configuration of Nginx to feel the control result of the Deployment controller.

We can define a deployment that maintains 3 copies of nginx through the following yaml:
In fact, in the initial version of Kubernetes, there was only a controller mode of ReplicaSet, which controlled the multi-copy Pod orchestration logic. Later, rolling update logic appeared. In order to solve the rolling update demand, Deployment was expanded on the basis of ReplicaSet.

apiVersion: apps/v1

kind: Deployment

metadata:

  name: sample-deployment-nginx

spec:

  selector:

    matchLabels:

      app: sample-deployment-nginx

  replicas: 3

  template:

    metadata:

      labels:

        app: sample-deployment-nginx

    spec:

      containers:

      - name: sample-nginx

        image: nginx:1.9.1

        ports:

        - containerPort: 80

Three special fields appear here:

1. selector: selector, similar to the selector in js, its function is to select the specified pod to run, in this instance we specify that all pods of app==sample-deployment-nginx will be deployed by this Deployment

2. Replicas: Specify the number of replicas maintained by this Deployment

3. template: The grammar of template is provided in the controller, which allows us to directly write the Pod information that needs to be arranged in the yaml of the controller

After writing this sample-deployment-nginx.yaml, execute it:

kubectl apply -f sample-deployment-nginx.yaml

The controller of the three copies has been successfully run, use this command to view the results of the run:

kubectl get pods -l app=sample-deployment-nginx

You can see that the 3 copies of Pod have successfully run in kubernetes

If at this time we execute the following command to delete a copy of podname==sample-deployment-nginx-54545f95cd-wtllm

kubectl delete pod sample-deployment-nginx-54545f95cd-wtllm

A new pod can be automatically generated to maintain replicas==3:

Through the above example, we can see that the deployment controller controls the number of replicas, which is actually the ReplicaSet controller controlling the number of replicas. Deployment is the controller of the ReplicaSet controller. This mode of mutual control between multiple layers is also very common in kubernetes. The relationship between them is shown in the following figure:

So far, all the functions of a deployment management pod have been displayed. You can see the delicate relationship between controller management in kubernetes: multiple controllers work together, not only can ensure precise control, but also process blocking can be split. Thereby improving performance.

Introduction of other controllers

When you understand the deployment controller, it is easy to understand the working principles of other controllers.

 

Here we briefly explain to you the control logic of other controllers:

 

l StatefulSet: Controls Pods with topological state or persistent storage. Topological state means that there is a clear sequential generation relationship between Pods. Persistent storage means that when the copy is deleted or modified, the internally stored data will still exist

l DaemonSet: The daemon process controller is a Pod where only one Node (server node) can exist. For example, the log collector of the system should be scheduled in this way

l Job and CronJob: Job is task scheduling. After the scheduling is completed, a Pod will end and no new tasks will be generated. Job is used to maintain various states of a task Pod running normally, restart in abnormal states, etc. The corresponding CronJob is a timed task, and students who have used Quartz must be familiar with it

Summarize

In summary, kubernetes maintains all Pod orchestration work through the above-mentioned various controllers, and it also provides a complete API that allows users to define various Pod orchestration controllers that meet their own needs. But for deployment, this article simply shows some commonly used function points. There are also various functions such as the largest rolling update resource, canary release, and grayscale release that need to be studied in detail.

This chapter uses movable type as an example to introduce the implementation of the k8s container arrangement part. In the next section, we will continue to share with you, in order to achieve another part of this ultimate demand-how to achieve the "human-dog interaction process".