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

This article is about how to arrange and manage the K8s application. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article. Let's take a look at it with the editor.

I. background of demand sources

First of all, let's look at the background. As shown in the following figure: if we directly manage all the Pod in the cluster, applying the Pod of A, B, C is actually scattered in the cluster.

Now there are the following problems:

First of all, how to ensure the number of Pod available in the cluster? That is to say, if we apply A four Pod, if there are some host failures, or some network problems, how can we ensure the number of them available?

How do I update the mirrored version for all Pod? Do we want some Pod to rebuild the new version of Pod?

Then during the update process, how to ensure the availability of the service?

And how to roll back to the previous version quickly if a problem is found during the update process?

Deployment: manage the controller of the deployment release

This brings us to today's topic: Deployment Managing controllers for deployment releases.

We can see that we plan applications A, B, C into different Deployment through Deployment. Each Deployment is actually managed by a group of the same application Pod, this group of Pod we think it is the same copy, so what can Deployment do for us?

First of all, Deployment defines an expected number of Pod, such as application A, and we expect the number of Pod to be four, so that controller will continue to maintain the expected number of Pod. When we have network problems or host problems with Pod, controller can help us recover, that is, the newly expanded corresponding Pod, to ensure that the number of available Pod is the same as the expected number.

Configure the Pod publishing method, that is, controller will update the Pod according to the policy given by the user, and during the update process, you can also set the range of the number of unavailable Pod

If there is a problem during the update process, the so-called "one-click" rollback, that is, you can update all the Pod under Deployment to an old version with a single command or one-line modification.

Second, use case interpretation of Deployment grammar

Let's use a simple use case to interpret how to manipulate Deployment.

You can see the simplest yaml file for Deployment in the image above.

"apiVersion:apps/v1", that is to say, the group to which Deployment currently belongs is apps, and the version is v1. "metadata" is the Deployment meta-information we see, that is, Labels, Selector and Pod.image in the previous review, which are all knowledge points mentioned in previous periods.

As a K8s resource, Deployment has its own metadata meta-information, and the Deployment.name we define here is nginx.Deployment. First of all, there must be a core field in Deployment.spec, namely replicas, where the expected number of Pod is defined as three. Selector is actually a Pod selector, so the Labels of all expanded Pod must match the image.labels on the selector layer, that is, app.nginx.

As mentioned in the Pod template template above, this template actually contains two parts:

One part is the metadata of the expected Pod, which contains labels, that is, a Labels that matches selector.matchLabels.

The second part is a Pod.spec contained in template. Here Pod.spec is actually the Pod.spec it used when Deployment finally created Pod. Here a container.nginx is defined, and its mirror version is nginx:1.7.9.

Here are the new knowledge points encountered:

The first is replicas, which is the expected or final number of states in Deployment.

The second is template, which is a template related to Pod.

View Deployment status

When we create a Deployment, we can see the overall state of the Deployment through kubectl get deployment. As shown in the following figure:

As you can see in the image above:

DESIRED: the expected number of Pod is 3

CURRENT: the current actual number of Pod is 3

UP-TO-DATE: actually the number of Pod that reaches the latest expected version

AVAILABLE: this is actually the number of Pod available during the run. As mentioned later, here AVAILABLE is not simply available, that is, Ready status, it actually contains some Pod that can be used for more than a certain length of time.

The creation time of AGE:deployment, as shown in the figure above, is that Deployment has been created for 80 minutes.

View Pod

Finally we can take a look at Pod. As shown in the following figure:

It is not difficult to see the three Pod,Pod name formats in the picture above.

The first paragraph: nginx-deployment, is actually the middle segment of the Deployment.name; to which the Pod belongs: template-hash, where the three Pod are the same, because all three Pod are actually created in the same template.

The last paragraph is a string of random, and we can see through get.pod that the ownerReferences of Pod, that is, the controller resource to which Pod belongs, is not a Deployment, but a ReplicaSet. The name of this ReplicaSet is actually nginx-deployment plus pod.template-hash, which will be mentioned later. All Pod is created by ReplicaSet, and ReplicaSet corresponds to a specific version of Deployment.template.

