在Kubernetes中部署高可用应用程序的实践

[[432705]]

真正的生产型应用会涉及多个容器。这些容器必须跨多个服务器主机进行部署。容器安全性需要多层部署，因此可能会比较复杂。但 Kubernetes 有助于解决这一问题。

Kubernetes 可以提供所需的编排和管理功能，以便您针对这些工作负载大规模部署容器。借助 Kubernetes 编排功能，您可以构建跨多个容器的应用服务、跨集群调度、扩展这些容器，并长期持续管理这些容器的健康状况。有了 Kubernetes，您便可切实采取一些措施来提高 IT 安全性。

高可用性(High Availability，HA)是指应用系统无中断运行的能力，通常可通过提高该系统的容错能力来实现。一般情况下，通过设置 replicas 给应用创建多个副本，可以适当提高应用容错能力，但这并不意味着应用就此实现高可用性。

众所周知，在Kubernetes环境中部署一个可用的应用程序是一件轻而易举的事。但另外一方面，如果要部署一个可容错，高可靠且易用的应用程序则不可避免地会遇到很多问题。在本文中，我们将讨论在Kubernetes中部署高可用应用程序并以简洁的方式给大家展示，本文也会重点介绍在Kubernetes部署高可用应用所需要注意的原则以及相应的方案。

请注意，我们不会使用任何现有的部署方案。我们也不会固定特定的CD解决方案，我们将省略模板生成 Kubernetes 清单的问题。在本文中，我们只讨论部署到集群时 Kubernetes 清单的最终内容，其它的部分本文不作过多的讨论。

一、副本数量

通常情况下，至少需要两个副本才能保证应用程序的最低高可用。但是，您可能会问，为什么单个副本无法做到高可用?问题在于 Kubernetes 中的许多实体(Node、Pod、ReplicaSet ，Deployment等)都是非持久化的，即在某些条件下，它们可能会被自动删除或者重新被创建。因此，Kubernetes 集群本身以及在其中运行的应用服务都必须要考虑到这一点。

例如，当使用autoscaler服务缩减您的节点数量时，其中一些节点将会被删除，包括在该节点上运行的 Pod。如果您的应用只有一个实例且在运行删除的节点上，此时，您可能会发现您的应用会变的不可用，尽管这时间通常是比较短的，因为对应的Pod会在新的节点上重新被创建。

一般来说，如果你只有一个应用程序副本，它的任何异常停服都会导致停机。换句话说，您必须为正在运行的应用程序保持至少两个副本，从而防止单点故障。

副本越多，在某些副本发生故障的情况下，您的应用程序的计算能力下降的幅度也就越小。例如，假设您有两个副本，其中一个由于节点上的网络问题而失败。应用程序可以处理的负载将减半(只有两个副本中的一个可用)。当然，新的副本会被调度到新的节点上，应用的负载能力会完全恢复。但在那之前，增加负载可能会导致服务中断，这就是为什么您必须保留一些副本。

上述建议与未使用 HorizontalPodAutoscaler 的情况相关。对于有多个副本的应用程序，最好的替代方法是配置 HorizontalPodAutoscaler 并让它管理副本的数量。本文的最后会详细描述HorizontalPodAutoscaler。

二、更新策略

Deployment 的默认更新策略需要减少旧+新的 ReplicaSet Pod 的数量，其Ready状态为更新前数量的 75%。因此，在更新过程中，应用程序的计算能力可能会下降到正常水平的 75%，这可能会导致部分故障(应用程序性能下降)。

该strategy.RollingUpdate.maxUnavailable参数允许您配置更新期间可能变得不可用的Pod的最大百分比。因此，要么确保您的应用程序在 25% 的Pod不可用的情况下也能顺利运行，要么降低该maxUnavailable参数。请注意，该maxUnavailable参数已四舍五入。

默认更新策略 ( RollingUpdate)有一个小技巧：应用程序在滚动更新过程中，多副本策略依然有效，新旧版本会同时存在，一直到所有的应用都更新完毕。但是，如果由于某种原因无法并行运行不同的副本和不同版本的应用程序，那么您可以使用strategy.type: Recreate参数。在Recreate策略下，所有现有Pod在创建新Pod之前都会被杀死。这会导致短暂的停机时间。

其他部署策略(蓝绿、金丝雀等)通常可以为 RollingUpdate 策略提供更好的替代方案。但是，我们没有在本文中考虑它们，因为它们的实现取决于用于部署应用程序的软件。

三、跨节点的统一副本分布

Kubernetes 的设计理念为假设节点不可靠，节点越多，发生软硬件故障导致节点不可用的几率就越高。所以我们通常需要给应用部署多个副本，并根据实际情况调整 replicas 的值。该值如果为1 ，就必然存在单点故障。该值如果大于1但所有副本都调度到同一个节点，仍将无法避免单点故障。

为了避免单点故障，我们需要有合理的副本数量，还需要让不同副本调度到不同的节点。为此，您可以指示调度程序避免在同一节点上启动同一 Deployment 的多个 Pod：

affinity: 
  PodAntiAffinity: 
    preferredDuringSchedulingIgnoredDuringExecution: 
    - PodAffinityTerm: 
        labelSelector: 
          matchLabels: 
            app: testapp 
        topologyKey: kubernetes.io/hostname 

