为什么选择 Kubernetes？

简单来说，就是它很好地满足了我们的需求；它能解决重要且复杂的问题，而又不需要我们自己去构建解决方案。Kubernetes提供的解决方案主要聚焦于扩展、打包以及使服务具有一定程度的“自愈”能力。

另一个关键的考量因素是部署——滚动升级和回滚很简单。我们已经围绕部署构建了复杂的基础设施，不过相关细节的话，我们会在另一篇文章中介绍。

我们如何使用 Kubernetes？

我们的生产基础设施分布在 4 个可用区，在 4 个特有的 Kubernetes 集群中。从技术上讲，Kubernetes 现在提供了在单个集群实体（entity）中管理这种拓扑的机制，但我们还没有探索过的这项新功能。

随着时间的推移，我们认识到，将系统分布在 4 个集群中有一些很大的好处，而且越来越多，下面是一些比较重要的。

能够在需要时通过一些内部工具跨 AZ 转移流量

事实证明，这在单个区域出现问题（无论是云提供商的原因，还是其他原因）时非常有用。

在生产环境中滚动上线基础设施更改

假设我们想测试一个新的Kubernetes插件或配置更改——当我们在底层基础设施上验证更改（只有当我们无法在过渡集群上验证时），便可以将大部分的生产流量转移到其他 3 个集群。

我们选择的服务网格是Istio。我们使用各种内部控制器管理入口和出口网关，为的是可以顺畅地配置和协调从 CDN 到所有 4 个集群的流量。我们不会在这里讨论细节（这本身就是一篇文章！）。

配置管理

Terraform 和一些内部工具是我们管理集群配置的首选武器。当团队第一次概念化 Kubernetes 配置时，并没有多少现成的工具可以帮助我们简化 Terraform。我们编写（并持续维护）了一个内部应用程序，它让我们可以跨集群（无论是生产集群，还是我们内部的任何过渡集群）模板化、传递和应用我们的配置。

事实证明，一个让我们可以使用模板和静态配置的工具非常有价值，它可以确保我们的配置始终有一个“真相来源”，并使我们有一个适当的流程可以测试更改并应用到集群。

我们都知道 Kubernetes 和容器技术的发展有多快——请在回复中告诉我们你还使用了哪些工具来简化 Kubernetes 配置管理！

优化集群缩放——针对突发流量进行扩展，依据请求量进行收缩

为了确保应用程序请求的资源大小与实际利用率相匹配，我们做了大量的工作。这对 Medium 来说有很大的帮助，那让我们可以充分利用我们的节点（更有效的打包）。还有一个好处是缩放更平滑，但需要一些额外的调优和工具才能实现。

集群超额配置和 Pod 抢占

这个工具很棒。对于它所做的事情，简单来说就是定义许多副本以及它们所需的资源量。在我们的例子中，我们知道需要随着流量大幅扩展的服务（我们称之为backend-A）恰好也需要大量的资源。一旦了解了缩放事件的性质，我们就知道需要规划多少个副本以及如何调整它们的大小。

假设流量暴增的情况会频繁出现，而此时该服务额外需要大约 200 个 pod（横跨所有 4 个集群）才能应对突发的请求。如果不能快速扩展，我们就会看到 5xx 错误急剧增加。

我们在每个集群中设置了集群超额配置（cluster-overprovisioner），请求的 CPU 和内存数略高于backend-A pod，并将副本数设置为 50（单集群配置）。通过适当地配置优先级抢占和集群自动缩放器，我们获得了以下好处：

集群超额配置（cluster-overprovisioner）的目标是在任何时间为backend-A 的纵向扩展（scale-up）事件额外提供 200 个 pod 的资源。
当需要调度新增的backend-A pod 时，集群超额配置的 pod 将被抢占（也就是驱逐）。
超额配置的 pod 被驱逐后需要重新调度。因此，它们通过集群自动缩放器触发节点纵向扩展事件。

因此，本质上上讲，集群超额配置消除了节点纵向扩展事件的延迟，让我们有空间可以平稳地处理生产服务的扩展事件而又不会产生中断。