超酷个人网站欣赏,阿里云怎样做公司网站,前端网站如何做全景图,哪个小说网站版权做的好在k8s中部署高可用程序实践 1. 多副本部署1.1. 副本数量1.2. 更新策略1.3. 跨节点的统一副本分布1.4. 优先级1.5. 停止容器中的进程1.6. 预留资源 2. 探针2.1. 活性探针#xff08;liveness probes#xff09;2.2. 就绪探针#xff08;Readiness probe#xff09;2.3. 启动… 在k8s中部署高可用程序实践 1. 多副本部署1.1. 副本数量1.2. 更新策略1.3. 跨节点的统一副本分布1.4. 优先级1.5. 停止容器中的进程1.6. 预留资源 2. 探针2.1. 活性探针liveness probes2.2. 就绪探针Readiness probe2.3. 启动探针2.4. 外部依赖检查 3. 负载调整3.1. HPA(HorizontalPodAutoscaler横向资源扩缩容)3.2. VPA(VerticalPodAutoscaler纵向资源扩缩容) 4. 疑问和思考5. 参考文档 Kubernetes 可以提供所需的编排和管理功能以便您针对这些工作负载大规模部署容器。借助 Kubernetes 编排功能您可以构建跨多个容器的应用服务、跨集群调度、扩展这些容器并长期持续管理这些容器的健康状况。有了 Kubernetes您便可切实采取一些措施来提高 IT 安全性。 高可用性High AvailabilityHA是指应用系统无中断运行的能力通常可通过提高该系统的容错能力来实现。一般情况下通过设置 replicas 给应用创建多个副本可以适当提高应用容错能力但这并不意味着应用就此实现高可用性。 众所周知在Kubernetes环境中部署一个可用的应用程序是一件轻而易举的事。但另外一方面如果要部署一个可容错高可靠且易用的应用程序则不可避免地会遇到很多问题。在本文中我们将讨论在Kubernetes中部署高可用应用程序并以简洁的方式给大家展示本文也会重点介绍在Kubernetes部署高可用应用所需要注意的故则以及相应的方案。 1. 多副本部署 1.1. 副本数量 通常情况下至少需要两个副本才能保证应用程序的最低高可用。但是您可能会问为什么单个副本无法做到高可用问题在于 Kubernetes 中的许多实体Node、Pod、ReplicaSet Deployment等都是非持久化的即在某些条件下它们可能会被自动删除或者重新被创建。因此Kubernetes 集群本身以及在其中运行的应用服务都必须要考虑到这一点。 例如当使用autoscaler服务缩减您的节点数量时其中一些节点将会被删除包括在该节点上运行的 Pod。如果您的应用只有一个实例且在运行删除的节点上此时您可能会发现您的应用会变的不可用尽管这时间通常是比较短的因为对应的Pod会在新的节点上重新被创建。 一般来说如果你只有一个应用程序副本它的任何异常停服都会导致停机。换句话说您必须为正在运行的应用程序保持至少两个副本从而防止单点故障。 副本越多在某些副本发生故障的情况下您的应用程序的计算能力下降的幅度也就越小。例如假设您有两个副本其中一个由于节点上的网络问题而失败。应用程序可以处理的负载将减半只有两个副本中的一个可用。当然新的副本会被调度到新的节点上应用的负载能力会完全恢复。但在那之前增加负载可能会导致服务中断这就是为什么您必须保留一些副本。 当然应用层面需要注意在多副本情况下的事务一致性问题。 在k8s环境中各个pod的高可用配置以及相关的资源高利用率治理通常是一个复杂的治理过程并且难度很高 对于有多个副本的应用程序最好的替代方法是配置 HorizontalPodAutoscaler 并让它管理副本的数量。本文的最后会详细描述HorizontalPodAutoscaler。 1.2. 更新策略 Deployment 的默认更新策略需要减少旧新的 ReplicaSet Pod 的数量其Ready状态为更新前数量的 75%。因此在更新过程中应用程序的计算能力可能会下降到正常水平的 75%这可能会导致部分故障应用程序性能下降。 该strategy.RollingUpdate.maxUnavailable参数允许您配置更新期间可能变得不可用的Pod的最大百分比。因此要么确保您的应用程序在 25% 的Pod不可用的情况下也能顺利运行要么降低该maxUnavailable参数。请注意该maxUnavailable参数已四舍五入。 默认更新策略 ( RollingUpdate)有一个小技巧应用程序在滚动更新过程中多副本策略依然有效新旧版本会同时存在一直到所有的应用都更新完毕。但是如果由于某种原因无法并行运行不同的副本和不同版本的应用程序那么您可以使用strategy.type: Recreate参数. 在Recreate策略下所有现有Pod在创建新Pod之前都会被杀死。这会导致短暂的停机时间。 其他部署策略蓝绿、金丝雀等通常可以为 RollingUpdate 策略提供更好的替代方案。但是我们没有在本文中考虑它们因为它们的实现取决于用于部署应用程序的软件。 1.3. 跨节点的统一副本分布 Kubernetes 的设计理念为假设节点不可靠节点越多发生软硬件故障导致节点不可用的几率就越高。所以我们通常需要给应用部署多个副本并根据实际情况调整 replicas 的值。该值如果为1 就必然存在单点故障。该值如果大于1但所有副本都调度到同一个节点仍将无法避免单点故障。 为了避免单点故障我们需要有合理的副本数量还需要让不同副本调度到不同的节点。为此您可以指示调度程序避免在同一节点上启动同一 Deployment 的多个 Pod affinity:PodAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- PodAffinityTerm:labelSelector:matchLabels:app: testapptopologyKey: kubernetes.io/hostname最好使用preferredDuringSchedulingaffinity而不是requiredDuringScheduling. 如果新Pod所需的节点数大于可用节点数后者可能会导致无法启动新 Pod。尽管如此requiredDuringScheduling当提前知道节点和应用程序副本的数量并且您需要确保两个Pod不会在同一个节点上结束时亲和性也就会派上用场。 1.4. 优先级 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非生产应用程序。 设置优先级将帮助您避免关键组件的突然被驱逐。此外如果缺乏节点资源关键应用程序将驱逐不太重要的应用程序。 1.5. 停止容器中的进程 STOPSIGNAL中指定的信号通常为TERM信号被发送到进程以停止它。但是某些应用程序无法正确处理它并且无法正常停服。对于在 Kubernetes 中运行的应用程序也是如此。 例如下面描述为了正确关闭 nginx你需要一个preStop这样的钩子 lifecycle: preStop:exec:command:- /bin/sh- -ec- |sleep 3nginx -s quit上述的简要说明 sleep 3 可防止因删除端点而导致的竞争状况。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。 1.6. 预留资源 调度器使用 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 MBchain.add Sidekiq::WorkerKiller, max_rss: 500 end end很明显在所有这些情况下limits.memory需要高于触发上述机制的阈值。 2. 探针 在 Kubernetes 中探针健康检查用于确定是否可以将流量切换到应用程序readiness probes以及应用程序是否需要重新启动liveness probes。它们在更新部署和启动新Pod方面发挥着重要作用。 首先我们想为所有探头类型提供一个建议为timeoutSeconds参数设置一个较高的值 。一秒的默认值太低了它将对 readiness Probe 和 liveness probes 产生严重影响。 如果timeoutSeconds太低应用程序响应时间的增加由于服务负载均衡所有Pod通常同时发生可能会导致这些Pod从负载均衡中删除在就绪探测失败的情况下或者更糟糕的是在级联容器重新启动时在活动探测失败的情况下。 2.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 添加任何外部依赖项检查。 2.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。 2.3. 启动探针 startup Probe 检查容器中的应用程序是否准备就绪。然后它将当前 Pod 标记为准备好接收流量或继续更新/重新启动部署。与 readiness Probe 不同startup Probe 在容器启动后停止工作。 我们不建议使用 startup Probe 来检查外部依赖它的失败会触发容器重启这最终可能导致 Pod 处于CrashLoopBackOff状态。在这种状态下尝试重新启动失败的容器之间的延迟可能高达五分钟。这可能会导致不必要的停机时间因为尽管应用程序已准备好重新启动但容器会继续等待直到因CrashLoopBackOff而尝试重新启动的时间段结束。 如果您的应用程序接收流量并且您的 Kubernetes 版本为 1.18 或更高版本则您应该使用 startup Probe。 另请注意增加failureThreshold配置而不是设置initialDelaySeconds是配置探针的首选方法。这将使容器尽快可用。 2.4. 外部依赖检查 如您所知readiness Probe 通常用于检查外部依赖项例如数据库。虽然这种方法理应存在但建议您将检查外部依赖项的方法与检查 Pod 中的应用程序是否满负荷运行并切断向其发送流量的方法分开也是个好主意。 您可以使用initContainers在运行主容器的 startupProbe/readinessProbe 之前检查外部依赖项。很明显在这种情况下您将不再需要使用 readiness Probe 检查外部依赖项。initContainers不需要更改应用程序代码。您不需要嵌入额外的工具来使用它们来检查应用程序容器中的外部依赖项。通常它们相当容易实现 initContainers:- name: wait-postgresimage: postgres:12.1-alpinecommand:- sh- -ec- |until (pg_isready -h example.org -p 5432 -U postgres); dosleep 1doneresources:requests:cpu: 50mmemory: 50Milimits:cpu: 50mmemory: 50Mi- name: wait-redisimage: redis:6.0.10-alpine3.13command:- sh- -ec- |until (redis-cli -u redis://redis:6379/0 ping); dosleep 1doneresources:requests:cpu: 50mmemory: 50Milimits:cpu: 50mmemory: 50Mi3. 负载调整 3.1. HPA(HorizontalPodAutoscaler横向资源扩缩容) 让我们考虑一种情况如果应用程序的意外负载明显高于平时会发生什么情况是的您可以手动扩展集群但这不是我们推荐使用的方法。这就是HorizontalPodAutoscalerHPAhttps://kubernetes.io/docs/tasks/run-application/horizontal-Pod-autoscale/的用武之地。 借助 HPA您可以选择一个指标并将其用作触发器根据指标的值自动向上/向下扩展集群。想象一下在一个安静的夜晚您的集群突然因流量大幅上升而爆炸例如Reddit 用户发现了您的服务CPU 负载或其他一些 Pod 指标增加达到阈值然后 HPA 开始发挥作用。它扩展了集群从而在大量 Pod 之间均匀分配负载。 也正是多亏了这一点所有传入的请求都被成功处理。同样重要的是在负载恢复到平均水平后HPA 会缩小集群以降低基础设施成本。这听起来很不错不是吗 让我们看看 HPA 是如何计算要添加的副本数量的。这是官方文档中提供的公式 d e s i r e d R e p l i c a s c e i l [ c u r r e n t R e p l i c a s ∗ ( c u r r e n t M e t r i c V a l u e / d e s i r e d M e t r i c V a l u e ) ] desiredReplicas ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )] desiredReplicasceil[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/v1kind: Deploymentname: php-apache minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 50这个很简单。一旦 CPU 负载达到 50%HPA 就会开始将副本数量扩展到最多 10 个。 下面是一个比较有趣的案例 apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: worker spec: scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: worker minReplicas: 1 maxReplicas: 10 metrics: - type: Externalexternal:metric:name: queue_messagestarget:type: AverageValueaverageValue: 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/v1kind: Deploymentname: worker minReplicas: 1 maxReplicas: 10 metrics: - type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 50 - type: Externalexternal:metric:name: queue_messagestarget:type: AverageValueaverageValue: 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: 60policies:- type: Percentvalue: 5periodSeconds: 20- type: Podsvalue: 5periodSeconds: 60selectPolicy: Min scaleUp:stabilizationWindowSeconds: 0policies:- type: Percentvalue: 100periodSeconds: 10正如您在上面的清单中看到的它有两个部分。第一个 ( scaleDown) 定义缩小参数而第二个 ( scaleUp) 用于放大。每个部分都有stabilizationWindowSeconds. 这有助于防止在副本数量持续波动时出现所谓的“抖动”或不必要的缩放。这个参数本质上是作为副本数量改变后的超时时间。 现在让我们谈谈这两者的策略。scaleDown策略允许您指定在type: Percent特定时间段内缩减的 Pod 百分比 。如果负载具有周期性现象您必须做的是降低百分比并增加持续时间。在这种情况下随着负载的减少HPA 不会立即杀死大量 Pod根据其公式而是会逐渐杀死对应的Pod。此外您可以设置type: Pods在指定时间段内允许 HPA 杀死的最大 Pod 数量 。 注意selectPolicy: Min参数。这意味着 HPA 使用影响最小 Pod 数量的策略。因此如果百分比值上例中的 5%小于数字替代值上例中的 5 个 PodHPA 将选择百分比值。相反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 清单示例结束本段 apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: worker spec: scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: worker minReplicas: 1 maxReplicas: 10 metrics: - type: Externalexternal:metric:name: queue_messagestarget:type: AverageValueaverageValue: 15 behavior:scaleDown:stabilizationWindowSeconds: 60policies:- type: Percentvalue: 5periodSeconds: 20- type: Podsvalue: 5periodSeconds: 60selectPolicy: MinscaleUp:stabilizationWindowSeconds: 0policies:- type: Percentvalue: 100periodSeconds: 10请注意此示例仅供参考。您将需要对其进行调整以适应您自己的操作的具体情况。 Horizontal Pod Autoscaler 简介HPA 非常适合生产环境。但是在为 HPA 选择指标时您必须谨慎并尽量多的考虑现状。错误的度量标准或错误的阈值将导致资源浪费来自不必要的副本或服务降级如果副本数量不够。密切监视应用程序的行为并对其进行测试直到达到正确的平衡。 3.2. VPA(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/v1kind: Deploymentname: my-app updatePolicy:updateMode: RecreatecontainerPolicies:- containerName: *minAllowed:cpu: 100mmemory: 250MimaxAllowed:cpu: 1memory: 500MicontrolledResources: [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/v1kind: Deploymentname: my-app updatePolicy:updateMode: Off # !!! resourcePolicy:containerPolicies:- containerName: *controlledResources: [cpu, memory]VPA 开始收集指标。您可以使用kubectl describe vpa命令查看建议只需让 VPA 运行几分钟即可 Recommendation:Container Recommendations:Container Name: nginxLower Bound:Cpu: 25mMemory: 52428800Target:Cpu: 25mMemory: 52428800Uncapped Target:Cpu: 25mMemory: 52428800Upper Bound:Cpu: 25mMemory: 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: redisspec:containers:- name: redisimage: redis:6.2.1ports:- containerPort: 6379resources:requests:memory: 100Micpu: 256mlimits:memory: 100Micpu: 256menv:- name: MY_MEM_REQUESTvalueFrom:resourceFieldRef:containerName: appresource: requests.memory- name: MY_MEM_LIMITvalueFrom:resourceFieldRef:containerName: appresource: 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)更清楚地说明了现有的限制。。 4. 疑问和思考 我们分享了一些 Kubernetes 高可用部署应用的的一些建议以及相关的案例这些机制有助于部署高可用性应用程序。我们讨论了调度器操作、更新策略、优先级、探针等方面。最后一部分我们深入讨论了剩下的三个关键主题PodDisruptionBudget、HorizontalPodAutoscaler 和 VerticalPodAutoscaler。 问题中提到的大量案例都是基于我们生成的真实场景如使用请根据自生的环境进行调整。 通过本文我们也希望读者能够根据自有的环境进行验证能够一起分享各自的生成经验能偶一起推进Kubernetes相关技术的发展与进步。再次也感谢读者能够花费大量的时间认真读完本文。 5. 参考文档 暂无