Today, I will continue to introduce the relevant knowledge of Linux operation and maintenance. The main content of this article is the deployment controller update strategy.
1. Introduction to Deployment update strategy
In the previous Kubernetes Detailed Explanation (22) - Deployment Controller , we introduced the basic knowledge of the Deployment controller and the creation process of the resource list. Today, let's talk about the basics of how the Deployment controller controls Pod updates.
The application update of the ReplicaSet controller needs to be manually divided into multiple steps and completed in sequence, which is cumbersome and error-prone. (In Kubernetes Detailed Explanation (21) - ReplicaSet Controller Practical Application As we mentioned in the article, ReplicaSet will not update the Pod immediately after setting the Pod update, but we need to manually delete the previous Pod before updating the Pod ) and if we use the Deployment controller, when we configure the Pod to update, the Deployment controller will automatically perform the Pod update operation without our manual control, and also allows us to intervene in its update process by setting parameters in advance.
2. Deployment update classification
The Deployment controller supports two update strategies - rollingUpdate and Recreate . The differences between the two update strategies are as follows:
1. Rebuild update.
Rebuilding and updating refers to deleting all existing Pod objects first, and then creating a new version of Pod objects. The biggest drawback of this update method is that during the update process, the running service must be interrupted for a certain period of time. But the point is that in this way of updating, there is no stage where new and old versions of Pods coexist and provide services together. However, compared with its advantages, its disadvantages are particularly obvious. Therefore, in a production environment, we rarely use rebuild update as an update strategy. Mostly rolling updates are used. Next, I will give you a detailed introduction to the rolling update process.
2, rolling update.
While deleting some old versions of Pods, create new versions of Pod resources. The advantage of this update method is that the normal provision of the service can be maintained, and the service operation will not be interrupted. But the problem with this is that there will be a period of time when the new version of the Pod and the old version of the Pod provide services at the same time, and the services received by the client may come from the old version of the Pod or from the new version of the Pod, which will lead to differences in services. In fact, compared with its shortcomings, the advantages of rolling update strategy are more obvious, that is, business continuity is not interrupted , and the coexistence of new and old versions of Pods can make it possible to check the availability of new versions of Pods in advance. found, dealt with in advance. At the same time, the shortcomings of rolling updates can also be solved by means of sub-regional updates. Therefore, our most commonly used update strategy is rolling update, and rolling update is also the default update strategy of the Deployment controller.
The schematic diagram of the deployment rolling update process is as follows:
3. Deployment update control parameters
During the rolling update process of Deployment, we can use two parameters, maxSurge and maxAvailable, to control the rolling update process. These two parameters are generally defined at the same time, and their meanings are as follows:
1. maxSurge
specifies the number or percentage that the actual number of Pods can exceed the expected number of Pods during the update process. The value of this parameter can be 0, a positive integer, or a percentage. For example, if this parameter is set to 2 and the number of pods is set to 3, then the number of pods will be at most 4 during a pod update.
2. maxAvailable
specifies that during the update process, the actual number of Pods must be less than the expected number of Pods or a percentage. The value of this parameter can be 0, a positive integer, or a percentage. For example, if this parameter is set to 2 and the number of pods is set to 3, then the number of pods will be at least 1 during a pod update.
It can be seen from the above explanation that the maxSurge parameter mainly specifies the maximum value of the Pod during the update process to prevent it from occupying a large amount of resources during the update process, while the maxAvailable parameter mainly specifies the minimum value of the Pod during the update process to prevent the Pod update process. The service is abnormal because the number of pods is insufficient.
Originality is not easy, please indicate the source for reprinting: https://blog.csdn.net/weixin_40228200