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

This article mainly explains "using Kubernetes to achieve a variety of applications", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "using Kubernetes to achieve a variety of applications" bar!

This lesson will lead you to learn the use of probes and Deployment. Through practice and learning, we can understand how Kubernetes can achieve high availability of applications.

The course is mainly divided into the following four parts:

Part one: probe

Part two: the use of Deployment

Part III: Demo

Part IV: summary

01

Kubernets probe

When you use kubernetes, have you ever encountered a vicious cycle in which Pod dies soon after startup and then restarts? How does Kubernetes detect if pod is still alive? Although the container has been started, how does Kubernetes know if the process of the container is ready to provide services? The answer is: probe

Probe type

LivenessProbe

Introduction: LivenessProbe, also known as survival probe, is mainly used to detect whether the container is still running. Kubelet uses a survival probe to know when to restart the container. For example, a survival probe can catch a deadlock (the application is running, but cannot continue with the following steps). Restarting the container in this case helps make the application more available in the event of a problem.

Purpose: Kubernetes can use the survival probe to check whether the container is still running. If the probe fails, Kubernetes will assume that the container is no longer running and will restart the container.

Detection method:

1. HTTP:kubelet executes the HTTP GET request to the specified path of the IP address of the container. Judge whether the detection is successful according to the return code

2. TCP socket: try to establish a TCP connection with the specified port of the container. If the connection is successful, the probe is successful.

3. Exec: execute any command in the container to check the exit status code. If the return value is 0, the probe is successful.

Survival probe yaml file:

Green is the http probe. Here, port 8080 of the container is requested. If the returned value is 2xx or 3xx, the probe is successful.

The red is the exec probe, where a cat command is executed.

The blue one is tcp probe. The function is to try to establish a TCP connection with port 8080.

ReadnessProbe:

Introduction: ready probe. Used to detect whether the Pod is ready. Because part of the Pod will have a long initialization time when it starts, the ready probe can be used to detect whether the Pod has been initialized. Kubelet uses the ready probe to know when the container is ready and can begin to accept the request flow, and when all the containers in a Pod are ready, the Pod can be considered ready. One of the uses of this signal is to control which Pod is the back end of the Service. When Pod is not ready, it will be removed from Service's load balancer.

Purpose: the ready probe is called periodically during the container life cycle. Determine whether the Pod accepts the client request. When the container's readiness probe returns successfully, the container is ready to accept the request.

Detection method:

1.HTTP: execute a HTTP GET request to the specified path to the IP address of the container. Judge whether the detection is successful according to the return code

2.TCP socket: attempts to establish a TCP connection to the specified port of the container. If the connection is successful, the probe is successful.

3.Exec: execute any command in the container to check the exit status code. If the status code is 0, the detection is successful.

Yaml file of the ready probe:

The configuration of ready probe is almost the same as that of survival probe.

It's just a field of readinessProbe.

02

The use of Deployment

ReplicaSet

Introduction: Pod is unreliable, may go down, and can be configured to restart, but if the node where the Pod is located goes down, the Pod will be completely lost, and problems will occur in the production environment. In addition, we generally do not use a single Pod, but many groups of the same Pod to provide services, which will be particularly difficult to maintain manually, especially when the number of clusters is large, so ReplicaSet is introduced here. The purpose of ReplicaSet is to maintain a stable set of Pod replicas that are running at all times. Therefore, it is usually used to ensure the availability of a given number of identical Pod.

How it works: RepicaSet is defined by a set of fields, including a selection operator to identify the collection of available Pod, a numeric value to indicate the number of copies that should be maintained, a Pod template to be used to specify that a new Pod should be created to meet the condition for the number of copies, and so on. Each ReplicaSet achieves the value of its existence by creating and deleting Pod as needed to achieve the desired number of copies. When ReplicaSet needs to create a new Pod, the provided Pod template is used.

How it works: the purpose of ReplicaSet is to maintain a stable set of Pod replicas that are running at all times. Therefore, it is usually used to ensure the availability of a given number of identical Pod.

‍

Each time ReplicaSet monitors the current number of Pod, if the number of Pod exceeds the required number, some of them will be deleted automatically. Otherwise, it will be created automatically and will be created using a template during the creation process.

ReplicaSet creates a new replacement copy of the Pod running on the failed node, which easily scales horizontally with pod.

If you change the tag of a pod, it is possible to detach it from the ReplicaSet to which it belongs

Similarly, if you want to put a Pod in the Replicas Set, you can also add it to the ReplicaSet by modifying the tag.

ReplicaSet yaml example

1.Label Selector: tag selector to determine scope

2.Replicas: number of copies, that is, scope

3.Pod template: pod template

Deployment

A Deployment controller provides declarative update capabilities for Pod and ReplicasSet.

You are responsible for describing the target state in the Deployment, while the Deployment controller changes the actual state to the desired state at a controlled rate. You can define a Deployment to create a new ReplicaSet, or delete an existing Deployment and adopt its resources through the new Deployment.

Deployment yaml example

The Deployment yaml file is very similar to ReplicaSet, except that the strategy field is added. This field is mainly used to describe the upgrade method.

Deployment does not directly manage Pod

When you create a Deployment, the ReplicaSet is created with it. When actually using Deployment, the actual Pod is created and managed by ReplicaSet, not directly by Deployment.

Using Deployment makes it easier to update your application because you can directly define the state that a single Deployment resource needs to achieve and let Kubernetes handle the intermediate state.

Upgrade Deployment

Deployment supports declarative updates, that is, you only need to modify the Pod template in the Deployment resource, and Kubernetes automatically converges the actual system state to the state defined in the resource.

Deployment supports different upgrade strategies, which are mainly divided into RollingUpdate and Recreate modes. This policy is defined in the deployment.spec.strategy field. Details can be obtained using the kubectl explain command.

Deployment Recreate upgrade

The Deployment Recreate upgrade strategy will directly stop the old version of Pod and create new ReplicaSet and Pod. And the traffic is switched. The specific steps are as follows:

The disadvantage is that there is no Pod running for a period of time during the upgrade process, and if there is an external request, the service will be unavailable and a certain amount of traffic will be lost.

Deployment RollingUpdate upgrade

The rolling upgrade method is shown in the figure above:

Kubernetes will create an additional v2 version of pod and replicaSet first. And gradually destroy the v1 version of pod, so as to achieve rolling upgrade

At the same time, we highly recommend that Deployment be used with the ready probe in the production environment. Because by default, requests are accepted on Pod running. But in fact, internal services may not be ready.

So it can be further used with minReadySeconds field, ready probe and other related functions.

03

Course summary

1. The use of probe, ready probe and survival probe. Three detection methods

2. The working principle of ReplicaSet, keeping pod at a certain amount through label.

3. How Deployment works, how to upgrade and how to roll back.

Thank you for your reading, the above is the content of "using Kubernetes to achieve a variety of applications", after the study of this article, I believe you have a deeper understanding of the use of Kubernetes to achieve a variety of applications, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.