最好使用preferredDuringSchedulingaffinity而不是requiredDuringScheduling。如果新Pod所需的节点数大于可用节点数，后者可能会导致无法启动新 Pod。尽管如此，requiredDuringScheduling当提前知道节点和应用程序副本的数量并且您需要确保两个Pod不会在同一个节点上结束时，亲和性也就会派上用场。

四、优先级

priorityClassName代表您的Pod优先级。调度器使用它来决定首先调度哪些 Pod，如果节点上没有剩余Pod空间，应该首先驱逐哪些 Pod。

您将需要添加多个PriorityClass(https://kubernetes.io/docs/concepts/configuration/Pod-priority-preemption/#priorityclass)类型资源并使用priorityClassName。以下是如何PriorityClasses变化的示例：

• Cluster. Priority > 10000：集群关键组件，例如 kube-apiserver。
• Daemonsets. Priority: 10000：通常不建议将 DaemonSet Pods 从集群节点中驱逐，并替换为普通应用程序。
• Production-high. Priority: 9000：有状态的应用程序。
• Production-medium. Priority: 8000：无状态应用程序。
• Production-low. Priority: 7000：不太重要的应用程序。
• Default. Priority: 0：非生产应用程序。

设置优先级将帮助您避免关键组件的突然被驱逐。此外，如果缺乏节点资源，关键应用程序将驱逐不太重要的应用程序。

五、停止容器中的进程

STOPSIGNAL中指定的信号(通常为TERM信号)被发送到进程以停止它。但是，某些应用程序无法正确处理它并且无法正常停服。对于在 Kubernetes 中运行的应用程序也是如此。

例如下面描述，为了正确关闭 nginx，你需要一个preStop这样的钩子：

lifecycle: 
preStop: 
  exec: 
    command: 
    - /bin/sh 
    - -ec 
    - | 
      sleep 3 
      nginx -s quit 

上述的简要说明：

1. sleep 3 可防止因删除端点而导致的竞争状况。
2. nginx -s quit正确关闭nginx。镜像中不需要配置此行，因为 STOPSIGNAL: SIGQUIT参数默认设置在镜像中。

STOPSIGNAL的处理方式依赖于应用程序本身。实际上，对于大多数应用程序，您必须通过谷歌搜索或者其它途径来获取处理STOPSIGNAL的方式。如果信号处理不当，preStop钩子可以帮助您解决问题。另一种选择是用应用程序能够正确处理的信号(并允许它正常关闭)从而来替换STOPSIGNAL。

terminationGracePeriodSeconds是关闭应用程序的另一个重要参数。它指定应用程序正常关闭的时间段。如果应用程序未在此时间范围内终止(默认为 30 秒)，它将收到一个KILL信号。因此，如果您认为运行preStop钩子和/或关闭应用程序STOPSIGNAL可能需要超过 30 秒，您将需要增加 terminateGracePeriodSeconds 参数。例如，如果来自 Web 服务客户端的某些请求需要很长时间才能完成(比如涉及下载大文件的请求)，您可能需要增加它。

值得注意的是，preStop hook 有一个锁定机制，即只有在preStop hook 运行完毕后才能发送STOPSIGNAL信号。同时，在preStop钩子执行期间，terminationGracePeriodSeconds倒计时继续进行。所有由钩子引起的进程以及容器中运行的进程都将在TerminationSeconds结束后被终止。

此外，某些应用程序具有特定设置，用于设置应用程序必须终止的截止日期(例如，在Sidekiq 中的--timeout 选项)。因此，您必须确保如果应用程序有此配置，则它的值略应该低于terminationGracePeriodSeconds。

六、预留资源

调度器使用 Pod的resources.requests来决定将Pod调度在哪个节点上。例如，无法在没有足够空闲(即非请求)资源来满足Pod资源请求的节点上调度Pod。另一方面，resources.limits允许您限制严重超过其各自请求的Pod的资源消耗。

一个很好的方式是设置limits等于 requests。将limits设置为远高于requests可能会导致某些节点的Pod无法获取请求的资源的情况。这可能会导致节点(甚至节点本身)上的其他应用程序出现故障。Kubernetes 根据其资源方案为每个Pod分配一个 QoS 类。然后，K8s 使用 QoS 类来决定应该从节点中驱逐哪些 Pod。

因此，您必须同时为 CPU 和内存设置requests 和 limits。如果Linux 内核版本早于 5.4(https://engineering.indeedblog.com/blog/2019/12/cpu-throttling-regression-fix/)。在某些情况下，您唯一可以省略的是 CPU 限制(在 EL7/CentOS7 的情况下，如果要支持limits，则内核版本必须大于 3.10.0-1062.8.1.el7)。

此外，某些应用程序的内存消耗往往以无限的方式增长。一个很好的例子是用于缓存的 Redis 或基本上“独立”运行的应用程序。为了限制它们对节点上其他应用程序的影响，您可以(并且应该)为要消耗的内存量设置限制。

唯一的问题是，当应用程序达到此限制时应用程序将会被KILL。应用程序无法预测/处理此信号，这可能会阻止它们正常关闭。这就是为什么除了 Kubernetes 限制之外，我们强烈建议使用专门针对于应用程序本身的机制来限制内存消耗，使其不会超过(或接近)在 Pod的limits.memory参数中设置的数值。

这是一个Redis配置案例，可以帮助您解决这个问题：

maxmemory 500mb   # if the amount of data exceeds 500 MB... 
maxmemory-policy allkeys-lru   # ...Redis would delete rarely used keys 

至于 Sidekiq，你可以使用 Sidekiq worker killer(https://github.com/klaxit/sidekiq-worker-killer):

require 'sidekiq/worker_killer' 
Sidekiq.configure_server do |config| 
config.server_middleware do |chain| 
  # Terminate Sidekiq correctly when it consumes 500 MB 
  chain.add Sidekiq::WorkerKiller, max_rss: 500 
end 
end 

很明显，在所有这些情况下，limits.memory需要高于触发上述机制的阈值。

七、探针

在 Kubernetes 中，探针(健康检查)用于确定是否可以将流量切换到应用程序(readiness probes)以及应用程序是否需要重新启动(liveness probes)。它们在更新部署和启动新Pod方面发挥着重要作用。

首先，我们想为所有探头类型提供一个建议：为timeoutSeconds参数设置一个较高的值 。一秒的默认值太低了，它将对 readiness Probe 和 liveness probes 产生严重影响。

如果timeoutSeconds太低，应用程序响应时间的增加(由于服务负载均衡，所有Pod通常同时发生)可能会导致这些Pod从负载均衡中删除(在就绪探测失败的情况下)，或者，更糟糕的是，在级联容器重新启动时(在活动探测失败的情况下)。

7.1. 活性探针(liveness probes)

在实践中，活性探针的使用并不像您想象的那样广泛。它的目的是在应用程序被冻结时重新启动容器。然而，在现实生活中，应用程序出现死锁是一个意外情况，而不是常规的现象。如果应用程序出于某种原因导致这种异常的现象(例如，它在数据库断开后无法恢复与数据库的连接)，您必须在应用程序中修复它，而不是“增加”基于 liveness probes 的解决方法。

虽然您可以使用 liveness probes 来检查这些状态，但我们建议默认情况下不使用 liveness Probe或仅执行一些基本的存活的探测，例如探测 TCP 连接(记住设置大一点的超时值)。这样，应用程序将重新启动以响应明显的死锁，而不会进入不停的重新启动的死循环(即重新启动它也无济于事)。

不合理的 liveness probes 配置引起的风险是非常严重的。在最常见的情况下， liveness probes 失败是由于应用程序负载增加(它根本无法在 timeout 参数指定的时间内完成)或由于当前正在检查(直接或间接)的外部依赖项的状态。

在后一种情况下，所有容器都将重新启动。

在最好的情况下，这不会导致任何结果，但在最坏的情况下，这将使应用程序完全不可用，也可能是长期不可用。如果大多数Pod的容器在短时间内重新启动，可能会导致应用程序长期完全不可用(如果它有大量副本)。一些容器可能比其他容器更快地变为 READY，并且整个负载将分布在这个有限数量的运行容器上。这最终会导致 liveness probes 超时，也将触发更多的重启。

另外，如果应用程序对已建立的连接数有限制并且已达到该限制，请确保liveness probes不会停止响应。通常，您必须为liveness probes指定一个单独的应用程序线程/进程来避免此类问题。例如，如果应用程序有11个线程(每个客户端一个线程)，则可以将客户端数量限制为10个，以确保liveness probes有一个空闲线程可用。

另外，当然，不要向 liveness Probe 添加任何外部依赖项检查。

7.2. 就绪探针(Readiness probe)

事实证明，readinessProbe 的设计并不是很成功。readinessProbe 结合了两个不同的功能：

• 它会在容器启动期间找出应用程序是否可用;
• 它检查容器成功启动后应用程序是否仍然可用。

在实践中，绝大多数情况下都需要第一个功能，而第二个功能的使用频率仅与 liveness Probe 一样。配置不当的 readiness Probe 可能会导致类似于 liveness Probe 的问题。在最坏的情况下，它们最终还可能导致应用程序长期不可用。

当 readiness Probe 失败时，Pod 停止接收流量。在大多数情况下，这种行为没什么用，因为流量通常或多或少地在 Pod 之间均匀分布。因此，一般来说，readiness Probe 要么在任何地方都有效，要么不能同时在大量 Pod 上工作。在某些情况下，此类行为可能有用。但是，根据我的经验，这也主要是在某些特殊情况下才有用。

尽管如此，readiness Probe 还具有另一个关键功能：它有助于确定新创建的容器何时可以处理流量，以免将负载转发到尚未准备好的应用程序。这个 readiness Probe 功能在任何时候都是必要的。

换句话说，readiness Probe的一个功能需求量很大，而另一个功能根本不需要。startup Probe的引入解决了这一难题。它最早出现在Kubernetes 1.16中，在v1.18中成为beta版，在v1.20中保持稳定。因此，最好使用readiness Probe检查应用程序在Kubernetes 1.18以下版本中是否已就绪，而在Kubernetes 1.18及以上版本中是否已就绪则推荐使用startup Probe。同样，如果在应用程序启动后需要停止单个Pod的流量，可以使用Kubernetes 1.18+中的readiness Probe。

7.3. 启动探针

startup Probe 检查容器中的应用程序是否准备就绪。然后它将当前 Pod 标记为准备好接收流量或继续更新/重新启动部署。与 readiness Probe 不同，startup Probe 在容器启动后停止工作。

我们不建议使用 startup Probe 来检查外部依赖：它的失败会触发容器重启，这最终可能导致 Pod 处于CrashLoopBackOff状态。在这种状态下，尝试重新启动失败的容器之间的延迟可能高达五分钟。这可能会导致不必要的停机时间，因为尽管应用程序已准备好重新启动，但容器会继续等待，直到因CrashLoopBackOff而尝试重新启动的时间段结束。

如果您的应用程序接收流量并且您的 Kubernetes 版本为 1.18 或更高版本，则您应该使用 startup Probe。

另请注意，增加failureThreshold配置而不是设置initialDelaySeconds是配置探针的首选方法。这将使容器尽快可用。

八、检查外部依赖

如您所知，readiness Probe 通常用于检查外部依赖项(例如数据库)。虽然这种方法理应存在，但建议您将检查外部依赖项的方法与检查 Pod 中的应用程序是否满负荷运行(并切断向其发送流量)的方法分开也是个好主意)。

您可以使用initContainers在运行主容器的 startupProbe/readinessProbe 之前检查外部依赖项。很明显，在这种情况下，您将不再需要使用 readiness Probe 检查外部依赖项。initContainers不需要更改应用程序代码。您不需要嵌入额外的工具来使用它们来检查应用程序容器中的外部依赖项。通常，它们相当容易实现：

initContainers: 
  - name: wait-postgres 
    image: postgres:12.1-alpine 
    command: 
    - sh 
    - -ec 
    - | 
      until (pg_isready -h example.org -p 5432 -U postgres); do 
        sleep 1 
      done 
    resources: 
      requests: 
        cpu: 50m 
        memory: 50Mi 
      limits: 
        cpu: 50m 
        memory: 50Mi 
  - name: wait-redis 
    image: redis:6.0.10-alpine3.13 
    command: 
    - sh 
    - -ec 
    - | 
      until (redis-cli -u redis://redis:6379/0 ping); do 
        sleep 1 
      done 
    resources: 
      requests: 
        cpu: 50m 
        memory: 50Mi 
      limits: 
        cpu: 50m 
        memory: 50Mi 

九、完整示例

下面是无状态应用程序的生产级部署的完整示例，其中包含上面提供的所有建议。可以作为大家生成的参考。

您将需要 Kubernetes 1.18 或更高版本以及内核版本为 5.4 或更高版本的基于 Ubuntu/Debian 的Kubernetes节点。

apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: testapp 
spec: 
replicas: 10 
selector: 
  matchLabels: 
    app: testapp 
template: 
  metadata: 
    labels: 
      app: testapp 
  spec: 
    affinity: 
      PodAntiAffinity: 
        preferredDuringSchedulingIgnoredDuringExecution: 
        - PodAffinityTerm: 
            labelSelector: 
              matchLabels: 
                app: testapp 
            topologyKey: kubernetes.io/hostname 
    priorityClassName: production-medium 
    terminationGracePeriodSeconds: 40 
    initContainers: 
    - name: wait-postgres 
      image: postgres:12.1-alpine 
      command: 
      - sh 
      - -ec 
      - | 
        until (pg_isready -h example.org -p 5432 -U postgres); do 
          sleep 1 
        done 
      resources: 
        requests: 
          cpu: 50m 
          memory: 50Mi 
        limits: 
          cpu: 50m 
          memory: 50Mi 
    containers: 
    - name: backend 
      image: my-app-image:1.11.1 
      command: 
      - run 
      - app 
      - --trigger-graceful-shutdown-if-memory-usage-is-higher-than 
      - 450Mi 
      - --timeout-seconds-for-graceful-shutdown 
      - 35s 
      startupProbe: 
        httpGet: 
          path: /simple-startup-check-no-external-dependencies 
          port: 80 
        timeoutSeconds: 7 
        failureThreshold: 12 
      lifecycle: 
        preStop: 
          exec: 
            ["sh", "-ec", "#command to shutdown gracefully if needed"] 
      resources: 
        requests: 
          cpu: 200m 
          memory: 500Mi 
        limits: 
          cpu: 200m 
          memory: 500Mi 

十、PodDisruptionBudget

PodDisruptionBudget(PDB：https://kubernetes.io/docs/concepts/workloads/Pods/disruptions/#Pod-disruption-budgets)机制是在生产环境中运行的应用程序的必备工具。它为您提供了一种方法，可以指定同时不可用的应用程序Pod数量的最大限制。在上文中，我们讨论了一些有助于避免潜在风险情况的方法：运行多个应用程序副本，指定PodAntiAffinity(以防止多个Pod被分配到同一节点)，等等。

但是，您可能会遇到多个 K8s 节点同时不可用的情况。例如，假设您决定将实例节点切换升级到更高配置的的实例节点。除此之外可能还有其他原因，本文不做更详细的描述。最终的问题都是多个节点同时被删除。你可能会认为，Kubernetes里的一切都是昙花一现的!哪怕节点异常或被删除，节点上面的Pod 将会被自动重建到其他节点上，因此，这又会有什么关系呢?好吧，让我们来继续往下看看。

假设应用程序有三个副本。负载在它们之间均匀分布，而 Pod 则分布在节点之间。在这种情况下，即使其中一个副本出现故障，应用程序也将继续运行。然而，两个副本的故障则会导致服务整体降级：一个单独的 Pod 根本无法单独处理整个负载。客户端将开始收到 5XX 错误。(当然，您可以在 nginx 容器中设置速率限制;在这种情况下，错误将是429 Too Many Requests。不过，服务仍然会降级)。

这就是 PodDisruptionBudget 可以提供帮助的地方。我们来看看它的配置清单：

apiVersion: policy/v1beta1 
kind: PodDisruptionBudget 
metadata: 
name: app-pdb 
spec: 
maxUnavailable: 1 
selector: 
  matchLabels: 
    app: app 

上述的配置清单非常简单；你可能熟悉它的大部分配置，maxUnavailable是其中最有趣的。此字段描述可同时不可用的最大 Pod 数。这可以是数字也可以是百分比。

假设为应用程序配置了 PDB。如果出于某种原因，两个或多个节点开始驱逐应用程序 Pod，会发生什么?上述 PDB 一次只允许驱逐一个 Pod。因此，第二个节点会等到副本数量恢复到驱逐前的水平，然后才会驱逐第二个副本。

作为替代方案，您还可以设置minAvailable参数。例如：

apiVersion: policy/v1beta1 
kind: PodDisruptionBudget 
metadata: 
name: app-pdb 
spec: 
minAvailable: 80% 
selector: 
  matchLabels: 
    app: app 

此参数可确保集群中至少有 80% 的副本始终可用。因此，如有必要，只能驱逐 20% 的副本。minAvailable可以是绝对数或百分比。

但有一个问题：集群中必须有足够的节点满足PodAntiAffinity条件。否则，您可能会遇到副本被逐出的情况，但由于缺少合适的节点，调度程序无法重新部署它。因此，排空一个节点将需要很长时间才能完成，并且会为您提供两个应用程序副本而不是三个。当然，你可以使用用命令kubectl describe来查看一个一致在等待中的Pod，看看发生了什么事情，并解决问题。但是，最好还是尽量去避免这种情况发生。

总而言之，请始终为系统的关键组件配置 PDB。

十一、HorizontalPodAutoscaler

让我们考虑另一种情况：如果应用程序的意外负载明显高于平时，会发生什么情况?是的，您可以手动扩展集群，但这不是我们推荐使用的方法。

这就是HorizontalPodAutoscaler(HPA，https://kubernetes.io/docs/tasks/run-application/horizontal-Pod-autoscale/)的用武之地。借助 HPA，您可以选择一个指标并将其用作触发器，根据指标的值自动向上/向下扩展集群。想象一下，在一个安静的夜晚，您的集群突然因流量大幅上升而爆炸，例如，Reddit 用户发现了您的服务，CPU 负载(或其他一些 Pod 指标)增加，达到阈值，然后 HPA 开始发挥作用。它扩展了集群，从而在大量 Pod 之间均匀分配负载。

也正是多亏了这一点，所有传入的请求都被成功处理。同样重要的是，在负载恢复到平均水平后，HPA 会缩小集群以降低基础设施成本。这听起来很不错，不是吗?

让我们看看 HPA 是如何计算要添加的副本数量的。这是官方文档中提供的公式：

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] 

现在假设：

• 当前副本数为3;
• 当前度量值为 100;
• 度量阈值为 60。

在这种情况下，结果则为3 * ( 100 / 60 )，即“大约”5 个副本(HPA 会将结果向上舍入)。因此，应用程序将获得额外的另外两个副本。当然，HPA操作还会继续：如果负载减少，HPA 将继续计算所需的副本数(使用上面的公式)来缩小集群。

另外，还有一个是我们最关心的部分。你应该使用什么指标?首先想到的是主要指标，例如 CPU 或内存利用率。如果您的 CPU 和内存消耗与负载成正比，这将起作用。但是如果 Pod 处理不同的请求呢?有些请求需要较大的 CPU 周期，有些可能会消耗大量内存，还有一些只需要最少的资源。

例如，让我们看一看RabbitMQ队列和处理它的实例。假设队列中有十条消息。监控显示消息正在稳定且定期地退出队列(按照RabbitMQ的术语)。也就是说，我们觉得队列中平均有10条消息是可以的。但是负载突然增加，队列增加到100条消息。然而，worker的CPU和内存消耗保持不变：他们稳定地处理队列，在队列中留下大约80-90条消息。

但是如果我们使用一个自定义指标来描述队列中的消息数量呢?让我们按如下方式配置我们的自定义指标：

• 当前副本数为3;
• 当前度量值为 80;
• 度量阈值为 15。

因此，3 * ( 80 / 15 ) = 16。在这种情况下，HPA 可以将 worker 的数量增加到 16，并且它们会快速处理队列中的所有消息(此时 HPA 将再次减少它们的数量)。但是，必须准备好所有必需的基础架构以容纳此数量的 Pod。也就是说，它们必须适合现有节点，或者在使用Cluster Autoscaler(https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)的情况下，必须由基础设施供应商(云提供商)提供新节点。换句话说，我们又回到规划集群资源了。

现在让我们来看看一些清单：

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
name: php-apache 
spec: 
scaleTargetRef: 
  apiVersion: apps/v1 
  kind: Deployment 
  name: php-apache 
minReplicas: 1 
maxReplicas: 10 
targetCPUUtilizationPercentage: 50 

这个很简单。一旦 CPU 负载达到 50%，HPA 就会开始将副本数量扩展到最多 10 个。

下面是一个比较有趣的案例：

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
name: worker 
spec: 
scaleTargetRef: 
  apiVersion: apps/v1 
  kind: Deployment 
  name: worker 
minReplicas: 1 
maxReplicas: 10 
metrics: 
- type: External 
  external: 
    metric: 
      name: queue_messages 
    target: 
      type: AverageValue 
      averageValue: 15 

请注意，在此示例中，HPA 使用自定义指标(https://kubernetes.io/docs/tasks/run-application/horizontal-Pod-autoscale/#support-for-custom-metrics)。它将根据队列的大小(queue_messages指标)做出扩展决策。鉴于队列中的平均消息数为 10，我们将阈值设置为 15。这样可以更准确地管理副本数。如您所见，与基于 CPU 的指标相比，自定义指标可实现更准确的集群自动缩放。

附加的功能：

HPA 配置选项是多样化。例如，您可以组合不同的指标。在下面的清单中，同时使用CPU 利用率和队列大小来触发扩展决策。

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
name: worker 
spec: 
scaleTargetRef: 
  apiVersion: apps/v1 
  kind: Deployment 
  name: worker 
minReplicas: 1 
maxReplicas: 10 
metrics: 
- type: Resource 
  resource: 
    name: cpu 
    target: 
      type: Utilization 
      averageUtilization: 50 
- type: External 
  external: 
    metric: 
      name: queue_messages 
    target: 
      type: AverageValue 
      averageValue: 15 

这种情况下，HPA又该采用什么计算算法?好吧，它使用计算出的最高副本数，而不考虑所利用的指标如何。例如，如果基于 CPU 指标的值显示需要添加 5 个副本，而基于队列大小的指标值仅给出 3 个 Pod，则 HPA 将使用较大的值并添加 5 个 Pod。

随着Kubernetes 1.18的发布，你现在有能力来定义scaleUp和scaleDown方案(https://kubernetes.io/docs/tasks/run-application/horizontal-Pod-autoscale/#support-for-configurable-scaling-behavior)。例如：

behavior: 
scaleDown: 
  stabilizationWindowSeconds: 60 
  policies: 
  - type: Percent 
    value: 5 
    periodSeconds: 20 
  - type: Pods 
    value: 5 
    periodSeconds: 60 
  selectPolicy: Min 
scaleUp: 
  stabilizationWindowSeconds: 0 
  policies: 
  - type: Percent 
    value: 100 
    periodSeconds: 10 

正如您在上面的清单中看到的，它有两个部分。第一个 ( scaleDown) 定义缩小参数，而第二个 ( scaleUp) 用于放大。每个部分都有stabilizationWindowSeconds. 这有助于防止在副本数量持续波动时出现所谓的“抖动”(或不必要的缩放)。这个参数本质上是作为副本数量改变后的超时时间。

现在让我们谈谈这两者的策略。scaleDown策略允许您指定在type: Percent特定时间段内缩减的 Pod 百分比 。如果负载具有周期性现象，您必须做的是降低百分比并增加持续时间。在这种情况下，随着负载的减少，HPA 不会立即杀死大量 Pod(根据其公式)，而是会逐渐杀死对应的Pod。此外，您可以设置type: Pods在指定时间段内允许 HPA 杀死的最大 Pod 数量 。

注意selectPolicy: Min参数。这意味着 HPA 使用影响最小 Pod 数量的策略。因此，如果百分比值(上例中的 5%)小于数字替代值(上例中的 5 个 Pod)，HPA 将选择百分比值。相反，selectPolicy: Max策略会产生相反的效果。

scaleUp部分中使用了类似的参数。请注意，在大多数情况下，集群必须(几乎)立即扩容，因为即使是轻微的延迟也会影响用户及其体验。因此，在本节中StabilizationWindowsSeconds设置为0。如果负载具有循环模式，HPA可以在必要时将副本计数增加到maxReplicas(如HPA清单中定义的)。我们的策略允许HPA每10秒(periodSeconds:10)向当前运行的副本添加多达100%的副本。

最后，您可以将selectPolicy参数设置Disabled为关闭给定方向的缩放：

behavior: 
scaleDown: 
  selectPolicy: Disabled 

大多数情况下，当 HPA 未按预期工作时，才会使用策略。策略带来了灵活性的同时，也使配置清单更难掌握。

最近，HPA能够跟踪一组 Pod 中单个容器的资源使用情况(在 Kubernetes 1.20 中作为 alpha 功能引入)(https://kubernetes.io/docs/tasks/run-application/horizontal-Pod-autoscale/#container-resource-metrics)。

HPA：总结

让我们以完整的 HPA 清单示例结束本段：

apiVersion: autoscaling/v1 
kind: HorizontalPodAutoscaler 
metadata: 
name: worker 
spec: 
scaleTargetRef: 
  apiVersion: apps/v1 
  kind: Deployment 
  name: worker 
minReplicas: 1 
maxReplicas: 10 
metrics: 
- type: External 
  external: 
    metric: 
      name: queue_messages 
    target: 
      type: AverageValue 
      averageValue: 15 
behavior: 
  scaleDown: 
    stabilizationWindowSeconds: 60 
    policies: 
    - type: Percent 
      value: 5 
      periodSeconds: 20 
    - type: Pods 
      value: 5 
      periodSeconds: 60 
    selectPolicy: Min 
  scaleUp: 
    stabilizationWindowSeconds: 0 
    policies: 
    - type: Percent 
      value: 100 
      periodSeconds: 10 

请注意，此示例仅供参考。您将需要对其进行调整以适应您自己的操作的具体情况。

Horizontal Pod Autoscaler 简介：HPA 非常适合生产环境。但是，在为 HPA 选择指标时，您必须谨慎并尽量多的考虑现状。错误的度量标准或错误的阈值将导致资源浪费(来自不必要的副本)或服务降级(如果副本数量不够)。密切监视应用程序的行为并对其进行测试，直到达到正确的平衡。

十二、VerticalPodAutoscaler

VPA(https://github.com/kubernetes/autoscaler/tree/master/vertical-Pod-autoscaler)分析容器的资源需求并设置(如果启用了相应的模式)它们的限制和请求。

假设您部署了一个新的应用程序版本，其中包含一些新功能，结果发现，比如说，导入的库是一个巨大的资源消耗者，或者代码没有得到很好的优化。换句话说，应用程序资源需求增加了。您在测试期间没有注意到这一点(因为很难像在生产中那样加载应用程序)。

当然，在更新开始之前，相关的请求和限制已经为应用程序设置好了。现在，应用程序达到内存限制，其Pod由于OOM而被杀死。VPA可以防止这种情况!乍一看，VPA看起来是一个很好的工具，应该是被广泛的使用的。但在现实生活中，情况并非是如此，下面会简单说明一下。

主要问题(尚未解决)是Pod需要重新启动才能使资源更改生效。在未来，VPA将在不重启Pod的情况下对其进行修改，但目前，它根本无法做到这一点。但是不用担心。如果您有一个“编写良好”的应用程序，并且随时准备重新部署(例如，它有大量副本;它的PodAntiAffinity、PodDistributionBudget、HorizontalPodAutoscaler都经过仔细配置，等等)，那么这并不是什么大问题。在这种情况下，您(可能)甚至不会注意到VPA活动。

遗憾的是，可能会出现其他不太令人愉快的情况，如：应用程序重新部署得不太好，由于缺少节点，副本的数量受到限制，应用程序作为StatefulSet运行，等等。在最坏的情况下，Pod的资源消耗会因负载增加而增加，HPA开始扩展集群，然后突然，VPA开始修改资源参数并重新启动Pod。因此，高负载分布在其余的Pod中。其中一些可能会崩溃，使事情变得更糟，并导致失败的连锁反应。

这就是为什么深入了解各种 VPA 操作模式很重要。让我们从最简单的开始——“Off模式”。

Off模式：

该模式所做的只是计算Pod的资源消耗并提出建议。我们在大多数情况下都使用这种模式(我们建议使用这种模式)。但首先，让我们看几个例子。

一些基本清单如下：

apiVersion: autoscaling.k8s.io/v1 
kind: VerticalPodAutoscaler 
metadata: 
name: my-app-vpa 
spec: 
targetRef: 
  apiVersion: "apps/v1" 
  kind: Deployment 
  name: my-app 
updatePolicy:  
  updateMode: "Recreate" 
  containerPolicies: 
    - containerName: "*" 
      minAllowed: 
        cpu: 100m 
        memory: 250Mi 
      maxAllowed: 
        cpu: 1 
        memory: 500Mi 
      controlledResources: ["cpu", "memory"] 
      controlledValues: RequestsAndLimits 

我们不会详细介绍此清单的参数：文章(https://povilasv.me/vertical-Pod-autoscaling-the-definitive-guide/)详细描述了 VPA 的功能和细节。简而言之，我们指定 VPA 目标 ( targetRef) 并选择更新策略。

此外，我们指定了 VPA 可以使用的资源的上限和下限。主要关注updateMode部分。在“重新创建”或“自动”模式下，VPA 将重新创建 Pod ，因此需要考虑由此带来的短暂停服风险(直到上述用于 Pod的 资源参数更新的补丁可用)。由于我们不想要它，我们使用“off”模式：

apiVersion: autoscaling.k8s.io/v1 
kind: VerticalPodAutoscaler 
metadata: 
name: my-app-vpa 
spec: 
targetRef: 
  apiVersion: "apps/v1" 
  kind: Deployment 
  name: my-app 
updatePolicy:  
  updateMode: "Off"   # !!! 
resourcePolicy: 
  containerPolicies: 
    - containerName: "*" 
      controlledResources: ["cpu", "memory"] 

VPA 开始收集指标。您可以使用kubectl describe vpa命令查看建议(只需让 VPA 运行几分钟即可)：

Recommendation: 
  Container Recommendations: 
    Container Name: nginx 
    Lower Bound: 
      Cpu:     25m 
      Memory: 52428800 
    Target: 
      Cpu:     25m 
      Memory: 52428800 
    Uncapped Target: 
      Cpu:     25m 
      Memory: 52428800 
    Upper Bound: 
      Cpu:     25m 
      Memory: 52428800 

运行几天(一周、一个月等)后，VPA 建议将更加准确。然后是在应用程序清单中调整限制的最佳时机。这样，您可以避免由于缺乏资源而导致的 OOM 终止并节省基础设施(如果初始请求/限制太高)。

现在，让我们谈谈使用 VPA 的一些细节。

其他 VPA 模式：

请注意，在“Initial”模式下，VPA 在 Pod 启动时分配资源，以后不再更改它们。因此，如果过去一周的负载相对较低，VPA 将为新创建的 Pod 设置较低的请求/限制。如果负载突然增加，可能会导致问题，因为请求/限制将远低于此类负载所需的数量。如果您的负载均匀分布并以线性方式增长，则此模式可能会派上用场。

在“Auto”模式下，VPA 重新创建 Pod。因此，应用程序必须正确处理重新启动。如果它不能正常关闭(即通过正确关闭现有连接等)，您很可能会捕获一些可避免的 5XX 错误。很少建议使用带有 StatefulSet 的 Auto 模式：想象一下 VPA 试图将 PostgreSQL 资源添加到生产中……

至于开发环境，您可以自由试验以找到您可以接受的(稍后)在生产中使用的资源级别。假设您想在“Initial”模式下使用 VPA，并且我们在Redis集群中使用maxmemory参数 。您很可能需要更改它以根据您的需要进行调整。问题是 Redis 不关心 cgroups 级别的限制。

换句话说，如果您的 Pod 的内存上限为 1GB，那么maxmemory 设置的是2GB ，您将面临很大的风险。但是你怎么能设置maxmemory成和limit一样呢?嗯，有办法!您可以使用 VPA 推荐的值：

apiVersion: apps/v1 
kind: Deployment 
metadata: 
name: redis 
labels: 
  app: redis 
spec: 
replicas: 1 
selector: 
  matchLabels: 
    app: redis 
template: 
  metadata: 
    labels: 
      app: redis 
  spec: 
    containers: 
    - name: redis 
      image: redis:6.2.1 
      ports: 
      - containerPort: 6379 
      resources: 
          requests: 
            memory: "100Mi" 
            cpu: "256m" 
          limits: 
            memory: "100Mi" 
            cpu: "256m" 
      env: 
        - name: MY_MEM_REQUEST 
          valueFrom: 
            resourceFieldRef: 
              containerName: app 
              resource: requests.memory 
        - name: MY_MEM_LIMIT 
          valueFrom: 
            resourceFieldRef: 
              containerName: app 
              resource: limits.memory 

您可以使用环境变量来获取内存限制(并从应用程序需求中减去 10%)并将结果值设置为maxmemory。您可能需要对sed用于处理 Redis 配置的 init 容器做一些事情，因为默认的 Redis 容器映像不支持maxmemory使用环境变量进行传递。尽管如此，这个解决方案还是很实用的。

最后，我想将您的注意力转移到 VPA 一次性驱逐所有 DaemonSet Pod 的事实。我们目前正在开发修复此问题的补丁(https://github.com/kubernetes/kubernetes/pull/98307)。

最终的 VPA 建议：

“OFF”模式适用于大多数情况。您可以在开发环境中尝试“Auto”和“Initial”模式。

只有在您已经积累了大量的经验并对其进行了彻底测试的情况下，才能在生产中使用VPA。此外，你必须清楚地了解你在做什么以及为什么要这样做。

与此同时，我们热切期待 Pod 资源的热(免重启)更新功能。

请注意，同时使用 HPA 和 VPA 存在一些限制。例如，如果基于 CPU 或基于内存的指标用作触发器，则 VPA 不应与 HPA 一起使用。原因是当达到阈值时，VPA 会增加资源请求/限制，而 HPA 会添加新副本。

因此，负载将急剧下降，并且该过程将反向进行，从而导致“抖动”。官方文件(https://github.com/kubernetes/autoscaler/tree/master/vertical-Pod-autoscaler#known-limitations)更清楚地说明了现有的限制。。

结论：

我们分享了一些 Kubernetes 高可用部署应用的的一些建议以及相关的案例，这些机制有助于部署高可用性应用程序。我们讨论了调度器操作、更新策略、优先级、探针等方面。最后一部分我们深入讨论了剩下的三个关键主题：PodDisruptionBudget、HorizontalPodAutoscaler 和 VerticalPodAutoscaler。

问题中提到的大量案例都是基于我们生成的真实场景，如使用，请根据自生的环境进行调整。

通过本文，我们也希望读者能够根据自有的环境进行验证，能够一起分享各自的生成经验，能偶一起推进Kubernetes相关技术的发展与进步。再次也感谢读者能够花费大量的时间认真读完本文。

参考文章： 

• https://blog.flant.com/best-practices-for-deploying-highly-available-apps-in-kubernetes-part-1/
• https://blog.flant.com/best-practices-for-deploying-highly-available-apps-in-kubernetes-part-2/
• Migrating your app to Kubernetes: what to do with files?
• ConfigMaps in Kubernetes: how they work and what you should remember
• Best practices for deploying highly available apps in Kubernetes. Part 1
• Comparing Ingress controllers for Kubernetes
• How we enjoyed upgrading a bunch of Kubernetes clusters from v1.16 to v1.19
• Best practices for deploying highly available apps in Kubernetes. Part 2