Update Mirror

Next we can see how to update the mirrored versions of all its Pod for a given Deployment. Here we can execute a kubectl command:

Kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1

First of all, there is a fixed set image writing after kubectl, which refers to the setting image.

The second is a deployment.v1.apps, which is also written in a fixed way, which is about the type of resource we want to operate. Deployment is the resource name, v1 is the resource version, and apps is the resource group. Here, it can also be abbreviated to deployment or deployment.apps. For example, when written as deployment, the apps group v1 version will be used by default.

The third part is the name of the deployment to be updated, that is, the nginx after our nginx-deployment; actually refers to template, that is, the container.name; in Pod. Here we can notice that there may be multiple container in a Pod, and we specify the container.name of the image we want to update, that is, nginx.

Finally, specify the mirror version that our container expects to update, in this case nginx: 1.9.1. As shown in the following figure: after executing this command, you can see that template.spec in deployment has been updated to nginx: 1.9.1.

Quick rollback

If we encounter problems during the release process, we also support a quick rollback. If executed through kubectl, it is actually the command "kubectl rollout undo" that can be rolled back to the previous version of Deployment; you can specify that it can be rolled back to a specific version by adding "rollout undo" to "to-revision".

DeploymeStatus

Finally, let's take a look at DeploymeStatus. Every resource has its own spec.Status. As you can see here, the three described in deploymentStatus are actually its conversion states, namely, Processing, Complete, and Failed.

Take Processing as an example: Processing means that Deployment is in the process of being expanded and released. For example, deployment in Processing status, all of its replicas and Pod copies are up to date and are available, so that you can enter complete status. If some capacity expansion occurs in complete status, it will also enter the working state of processing processing.

If you encounter some problems in the process: for example, if you failed to pull the image or failed to check readiness probe, you will enter failed status; if some pod readiness probe check failures occur during the running process, that is, complete status, deployment will also enter failed status. After entering the failed state, deployment will not re-enter the failed state unless all points of deployment become available and are the latest version of updated.

3. Operation demonstration Deployment creation and status

Let's demonstrate the operation: connect an Ali Cloud service cluster here. We can see that there are already several node available in the current cluster.

First create the corresponding deployment. You can see that desired, current, up-to-date, and available in deployment have all reached the desired state of availability.

The structure of Deployment

Here we can see that the replicas in spec is three, and the tags defined in selector and template labels are image in app:nginx,spec, which is what we expect from nginx: 1.7.9 available.replicas,readReplicas and updatedReplicas are both three.

Pod statu

We can select another Pod to see the status:

As you can see: the function of ownerReferences in Pod is that the image in ReplicaSet;pod.spec.container is 1.7.9. The Pod is already in Running state, and its conditions.status is "true", indicating that its service is available.

Update and upgrade

Currently there is only the latest version of replicaset, so try to upgrade deployment now.

The command "kubectl set image" is followed by "deployment", followed by deployment.name, and finally specifies the container name and the image version we expect to upgrade.

Next, let's take a look at the update of image in template in deployment to 1.9.1.

At this time, let's get pod to see the status.

Three pod have been upgraded to a new version, and the pod-template-hash in the name of pod has been updated.

You can see that the number of spec and pod for the old version of replicaset is 0, and the number of pod for the new version is 3.

Suppose you update it again, and at this time get.pod can actually see that there are actually two old versions of pod in running and one in deletion, while two new versions of pod, one in running and the other in creating.

At this time, the number of pod available to us, that is, the number of pod in non-deleted state, is actually 4, which has exceeded the number of 3 that replica originally set in deployment. The reason for this is that we have maxavailable and maxsugar operations in deployment, and these two configurations can limit some of our policies during the release process. This issue will be discussed later in architectural design.

Historical version retains revisionHistoryLimit

As you can see in the figure above, our current latest version of replicaset is 3 pod, and there are two historical versions of replicaset, so will there be a situation: as the deployment is constantly updated, this old version of replicaset will accumulate more and more. In fact, deployment provides a mechanism to avoid this problem: in deployment spec, there is a revisionHistoryLimit, its default value is 10, it actually guarantees the number of historical versions of replicaset, we try to change it to 1.

