作者：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…