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

What is the implementation principle of kubernetes interrupt budget? I believe that many inexperienced people do not know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

1.1 what exactly is eviction?

The concept of eviction is understood in k8s in two scenarios: the Pod eviction interface on the apiserver side and the eviction manager in kubelet, although both have similar evictPod operations But in essence, it is not a thing at all. The eviction in kubelet will eventually call runtime to kill the running container, while the API on the apiserver side deletes the corresponding Pod directly in the etcd, which is where the apiserver really works. The eviction at the end of this article all refers to the apiserver interface.

1.2 Drain

Drain is a command used to maintain node expansion in K8s. In fact, it is the only command that expels API calls by default in K8s.

1.3 Pod interrupts the budget

The name of the Pod interruption budget is very straightforward, but the introduction is really complicated. In fact, simply speaking, it can be divided into two parts: interruption and budget. The budget is actually very easy to understand, just like everyone usually spends money. The budget here is the same as the budget here, but the budget here is the number of operations you can do. For example, you allow a maximum of 10% of the Pod downtime of a resource. It will calculate how many machines you can interrupt based on your current state and your budget.

So what is an interruption? The answer is to delete the corresponding operation is to delete the corresponding Pod, and to integrate it is to calculate the number of Pod operations you can delete based on your current status.

All right, this is the end of the introduction of the basic concepts, and let's start the exploration of its implementation.

two。 Core implementation of 2.1 PDB calculation data

We mentioned above that the essence of PDB is to calculate the number of deletions allowed, so what data is needed to do this kind of calculation? First we need a PDB (budget), and then we need the status of the current Pod (via selector). Is that enough? The answer is definitely not. What is missing? That is, the total we mentioned above, that is, how many are expected in the current cluster of the Pod? how to get it? In fact, this corresponds to the corresponding upper-level resources, such as Deployment, ReplicaSet, StatefulSet and so on. We need the number of Pod expected by the upper-level resources, that is, our total.

2.2 Association of upper-level resources

So how do I know exactly who the upper controller of my Pod management is? The answer is actually the Controlled By field, and we can get the corresponding ownerReferences so that we can know who the upper controller is, and then we can take out the desired number from the corresponding controller field.

2.3 effective time of interruption

I feel that the name of interrupt effective time is very appropriate, the official name is DeletionTImeout, because in K8s, the controller and apiserver are two components that can be separated. I mentioned above that the eviction interface will receive the eviction request, so how to pass this expelled Pod to PDB because he has to calculate how much more can be expelled, in addition to the current Pod and the expected number of Pod? It is also certainly necessary to know the number of people who can continue to be interrupted (those that are being expelled).

If it takes a long time for the PDB to receive this message because of the instability of the cluster, in fact, the corresponding request may have been invalidated a long time ago, and the corresponding expelled Pod is still taken into account when it is not actually expelled, which may affect the subsequent expulsion operation. Therefore, in order to solve this problem of delay and asynchrony, there is an interruption valid time, which is 2 minutes by default. It will be deleted automatically after expiration, and the Pod will be skipped when calculating.

2.4 revelation of the overall realization

The overall implementation of control is divided into the following major steps: 1. The user defines the resources to be protected by the PDB 2.controller-aware resources and then calculates the data corresponding to the PDB. After the 3.eviction interface receives the eviction request, it detects whether the PDB allows. If it is allowed to update the interrupted Pod to the DisruptedPods field of the PDB, after the 4.PDB senses the update, the update PDB is recalculated, so that the eviction can be used again and again after receiving the eviction request.

After reading the above, have you mastered the principle of kubernetes interrupting budget? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.