办理Kubernetes集群在坚持一致的可用性和对毛病的耐性方面存在困难。尽管运用副本能够保证存在多个运用程序实例，但并不能保证运用程序运转时的不间断。

译自Kubernetes Pod Disruption Budget: The Practical Guide 2024，作者 Mohamed BEN HASSINE 。

这便是Pod Disruption Budget（Pod中止预算，PDB）变得至关重要的当地。PDB是Kubernetes内的一个功能，经过对运用程序能够处理的中止数量拟定规则，有助于坚持运用程序的稳定性。

本文深入探讨了PDB的具体内容，包含其界说、怎么创立、最佳运用事例以及其重要性的根本原因。

Pod中止指的是当Pod被有意地从节点中删去或驱赶时产生的情况。这可能出于各种原因，包含：

  • 节点保护（如操作系统晋级或硬件晋级）。
  • Kubernetes集群晋级。
  • 自动缩放。
  • 由于节点资源束缚而从头调度Pod。

在Kubernetes中，有两种类型的中止：

  • 自愿中止：这些是能够控制和方案的中止。估计它们将恪守您界说的Pod Disruption Budget（PDB）。
  • 非自愿中止：这些是无法预测或控制的意外中止，例如节点上的硬件毛病或内核溃散。重要的是要注意，这些类型的中止不会恪守PDB设置的束缚。

什么是“Pod Disruption Budget”？

现在咱们已经了解了Pod中止是什么，让咱们深入探讨一下旨在协助咱们办理它的东西。简略来说，Pod Disruption Budget（PDB）使您能够控制应在任何给定时刻可拜访的副本数。在为运用程序装备PDB时，您能够指定以下内容之一：

  • Pod有必要一直可用的最小副本数（称为最小可用）。
  • 可用的副本数的最大数量（称为最大不可用）。

在实践操作中，这意味着，例如，假如您的运用程序有5个副本，而且您设置了一个PDB，要求最少可用的副本数为2个，则只要有两个副本正常运转，PDB就不会影响您的运用程序。

可是，假如副本数少于2个，某些Kubernetes操作将被暂停。例如，假如由于缩容进程导致副本少于2个，那么您的集群的缩容将被暂停。

运用“Pod Disruption Budget”的要求？

为了运用Pod Disruption Budget（PDB），要求很简略：

  • Kubernetes版别：保证您的Kubernetes版别为1.21或更高。
  • Pod符号：要创立和运用PDB，您需求指定应该收效的Pods。因而，相应地符号您的Pods，以便简略地辨认应该运用PDB的Pods。此符号有助于精确运用Pod Disruption Budget。

怎么创立Pod Disruption Budget？

咱们将讨论创立Pod Disruption Budget（PDB）目标的各种办法。

Kubectl Create

要快速将Pod Disruption Budget（PDB）运用于特定作业负载，请履行以下kubectl指令：

kubectl create poddisruptionbudget my-app-pdb --min-available=1 
--selector=app=my-super-app

让咱们分解一下：

  • poddisruptionbudget：这是咱们要创立的Kubernetes API资源类型，代表“Pod Disruption Budget”资源。或者，您能够运用简称“pdb”。
  • my-app-pdb：这是专门为运用程序“super-critical-app”创立的PDB资源的称号。
  • –min-available=1：此标志保证咱们的运用程序一直可用的最小副本数为1个，设置中止的阈值。
  • –selector=app=my-super-app：此标志用于指定应该运用PDB的Pods。在本例中，它指定了PDB适用于具有标签“app=super-critical-app”的Pods。

YAML界说

另一种创立Pod Disruption Budget（PDB）目标的办法是运用YAML文件界说其装备。

让咱们看一个在前一节中讨论的相同PDB的示例，特别是利用minAvailable参数。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: my-super-app

履行kubectl apply -f <YAML_FILE>将生成相同的Pod Disruption Budget（PDB）。现在，让咱们探讨运用maxUnavailable参数的示例。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  maxUnavailable: 0
  selector:
    matchLabels:
      app: my-super-app

Helm Chart

以下是怎么在Helm Chart中界说PDB的示例：

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
 name: "{{ .Release.Name }}-pdb"
spec:
 minAvailable: 2
 selector:
 matchLabels:
 app: "{{ .Release.Name }}"

在此示例中，Pod Disruption Budget（PDB）被装备为在自愿中止期间坚持两个符号为app: {{ .Release.Name }}的Pods的最小数量。

当履行可能使运用程序不可用的操作时，Kubernetes尽力恪守PDB原则。例如，它将尝试以防止违背PDB的方式将Pods分配给节点。

重要的是要认识到，PDB不能保证可用Pod的数量或百分比坚持恒定。在产生意外中止或集群资源不足以在节点毛病后调度新的Pod时，可用Pod的计数可能会低于指定的阈值。

将PDB集成到您的Helm Chart中时，承认选择器字段中的标签与您打算保护的Pods的标签对齐至关重要。

验证PDB已创立并运用

让咱们首先列出咱们的Pod Disruption Budget（PDB）目标。咱们希望看到一个，特别是在前面的部分中创立的那一个，称号为“app-pdb”。

$ kubectl get pdb
NAME        MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
my-app-pdb         1              0                      0

现在的装备规则最少1个副本。鉴于咱们运用默认设置1个副本，因而最大可答应的不可用性限制为1（任何更多，运用程序将停止运转）。

