Kubernetes Pod 冗余策略

做者：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...