Introduction to cloud native technology kubernetes (K8S)

Today we will look at the introduction of Kubernetes technology. Recently, I watched Teacher Zhang Lei’s in-depth presentation on Kubernetes technology on Geek Time. It was very well presented. Students who are interested can go and listen to it. It is very helpful for understanding Kubernetes technology. Here I will share my learning notes according to my own progress.

Today we are standing at a higher angle, and there will be more conceptual things.

01 What is Kubernetes?

I used to think this question was easy to answer, until I continued to understand Kubernetes and went deeper and deeper, I found that this question is difficult to answer comprehensively.

To understand this problem, first you have to know what a container is? In the previous article, we said that a container is a special process, which is actually a special process isolation environment built by three technologies: Namespace, Cgroup, and rootfs. The main purpose of this isolated environment is to run our own applications.

For cloud vendors, if they can run the Docker images submitted by users in the container environment of their own platform and manage them well, then this cloud platform will have commercial value. In fact, this is indeed achieved.

However, if you want to gain user recognition, it is not just about supporting one container or one user's Docker image, but more about supporting countless developers and a large container cluster so that your platform can be recognized by the entire cloud-native ecosystem. Based on this reality, it is not difficult to find that whoever can better organize, schedule, orchestrate, and standardize the management of container clusters will be favored in the container field.

Here, I marked two words in red, namely scheduling and choreography. It is necessary to explain these two words:

Scheduling: placing a container on the best node to run according to certain rules

Orchestration: Fully automatically handles the relationships between containers according to the user's wishes and the rules of the entire system

In this context, Docker's native Compose+Swarm combination and Google's Kubernetes project came into being. Why did Kubernetes win in the end? Let’s take a look at it slowly.

The theoretical basis of the Kubernetes project is more advanced than its engineering practice. The Kubernetes project originated from Borg, a core system of Google's infrastructure. Compared with other container orchestration projects, it embodies a series of "advancedness" and "completeness", and these features have become the core value on which the Kubernetes project relies.

The advent of Kubernetes has solved the bottlenecks in container orchestration, scheduling, and cluster management. It has also solved a pain point for users: I have a container image of an application. Please help me run this application on a cluster. However, this is not enough to replace the Compose+Swarm architecture, because Docker's native Compose+Swarm architecture can also solve the operation of containers and basic operation and maintenance management functions.

What makes Kubernetes even more valuable is that it was not designed around the specific container Docker from the very beginning. It only regards Docker as an underlying container implementation. The problem it focuses on solving is that there are actually various relationships between tasks running on a large scale. The handling of these relationships is the most difficult part of task orchestration and system management.

There are many types of relationships between these tasks, for example, the relationship between a web application and a MySQL database, the relationship between a load proxy and backend services, and so on.

Traditional virtual machines handle this type of tasks by usually deploying them together because TCP or HTTP requests will occur between tasks. However, after the emergence of container technology, each task can be encapsulated in different containers through mirroring. They do not interfere with each other, have their own resource configuration, and can also be scheduled on different machines by the cluster. as follows:

02 The difference between Kubernetes and Compost+Swarm

This kind of relationship processing between tasks is also the most obvious difference between the Kubernetes project and the Compost+Swarm architecture.

Taking the web application and MySQL services as an example, in the Compost+Swarm architecture, a "link" will be defined between the two services, and the Docker project will be responsible for maintaining this "link". Docker will inject the IP and port of the DB container into the container of this web application as environment variables for use by the application process. When the connection information of the DB container changes, the environment variables will be updated.

The Compost+Swarm design pattern can better support the connection between web applications and MySQL services, but in the future there may be connections between more types of tasks, and this simple ability to handle dependencies will definitely encounter bottlenecks.

The main design idea of ​​the Kubernetes project is to define the various relationships between tasks in a unified way from a more macro perspective, and leave room for supporting more types of relationships in the future.

For example, Kubernetes classifies the mutual calls between containers to distinguish which interactions are frequent TCP interactions, which interactions are merely disk file interactions, and so on. For these tasks that require interaction, the conventional practice is to deploy various tasks on the same machine and communicate through Localhost. Kubernetes introduces the concept of Service, which allows two originally interdependent services to be deployed on different machines. Behind each Service are several Pods. The function of the Service is to provide a fixed proxy entry for the Pod, and the distribution of the Pod is completely random.

In this way, for the Web application Pod, all it needs to care about is the Service information of the database Pod. It is not difficult to imagine that the automatic update and maintenance of the IP address, port and other information of the Pod that the Service backend actually proxies is the responsibility of the Kubernetes project.

03 Summary

Today, we started with the most basic concept of container and put forward the background of k8s. We also extended it to Pod through the "close collaboration" between web application and MySQL service. With Pod, we hope to start multiple application instances at a time, so we need Deployment, a multi-instance manager of Pod (which will be discussed later); and with such a group of identical Pods, we need to access it in a load-balanced manner through a fixed IP address and port, so we have Service. If the web application needs an account and password to access MySQL, we will introduce Secret... Finally, you will see the following picture:

We will analyze the specific content later. . .

I have said so much mainly to express that the Kubernetes project is not like other projects, which create an instruction for each management function and then implement the logic in the project.
In contrast, in the Kubernetes project, the approach we recommend is:
1. First, describe the application you are trying to manage through an "orchestration object", such as Pod, Job, CronJob, etc.
2. Then, define some "service objects" for it, such as Service, Secret, Horizontal Pod Autoscaler, etc. These objects will be responsible for specific platform-level functions.
This method of usage is the so-called "declarative API". The "orchestration objects" and "service objects" corresponding to this API are both API objects in the Kubernetes project.
This is the core design concept of Kubernetes.

That’s all for today.

The above is the detailed introduction of cloud native technology kubernetes (K8S). For more information about cloud native technology kubernetes (K8S), please pay attention to other related articles on 123WORDPRESS.COM!