Shulou(Shulou.com)06/02 Report--

Author | Li Xiang, senior technical expert of Alibaba and one of the 9 TCO of CNCF

What is Kubernetes

Kubernetes, as can be seen from the official website, is an industrial container orchestration platform. The word Kubernetes is Greek, and its Chinese translation is "helmsman" or "pilot". The word "ks", or "K8s", is also seen in some common materials, which is an acronym caused by replacing the eight letters "ubernete" with "8".

Why is Kubernetes named "helmsman"? You can take a look at this picture:

This is a ship carrying a pile of containers, carrying containers on the sea, taking them to where they are supposed to go. We have actually introduced a concept called container,container, which also has another meaning for "container". With this implication, Kubernetes hopes to become a ship carrying containers to help us manage these containers, that is, to manage these containers.

This is why the word Kubernetes was chosen to represent the project. More specifically, Kubernetes is an automated container orchestration platform that is responsible for application deployment, application resilience, and application management, all of which are container-based.

2. Kubernetes has the following core functions: service discovery and load balancing; automatic container packing, which we will also call scheduling, that is, "scheduling". When a container is placed on a certain machine in a cluster, Kubernetes will help us to do storage choreography, so that there can be a connection between the storage declaration cycle and the container life cycle; Kubernetes will help us to do automated container recovery. In a cluster, host problems or OS problems often occur, resulting in the unavailability of the container itself, and Kubernetes will automatically restore these unavailable containers; Kubernetes will help us to do the automatic release and rollback of applications, as well as the management of application-related configuration ciphertext; for job tasks, Kubernetes can perform batch execution In order to make the cluster and the application more flexible, Kubernetes also supports horizontal scaling.

Next, we would like to give you a more realistic introduction to the capabilities of Kubernetes with three examples.

1. Scheduling

Kubernetes can put the container submitted by the user on one of the nodes of the cluster managed by Kubernetes. Kubernetes's scheduler is the component that performs this capability, and it observes the size and specification of the container being scheduled.

For example, the CPU it needs and the memory it needs, and then find a relatively idle machine in the cluster to do a placement, that is, a placement operation. In this example, it may place the red container on a second idle machine to complete a scheduling job.

2. Automatic repair

Kubernetes has a node health check function that monitors all hosts in the cluster. When the host itself fails or the software fails, the node health check will automatically detect it.

Next, Kubernetes will automatically migrate the containers running on these failed nodes to a host that is running healthily, so as to complete an automatic recovery of containers in the cluster.

3. Horizontal telescopic

Kubernetes has the ability to check the business load, and it will monitor the load borne by the business. If the CPU utilization of the service itself is too high, or the response time is too long, it can expand the capacity of the service.

For example, in the following example, when the yellow color is too busy, Kubernetes can change the yellow load from one to three. Next, it can improve the response time by evenly distributing the load that originally hit the first yellow color to the load of three yellow colors through load balancing.

This is a brief introduction to the three core competencies of Kubernetes.

III. The structure of Kubernetes

Kubernetes architecture is a typical two-tier architecture and server-client architecture. Master, as the central management and control node, will make a connection with Node.

All UI, clients, and these components on the user side will only connect with Master. Sending the desired state or commands to Master,Master will send these commands to the corresponding nodes for final execution.

Kubernetes's Master consists of four main components: API Server, Controller, Scheduler, and etcd. As shown in the following figure:

API Server: as the name implies, it is used to handle API operations. All components in Kubernetes are connected to API Server. Generally, components and components are not connected independently and rely on API Server for message transmission. Controller: controller, which is used to manage the cluster state. For example, in the two examples we just mentioned, the first automatically repairs the container and the second automatically expands horizontally, both of which are done by Controller in Kubernetes. Scheduler: it's a scheduler. As its name implies, the "scheduler" is to complete the scheduling operation. In the first example we just introduced, we put the Container submitted by a user to find a suitable node according to the size of the request for CPU and memory. Etcd: is a distributed storage system. The original information needed in API Server is placed in etcd. Etcd itself is a highly available system, which ensures the high availability of Master components of the entire Kubernetes through etcd.

The API Server we just mentioned is a deployment component that can be scaled horizontally in terms of deployment structure. Controller is a deployment component that can be used for hot backup. It has only one active, and its scheduler is also corresponding. Although there is only one active, it can be used for hot backup.

The architecture of Kubernetes: Node

