作者：Harry Martland

翻译：Bach（才云）

校对：星空下的文仔（才云）、bot（才云）

分布式系统会不可避免地产生些故障，咱们须要打算好如何解决，其中有种办法是运行多个服务实例，这样即使有一个故障了，其余的能够持续接管。在本文中，咱们将探讨一些在 Kubernetes 上实现此指标的不同办法。

K8sMeetup

None

冗余（Redundancy）是有代价的，咱们在思考弹性时就应想到这一点。当然，如果客户能够忍耐大量中断，并且对他们的体验没有太大影响，那么这点就无所谓了。

在探讨服务运行工夫（uptime）时，通常以几个 9 来评估，例如运行工夫为 99.9％，这意味着每 1000 个申请中，只有一个失败。依据以往教训，咱们每减少九个服务，须要破费约十倍的老本。

只有应用程序不是常常解体，咱们就能够运行一个 Pod 并依附 K8s 从新运行，不过这须要一个 Pod 来解决服务接管的负载。

K8sMeetup

N

随着服务开始须要更多的 Pod 来解决负载，咱们能够对其进行扩大。如果流量是随工夫变动的（例如中午顶峰），那咱们要有足够的 Pod 在顶峰工夫解决负载。这种策略在 Pod 接管的流量会显著缩小时，能力提供较好的弹性。

如果某个 Pod 在顶峰时段产生故障，那么申请（request）将散布到其余 Pod 上，这样可能会超过它们的容量。不过在流量较小的话，其余 Pod 可能会有足够的容量来接受负载。

在探讨伸缩时，大家可能听过一些术语，例如 in、out、up 和 down。通常，up 和 down 意味着放弃雷同数量的实例，但减少或缩小 CPU 或 Server 的内存。In 和 out 是减少或删除服务实例，但放弃资源不变。明确这些后，咱们能够进一步实现伸缩，但要留神会受到可应用的最大 CPU 或内存限度。

K8sMeetup

N+1

与 N 一样，咱们要理解须要多少 Pod 来解决顶峰流量，这次增加了一个额定 Pod 来为咱们提供爱护，以避免顶峰期间呈现 Pod 故障的状况。这种策略的弹性老本就是一个 Pod，这是额定的老本，并只在故障状况下才须要。这就是为什么即使有一个 Pod 能够解决所有流量，但咱们仍要有一个额定 Pod。

K8sMeetup

伸缩

与其手动计算顶峰时段所需的 Pod 数量，不如让 K8s 代为实现。有了伸缩指标（scaling metric），K8s 能够依据以后需要伸缩服务，在需要较低时放大规模，在须要时扩充规模，这样就升高了老本。尽管伸缩自身并不能使 Pod 从故障中恢复过来，然而能够应答激增的需要。管制好 Pod 的内存和 CPU 能够使咱们更准确地扩大规模并降低成本。

扩大服务须要留出肯定的空间，最好不要将 Pod 用到极限。Pod 须要一些工夫能力启动，它会主动计算主动伸缩指标。应用程序须要可能解决申请扩大与理论扩大之间的申请。另外，如果有很多 Pod，那么总的闲暇空间会放大，因为它散布在所有 Pod 中。

K8sMeetup

75% 伸缩

晓得主动伸缩以及何时伸缩服务时，咱们就能够管制所需的弹性。将服务容量伸缩到 75％ 时，咱们会损失 25％ 的 Pod，领有的 Pod 越多，损失的也就越多，同时咱们还要为未利用的 Pod 领取大量费用。即使是这样，当咱们运行着大量的 Pod 时，仍旧要思考升高弹性百分比，因为可能会呈现大量 Pod 产生故障的状况。

如果服务的流量特地麻烦，这项策略就会特地有用。尖峰流量（spike）会对主动伸缩产生很大影响，因为它们呈现的工夫很短，以至于主动伸缩器没有工夫做出反馈。如果咱们大抵晓得峰值是多少，那么就能够将其布局到服务的伸缩中。

K8sMeetup

伸缩 + N

如果想准确地管制冗余而不是某个百分比，那么能够抉择扩大容量，再减少 N 中的额定 Pod。这样即使 N 的 Pod 故障，咱们依然有足够的容量，来准确管制冗余 Pod。

K8s Service 应用标签（labels）来决定路由哪些 Pod 的申请。这样咱们能够应用不同配置部署同一 Service 的两个正本集，一个正本集应用程度 Pod 主动伸缩器，而另一副本集配置为具备 N 的 Pod。两个正本集应用雷同的标签标记容器，并且 Service 将路由到该标签。该 Service 在所有 Pod 中平均分配流量，从而容许在扩大服务的同时保护 N 的冗余 Pod。

K8sMeetup

多集群

咱们还能够将应用程序部署到两个 K8s 集群中，这样即使整个集群呈现故障，都还能持续保护服务。负载均衡器在集群后面，并在集群之间路由流量。

运行多个集群时，主动伸缩也更具挑战性，因为伸缩指标通常不会在集群之间共享。如果集群产生了故障，仍在工作的集群将在简直没有告诉的状况下，接管来自故障集群的所有流量。有多种办法能够应答这种忽然减少的负载，主动伸缩性能能迅速地做出反馈并解决流量。

依据所需的冗余水平，集群能够以“被动-被动”模式（active-passive mode）运行，这意味着集群能够接管所有申请，但除非在集群之间共享伸缩指标，否则在此设置中，服务必须从零开始扩大。

K8sMeetup

数量与冗余

领有的 Pod 越多，单个 Pod 的故障对其余 Pod 的影响就越小。假如咱们有十个能够服务 100rps 的 Pod，如果以 90rps 的比例伸缩并且有一个 Pod 故障，那么其余 Pod 要接管 100rps，并达到容量极限；如果咱们有 20 个 Pod，其中有一个 Pod 故障，其余的 Pod 仅需解决 95rps。这两种状况都是假设服务能精确接管申请。实际上，服务通常会收到比这少的流量，如果扩充规模，收到的流量会稍多一些。

K8sMeetup

总结

主动伸缩是一个简单的问题，有很多抉择须要咱们思考。通过本文，心愿大家对此有更好的理解，并且能够应用它来缩小云账单老本，同时放弃服务的失常运行。

原文链接：https://medium.com/better-pro...