From the second figure above, you can see two replicaset, that is, except for the current version of replicaset, the old version of replicaset actually retains only one.

Roll back

Finally, try to do a rollback. First, let's take a look at replicaset. It is found that the number of replicaset in the old version has increased from 0 to 2, while the number of replicaset in the new version has been reduced from 3 to 1, indicating that it is already doing rollback operations. Then observe that the number of old versions is already 3, that is, the rollback has been successful, while the number of new versions of pod has changed to 0.

Let's take a final look at get pod:

At this point, the three pod.template-hash have been updated to the old version of hash, but in fact all three pod are recreated, not the three pod we created in the previous version. In other words, when we rolled back, we actually created three old versions of pod instead of finding the previous three pod.

IV. Management mode of architecture design

Let's take a look at architectural design. First of all, take a brief look at the management mode: Deployment is only responsible for managing different versions of ReplicaSet, and ReplicaSet manages the specific number of Pod copies, with each ReplicaSet corresponding to a version of Deployment template. As you can see in the above example, each time you modify template, a new ReplicaSet is generated, and the Pod under this ReplicaSet is actually the same version.

As shown in the figure above: Deployment creates ReplicaSet and ReplicaSet creates Pod. Their OwnerRef actually corresponds to the resources of their controllers.

Deployment controller

Let's first take a brief look at the implementation principle of the controller.

First of all, all of our controllers do some Handler and Watch through Event in Informer. In this place, the Deployment controller is actually concerned with the event in Deployment and ReplicaSet, and will be added to the queue after receiving the event. After the Deployment controller is taken out of the queue, its logic will determine whether the Check Paused, this Paused is actually whether the Deployment needs a new release. If the Paused is set to true, it means that the Deployment will only do a quantitative maintenance, not a new release.

As shown in the figure above, you can see that if Check paused is Yes, that is, true, then only Sync replicas can be done. That is to say, synchronize the replicas sync to the corresponding ReplicaSet, and finally Update Deployment status, then the ReplicaSet of the controller is over.

Well, if paused is false, it will do Rollout, that is, update through Create or Rolling, which is also realized by ReplicaSet such as Create/Update/Delete.

ReplicaSet controller

When Deployment allocates ReplicaSet, the ReplicaSet controller itself watch events from Informer, which contain events for ReplicaSet and Pod. Once removed from the queue, the logic of ReplicaSet controller is simple, just managing the number of replicas. In other words, if controller finds that the number of replicas is larger than the number of Pod, it will expand its capacity, and if it finds that the actual number exceeds the expected number, it will delete Pod.

As you can see in the diagram of the Deployment controller above, the Deployment controller actually does more complex things, including version management, and it leaves the quantity maintenance work under each version to ReplicaSet.

Expansion / reduction simulation

Let's take a look at some operational simulations, such as capacity expansion simulation. Here is a Deployment whose number of copies is 2, and the corresponding ReplicaSet has Pod1 and Pod2. At this point, if we modify the Deployment replicas, controller will synchronize the replicas into the current version of ReplicaSet. This ReplicaSet finds that there are currently two Pod, but does not meet the current expectation of three, and a new Pod3 will be created.

Release simulation

Let's simulate the release again, and the release will be a little more complicated. Here you can see the current initial template of Deployment, such as template1. There are three Pod:Pod1,Pod2,Pod3 under the corresponding version of template1 ReplicaSet.

When you modify the image of a container in template, Deployment controller will create a new ReplicaSet corresponding to template2. After it is created, the ReplicaSet will gradually modify the number of two ReplicaSet, for example, it will gradually increase the expected number of replicas in the ReplicaSet2, and gradually reduce the number of Pod in the ReplicaSet1.

So the final result is: the new version of Pod is Pod4, Pod5 and Pod6, the old version of Pod has been deleted, here is the completion of a release.

Rollback simulation