Kubernetes's Node actually runs business loads, and each business load runs in the form of Pod. Wait a minute. I'll introduce the concept of Pod. One or more containers running in a Pod, what really runs these Pod components is called kubelet, the most critical component on Node, which receives the status of the required Pod running through API Server and submits it to the Container Runtime component we draw below.

To create an environment for containers to run on OS, and finally to run containers or Pod, you also need to manage storage and network. Kubernetes will not directly operate on network storage, they will rely on Storage Plugin or network Plugin to operate. Users or cloud vendors will write the corresponding Storage Plugin or Network Plugin to complete storage operations or network operations.

In Kubernetes's own environment, there will also be Kubernetes's Network, which is to provide Service network for networking. (we will also introduce the concept of "service" later. The component that really completes the networking of service is Kube-proxy, which makes use of the ability of iptable to build the Network of Kubernetes, that is, cluster network. These are the four components of Node.

Kubernetes's Node does not interaction directly with user, its interaction only passes through Master. User sends this information to the node through Master. The components we just mentioned are running on every Node of Kubernetes.

Let's take another look at how these components in the Kubernetes architecture interaction each other with an example.

Users can submit a Pod to Kubernetes for deployment through UI or CLI. The Pod request will first be submitted to Kubernetes API Server via CLI or UI. Next, API Server will write this information to its storage system etcd, and then Scheduler will get this information through API Server's watch or notification mechanism: a Pod needs to be scheduled.

At this point, Scheduler will make a scheduling decision based on its memory state, and after completing this scheduling, it will say to API Server report, "OK! this Pod needs to be scheduled to a certain node."

At this time, after API Server receives the operation, it will write the result to etcd again, and then API Server will notify the corresponding node to start the actual execution of Pod. The kubelet of the corresponding node will get this notification, and kubelet will call Container runtime to actually start and configure the container and its running environment, schedule Storage Plugin to configure storage, and network Plugin to configure the network.

In this example, we can see how these components communicate with each other and coordinate to complete a Pod scheduling operation.

Fourth, the core concept of Kubernetes and its core concept of API the first concept: Pod

Pod is a minimum scheduling and resource unit of Kubernetes. Users can produce a Pod through Kubernetes's Pod API and have Kubernetes schedule the Pod, that is, running it on a node managed by Kubernetes. A Pod is simply an abstraction of a set of containers that contains one or more containers.

For example, in the picture below, it contains two containers, each of which can specify the size of the resources it needs. For example, one G per core, or 0.5 core, 0.5 G.

Of course, some other required resources can also be included in this Pod: for example, we see the Volume volume as a storage resource; for example, we need 100 GB storage or another 20GB storage.

In Pod, we can also define how the container needs to run. For example, the Command that runs the container, and the environment variables that run the container, and so on. The Pod abstraction also provides a shared runtime environment for these containers, they share the same network environment, and these containers can be connected directly using localhost. Pod and Pod are separated by isolation from each other.

The second concept: Volume

Volume is the concept of volume, which is used to manage Kubernetes storage, to declare that containers in Pod can access file directories, and a volume can be mounted under the specified path of one or more containers in Pod.

Volume itself is an abstract concept, and a Volume can support a variety of back-end storage. For example, Kubernetes's Volume supports many storage plug-ins, which can support local storage and distributed storage, such as ceph,GlusterFS; it can also support cloud storage, such as cloud disk on Ali Cloud, cloud disk on AWS, cloud disk on Google, and so on.

The third concept: Deployment

Deployment is a higher-level abstraction on the Pod abstraction, which defines the number of copies of a set of Pod and the version of the Pod. Generally speaking, people use the abstraction of Deployment to do the real management of the application, and Pod is the smallest unit that makes up Deployment.

Kubernetes maintains the number of Pod in the Deployment through Controller, the controller we just mentioned, and it also helps Deployment recover failed Pod automatically.

For example, I can define a Deployment that requires two Pod in the Deployment. When one Pod fails, the controller detects that it restores the number of Pod in the Deployment from one to two, and then generates a new Pod. Through the controller, we will also help complete the release strategy. For example, a rolling upgrade, a regenerated upgrade, or a version rollback.

The fourth concept: Service

Service provides stable access addresses for one or more Pod instances.

For example, in the above example, we see that a Deployment may have two or more identical Pod. For an external user, the access to which Pod is actually the same, so it wants to do a load balancer. While doing load balancing, I only want to access a fixed VIP, that is, Virtual IP address. I do not want to know the IP address of each specific Pod.

As we just mentioned, the pod itself may be terminal go, and if one Pod fails, it may be replaced with another new one.

For an external user, a number of specific Pod addresses are provided, and this user has to constantly update the Pod address. When the Pod fails to restart again, we want to have an abstraction that abstracts the access ability of all Pod into an IP address of a third party. The abstraction of the Kubernetes that implements this is called Service.

There are many ways to implement Service. Kubernetes supports Cluster IP, the networking of kuber-proxy mentioned above, and it also supports nodePort, LoadBalancer and other access capabilities.

The fifth concept: Namespace

Namespace is used to do logical isolation within a cluster, including authentication, resource management, and so on. Each resource in Kubernetes, such as Pod, Deployment, and Service just mentioned, belongs to a Namespace. Resources in the same Namespace need to be named uniquely, and resources in different Namespace can be renamed.

A use case of Namespace, for example, in Alibaba, we will have many business units internally. We want to have a view isolation between each business units, and it is also different in authentication and cuda. We will use Namespace to provide each BU with a mechanism for isolation that he sees.

API of Kubernetes

Let's introduce the basics of Kubernetes's API. From the perspective of high-level, Kubernetes API is made up of HTTP+JSON: the way users access it is HTTP, and the content of content in the accessed API is in JSON format.

Kubernetes's kubectl is command tool,Kubernetes UI, or sometimes uses curl to communicate directly with Kubernetes, using the form of HTTP + JSON.

Here's an example: for example, for a resource of this Pod type, its HTTP access path is API, followed by apiVesion: V1, followed by the corresponding Namespaces, and the Pods resource, and finally Podname, which is the name of Pod.

If we submit a Pod or get a Pod, its content content is expressed in JSON or YAML. There is an example of yaml in the figure above, and in this yaml file, the description of Pod resources is also divided into several parts.

The first part, generally speaking, will be API's version. For example, if it is V1 in this example, it will also describe which resource I am working on; for example, if my kind is pod, write the name of the Pod in Metadata; for example, nginx, we will also type some label to it, and we will talk about the concept of label later. In Metadata, annotation is sometimes written, that is, additional user-level descriptions of resources.

The more important part is called Spec,Spec, which is an expected state that we want Pod to achieve. For example, what container needs to be run internally; for example, if there is a nginx container in it, what is its image? What is the port exposed by it?

When we get this resource from Kubernetes API, generally speaking, there is a project under the Spec called status, which expresses the current state of the resource; for example, the status of a Pod may be being scheduled, or it has been running, or it has been terminates, that is, it has been executed.

Just now in API, we talked about an interesting metadata called "label". This label can be a group of KeyValuePair.

For example, in the first pod shown below, label may be a color equal to red, that is, its color is red. Of course, you can also add other label, such as size: big is the size, defined as large, it can be a set of label.

These label can be queried by selector, that is, the selector. This capability is actually very similar to our select statement of type sql, such as select in the three Pod resources in the figure below. Name color equals red, even if its color is red, we can also see that only two of them are selected, because only their label is red, and the color written in the other label is equal to yellow, because its color is not red and will not be selected.

These resources can be filtered through the API layer of label,kubernetes, which is also the default way for kubernetes to express a collection of resources.

For example, the Deployment we just introduced may represent a set of Pod, it is an abstraction of a set of Pod, and a set of Pod is expressed through label selector. Of course, we just talked about a group of Pod corresponding to service, that is, a service corresponds to one or more Pod to uniformly access them. This description is also a group of Pod selected by select through label selector.

So you can see that label is a very core concept of kubernetes API, and we will focus on explaining and introducing the concept of label in the next course, and how to make better use of it.

5. End with a demo

The last part, I would like to end with an example, let you try a kubernetes with me, before trying Kubernetes, I hope you can install Kubernetes on this machine, install a Kubernetes sandbox environment.

There are three main steps to install this sandbox environment:

First, you need to install a virtual machine to start Kubernetes in the virtual machine. We will recommend that you use virtualbox as the running environment for virtual machines.

Install VirtualBox: https://www.virtualbox.org/wiki/Downloads

Second, we need to start Kubernetes,Kubernetes in a virtual machine. There is a very interesting project called minikube, which is an environment for launching a Kubernetes with the smallest local.

Minikube We recommend using the Aliyun version written below. The main difference between it and the official minikube is to replace the dependencies on Google needed in minikube with some images with faster domestic access, so as to facilitate everyone's installation.

Install MiniKube (Chinese version): https://yq.aliyun.com/articles/221687

Finally, after installing virtualbox and minikube, you can start minikube, that is, the following command.

Launch command: minikube start-vm-driver virtualbox

If you are not a Mac operating system, please visit the link below to see how other operating systems install the minikube sandbox environment.

Https://kubernetes.io/docs/tasks/tools/install-minikube/

After you have installed it, I will give you an example to do three things:

Submit a nginx deployment

Kubectl apply-f https://k8s.io/examples/application/deployment.yaml

Upgrade nginx deployment

Kubectl apply-f https://k8s.io/examples/application/deployment-update.yaml

Expand nginx deployment.

Kubectl apply-f https://k8s.io/examples/application/deployment-update.yaml

The first step is to submit a Deployment of nginx, and then make a version upgrade of the Deployment, that is, to change the version of its intermediate Pod. Finally, we will also try to expand the capacity of nginx and scale it horizontally. Let's try these three operations with me.

First, let's take a look at minikube's status, and we can see that both kubelet master and kubectl are configured.

Next, we use kubectl to take a look at the selected status in this cluster, and we can see that the node of this master is already in running status:

Let's take this as the node. Let's try to take a look at the Deployment resource in the cluster:

You can see that there is no Deployment in the cluster, so we can use the semantics of watch to see the changes of the Deployment resource in the cluster.

Let's do the three operations we just wanted: the first one is to create a Deployment. You can see the first figure below, this is an API content, its kind is Deployment,name is nginx-deployment, in the figure its replicas number is 2, its mirror version is 1.7.9.

! [] (https://intranetproxy.alipay.com/skylark/lark/0/2019/png/168324/1564386046039-12c5b5d6-0c39-4029-9fac-a56f95999fc0.png#align=left&display=inline&height=108&originHeight=96&originWidth=149&size=0&status=done&width=167)

Let's go back to kubectl, the commnd, to perform the real operation of this Deployment. We can see a simple operation to get Deployment to keep making copies.

The number of Deployment copies is 2. You can also describe the current Deployment status below. We know that we didn't have this Deployment before, but now let's go to describe this nginx-deployment.

As you can see in the following figure: a nginx-deployment has been generated, its number of replicas is what we want, selector is what we want, and its image version is 1.7.9. You can also see that the version controller deployment-controller is also managing its generation.

Next, to upgrade this Deployment version, first download another yaml file, deployment-update.yaml, and you can see that the version number of the image itself has been upgraded from 1.7.9 to 1.8.

Next, let's re-apply the new deployment-update yaml file.

As you can see, some operations of this Deployment upgrade are shown on the other side of the screen, and eventually its up-to-date value changes from 0 to 2, which means that all containers are the latest version and all Pod are the latest version. We can also discribe to see if all the versions of Pod have been updated, and we can see that the version of this image has really been updated from 1.7.9 to 1.8.

Finally, we can also see that controller performs several new operations, and the controller maintains the entire Deployment and Pod state.

Finally, let's demonstrate how to expand Deployment horizontally and download another yaml file, deployment-scale.yaml, where the number of replicas has been changed from 2 to 4.

Go back to the original window and use kubectl to apply the new deployment-scale.yaml file. On another window, you can see that when we performed the deployment-scale operation, the number of container Pod changed from 2 to 4. Once again, we can describ the deployment in the current cluster, and we can see that the number of replicas has changed from 2 to 4. At the same time, we can also see that controller has done several new operations, and this scale up has been successful.

Finally, let's delete the Deployment we just generated using the delete operation. Kubectl delete deployment, which is also our own deployment name just now, when we delete it, all our operations are done today.

If we re-get the Deployment, it will also show that the resource no longer exists and the cluster is back to its original clean state.

This paper summarizes

In this article, we focus on the core concepts of Kubernetes and the architecture design of Kubernetes. The main contents are as follows:

Kubernetes is an automated container orchestration platform, which is responsible for application deployment, application resilience and application management, all of which are container-based. Kubernetes architecture is a typical two-tier architecture and server-client architecture.

"Alibaba Cloud's native Wechat official account (ID:Alicloudnative) focuses on micro-services, Serverless, containers, Service Mesh and other technology areas, focuses on cloud native popular technology trends, and large-scale cloud native landing practices, and is the technical official account that best understands cloud native developers."

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.