Kubernetes-ReplicaSet vs PodDisruption预算 [英] Kubernetes - ReplicaSet vs PodDisruptionBudget

问题描述

我想知道PodDisruptionBudget的附加值是什么.

I was wondering what added value gives the PodDisruptionBudget.

据我了解，PodDisruptionBudget承诺一定数量的节点将始终保留在群集中，同时有2个选项来决定如何:minAvailable/maxUnavailable.

As far as I understand, PodDisruptionBudget promises that a certain amount of nodes will always remain in the cluster while there are 2 options to decide how: minAvailable / maxUnavailable.

现在，当我定义ReplicaSet时，我定义了我想要多少个副本.因此，例如，如果我定义2，则副本数量将不少于2个.那是什么赋予了PodDisruptionBudget?

Now, when I define ReplicaSet I define how many replicas I want. So if for example I define 2, there won't be less than 2 replicas. Then what gives the PodDisruptionBudget?

推荐答案

PodDisruptionBudget 帮助确保 ReplicaSet 无法保证的应用程序零停机.

PodDisruptionBudget helps in ensuring zero downtime for an application which ReplicaSet can't guarantee.

后续帖子解释为示例 PodDisruptionBudget 如何在实现应用程序零停机时间方面很有用:

The following post explains with an example how PodDisruptionBudget can be useful in achieving zero downtime for an application:

引用该帖子，节点升级是正常情况，如以下所述:

Quoting the post, the node upgrade is a normal scenario as described in:

让我们考虑一种情况，我们需要升级节点的版本或经常更新规格.集群缩减规模也是正常情况.在这种情况下，要删除的节点上运行的Pod需要筋疲力尽.

Let’s consider a scenario, we need to upgrade version of node or update the spec often. Cluster downscaling is also a normal condition. In these cases, the pods running on the to-be-deleted nodes needs to be drained.

kubectl排出在要升级的节点之一上执行:

kubectl drain is performed on one of the nodes for the upgrade:

我们需要从池中删除node1，而我们无法通过该操作来删除它立即分离，因为这将导致所有豆荚的终止在那儿运行会降低服务质量.之前的第一步分离节点是使该节点处于非计划状态.

We need to remove node1 from the pool which we cannot do it by detaching instantly as that will lead to termination of all the pods running in there which can get services down. First step before detaching node is to make the node unscheduled.

正在运行 kubectl get pods -w 将显示在节点上运行的pod处于终止状态，这将导致停机:

Running kubectl get pods -w will show the pods running on the node get in termination state which leads to a downtime:

如果您使用kubectl get pods快速检查豆荚，它将立即终止在node1上调度的所有正在运行的Pod.这可能会导致停机！如果您正在运行的Pod数量很少并且所有这些都安排在同一节点上，这将花费一些时间要在其他节点上安排的广告连播.

If you quickly check the pods with kubectl get pods , it will terminate all the running pods instantly which were scheduled on node1 . This could lead a downtime! If you are running few number of pods and all of them are scheduled on same node, it will take some time for the pods to be scheduled on other node.

在这种情况下，具有 minAvailable 的

PodDisruptionBudget 在实现零停机时间方面很有用. Replicaset 将仅确保将 replicas 个广告连播数量在此过程中在其他节点上创建.

PodDisruptionBudget with minAvailable are useful in such scenarios to achieve zero downtime. Replicaset will only ensure that the replicas number of pods will be created on other nodes during the process.

如果您只是一个具有一个副本的 Replicaset ，而未指定 PodDisruptionBudget ，则该Pod将终止，并在其他节点上创建一个新Pod.这是 PDB 提供了优于 Replicaset 的优势.

If you just have a Replicaset with one replica and no PodDisruptionBudget specified, the pod will be terminated and a new pod will be created on other nodes. This is where PDBs provide the added advantage over the Replicaset.

要使PodDisruptionBudget正常工作，必须至少有2个吊舱为标签选择器运行，否则无法耗尽节点宽限期，当宽限时间结束时，它将被强行逐出.

For the PodDisruptionBudget to work, there must be at least 2 pods running for a label selector otherwise, the node cannot be drained gracefully and it will be evicted forcefully when grace time ends.

这篇关于Kubernetes-ReplicaSet vs PodDisruption预算的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！