Let's take a look at the rollback simulation. According to the above release simulation, we can see that Pod4, Pod5, and Pod6 have been released. At this point, it is found that there is a problem with the current business version. If you do a rollback, whether you modify template through the rollout command or through rollback, it actually rolls back template to the old version of template1.

At this time, Deployment will re-modify the expected number of Pod in ReplicaSet1, change the expected number to 3, and gradually reduce the number of replica in the new version, that is, ReplicaSet2. The end result is to recreate the Pod from the old version.

As you can see in the figure of releasing the simulation, Pod1, Pod2 and Pod3 are the old versions in the initial version, but Pod7, Pod8 and Pod9 are in fact after the rollback. That is to say, its rollback is not to re-find the previous Pod, but to recreate the Pod that conforms to the old version of template.

Spec field parsing

Finally, let's take a brief look at some field parsing in Deployment. First, take a look at the other spec fields in Deployment:

MinReadySeconds:Deployment will see if Pod is available according to Pod ready, but if we set MinReadySeconds, for example, 30 seconds, then Deployment will definitely wait until Pod ready exceeds 30 seconds before thinking that Pod is available. The prerequisite for Pod available is Pod ready, but the Pod of ready is not necessarily available. It must exceed MinReadySeconds before it can be judged as available.

RevisionHistoryLimit: keep the historical revision, that is, the number of historical ReplicaSet. The default value is 10. It can be set to one or two, and if the rollback is more likely, the number can be set to more than 10

Paused:paused is the logo. Deployment only does quantity maintenance, not new releases. It may be used here in Debug scenarios.

ProgressDeadlineSeconds: as mentioned earlier, when Deployment is expanded or released, its condition will be in a processing state, and processing can set a timeout. If you are still in a processing after the timeout, then controller will assume that the Pod will enter the failed state.

Analysis of upgrade Policy Field

Finally, let's take a look at the upgrade policy field parsing.

Deployment provides two main strategies in RollingUpdate, one is MaxUnavailable and the other is MaxSurge. For the meaning of parsing these two fields, you can take a look at the detailed comment in the figure below, or simply explain it:

MaxUnavailable: the maximum number of Pod that is not available during scrolling

MaxSurge: the maximum number of Pod that exceeds the expected number of replicas during scrolling.

As mentioned above, there may be a situation when a Deployment with a ReplicaSet of 3 is released: both the new version of ReplicaSet and the old version of ReplicaSet may have two replicas, which adds up to four, three more than we expected. This is because our default MaxUnavailable and MaxSurge are both 25%. By default, 25% of the replica may be unavailable during the publishing process of the Deployment, or 25% of the number of replica may be available, up to 125% of the replica.

This can actually be set up according to the actual scenario of the user. For example, when users have enough resources and pay more attention to the availability in the publishing process, you can set a smaller MaxUnavailable and a larger MaxSurge. However, if the user's resources are tight, you can set the MaxSurge to be small, or even set to 0. Note here that MaxSurge and MaxUnavailable cannot be 0 at the same time.

The reason is not difficult to understand. When MaxSurge is 0, Pod must be deleted in order to expand Pod;. If Pod is not deleted, Pod cannot be newly expanded, because the total number of Pod will exceed the expected number. If both are 0, MaxSurge guarantees that there is no new expansion of Pod, and MaxUnavailable cannot guarantee that any Pod in ReplicaSet is available, which will cause problems. So these two values cannot be 0 at the same time. Users can set corresponding and appropriate values according to their actual scenarios.

Here is a brief summary of the main contents of this article:

Deployment is a common Workload in Kubernetes, which supports deployment and management of multiple versions of Pod

Deployment manages multiple versions by creating a ReplicaSet for each version of template, and ReplicaSet maintains a certain number of Pod copies, while Deployment only needs to care about the number of Pod specified in different versions of ReplicaSet.

Therefore, the fundamental principle of Deployment release deployment is that Deployment adjusts the number of final copies in different versions of ReplicaSet to achieve the upgrade and rollback of multiple versions of Pod.

The above is how to arrange and manage the K8s application. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.