怎么测验Kubernetes PDB？

要真实掌握Pod Disruption Budgets（PDB）的有效性，最具见地的办法是在各种场景下活跃测验它，其间其作用是保护运用程序不会少于指定数量的副本。

Kubernetes节点排空

咱们将首先履行节点排空，不仅仅是任何节点，而是特别是咱们的运用程序副本当前正在运转的节点。节点排空触及在将节点符号为“cordoned”后从头定位所有Pod，表明该节点上不能再调度新的Pod。

假定咱们履行了指令

kubectl get po -o wide | grep -i my-super-app

咱们确认节点称号为“teckbootcamps-node”，让咱们继续排空该节点。

$ kubectl drain teckbootcamps-node --ignore-daemonsets
node/teckbootcamps-node cordoned

这是一个活跃的开始。开始，咱们观察到咱们的节点已被关闭，表明不会将新的作业负载分配给它。让咱们继续查看后续输出以获取更多见地。

evicting pod default/last-app
evicting pod default/my-super-app
evicting pod default/funny-app

风趣。值得注意的是，节点上的所有Pod都被组织进行驱赶。可是，重要的是不要误以为这表明了PDB无法正常作业。

这只是对其预期操作的通知。让咱们继续查看接下来产生的事情。

evicting pod default/my-super-app
error when evicting pods/"my-super-app" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod default/jkog-cc8457d4-pkhzs
error when evicting pods/"my-super-app" -n "default" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.

PDB来拯救！ Kubernetes在驱赶目标Pod（咱们最近创立的PDB中指定的Pod）时遇到了障碍。

它评估装备的PDB并推断出，分散此Pod将导致可用的Pod数量从1削减到0，低于minAvailable=1界说的阈值。

Kubernetes节点池晋级

让咱们在不同的作业流程中测验PDB-具体来说，在Google云平台（GCP）上的GKE集群中晋级节点池，而且节点池只有一个节点和最小可用设置为1。通常，在这样的进程中，将节点符号为关闭以防止在其上调度新的作业负载。

随后，运用排空操作以将作业负载转移到具有更新的Kubernetes版别的新节点。在理论上，PDB应该介入，由于此场景意味着将Pod从一个节点驱赶到另一个节点时副本数削减为0。让咱们在这种情况下查看其性能。

运用gcloud CLI

gcloud container clusters upgrade CLUSTER_NAME --node-pool=NODE_POOL_NAME --cluster-version VERSION

结果怎么？没有晋级！好吧，不完满是。开始，您的作业负载不会转移到新节点，实践上依然作为旧节点上的唯一占用者（假定其他作业负载没有PDB）。可是，请注意您从GCP收到的这条风趣的音讯。

Pod Disruption Budget（PDB）是保证运用程序继续运转的最佳解决方案吗？

简而言之，不是。Pod Disruption Budget（PDB）并非是保证运用程序不间断运转的一劳永逸的解决方案。从技术上讲，它并不是绝对牢靠的，有时需求额定的办法来保证运用程序的接连和正确运转。让咱们探讨一些比如。

考虑一个简略的情形：您有一个名为“my-cool-app”的Pod，有一个副本，而且运用了PDB，其间minAvailable=1，表明应一直有一个运转中的副本，不答应对Pod进行中止。

现在，假如您运转kubectl delete po my-cool-app，您认为会产生什么？假如您的答案是“它会被删去”，那么您是正确的。PDB不会阻挠Pod被删去，由于这种直接删去被视为办理员建议的办理操作，而不是由Kubernetes服务自己办理。因而，在办理员直接删去Pod时，PDB不会产生影响。

Kubernetes PDB的缺陷

旨在保证运用程序继续运转的PDB可能会阻碍某些操作。例如，假如您尝试排空一个节点，PDB可能会阻挠该操作，导致节点上的运用程序无法被驱赶，由于受到了PDB的限制。尽管PDB的意图是坚持运用程序的不间断运转，但假如方案不妥，它可能会干扰现有的流程。

尽管PDB并不彻底阻挠某些操作，但它可能会引进推迟。考虑一下在GCP的GKE节点池中晋级Kubernetes版别的示例。开始，PDB可能会推迟节点排空，但终究，该操作会进行，尽管推迟了一个小时。因而，尽管PDB不会阻挠运用程序的停机，但它的确推迟了节点池晋级进程。

PDB的影响还延伸到集群的减缩能力。假如不同的运用程序在两个节点上运转，而且Kubernetes能够将它们合并到单个节点以进行减缩，PDB将阻挠此操作以防止中止。但是，这种保护是以保护运用程序牢靠性而产生更高的集群费用为价值的。

定论

总归，咱们探讨了“Pod中止”的概念及其对应的“Pod中止预算”（PDB）。咱们讨论了实施PDB的先决条件，并深入探讨了创立它的各种办法，包含运用kubectl create、YAML界说和Helm Chart。还介绍了验证进程，以保证成功创立和运用PDB。

然后，咱们继续在实践场景中测验PDB，例如Kubernetes节点排空和节点池晋级。尽管PDB是保护运用程序可用性的宝贵东西，但重要的是要认识到，它可能不是接连运转的终究解决方案，而且咱们强调了在Kubernetes环境中运用时可能遇到的一些问题。

本文在云云众生（yylives.cc/）首发，欢迎大家拜访。