Cloud platform container team 360 cloud computing
Heroine declaration
When using the rolling update of kubernetes, you may often encounter the situation of "too fast and unstable" or "too slow and poor experience". This article will introduce the characteristics of kubernetes rolling update control rate.
PS: rich first-line technology, a wide range of forms, all in " 3 60 cloud computing " point of concern Oh!
1
meaning
During the rolling update of the service, the purpose of the deployment controller is to reduce the number of copies of the old version (old_rs) to 0 and increase the number of copies of the new version (new_rs) to the expected value (replicas). When you use it, it is usually easy to overlook the characteristics of controlling the rate. The following are the two parameters provided by kubernetes:
1. maxUnavailable: Compared with the number of copies expected to be ready, the maximum ratio (or maximum) of the number of unavailable copies. The smaller the value, the more stable the service and the smoother the update;
2. maxSurge: the number of copies expected to be ready , Exceeding the maximum ratio (or maximum value) of the expected number of copies, the larger the value, the faster the copy update speed.
2
Ranges
Numerical value
1. maxUnavailable: [0, number of copies] maxSurge: [0, number of copies]
2. maxSurge: [0, number of copies]
Note: Both cannot be 0 at the same time.
proportion
1. maxUnavailable: [0%, 100%] Round down, for example, 10 copies, 5% == 0.5, but the calculation is based on 0;
2. maxSurge: [0%, 100%] rounded up, such as 10 copies, if 5% == 0.5, but the calculation is based on 1;
Note: Both cannot be 0 at the same time.
Recommended configuration
1. maxUnavailable == 0
2. maxSurge == 1
This is the default configuration provided to users in our production environment. That is, the smoothest principle of "one up and down, first up and down": after a new version of pod is ready (combined with readiness), the old version of pod will be destroyed. The applicable scenario of this configuration is smooth update and stable service, but it also has the disadvantage that it is "too slow".
3
Custom strategy
When the deployment controller adjusts the number of replicasets, it strictly controls the release rhythm through the following formula. Therefore, if you need to publish quickly, you can adjust these two values according to the actual situation:
(Number of target copies-maxUnavailable) <= number of actual Ready copies online <= (number of target copies + maxSurge)
Example: If the number of copies is expected to be 10, it is expected that at least 80% of the copies can work stably, so: maxUnavailable = 2, maxSurge = 2 (customizable, it is recommended to be consistent with maxUnavailable)
8 <= Actual number of Ready copies online <= 12
In this way, during the update process, the number of pods that can normally provide services online will always remain within this range.
4
to sum up
This article explains the most overlooked "update rate control in rolling update strategy" features of kubernetes: maxUnavailable and maxSurge, I hope it will be helpful to you when you release the version.
Subsequent articles will bring about the principle of deployment controller controlling rolling updates under multiple versions (replicaset), and analyze its corresponding source code implementation logic.