Medium的Kubernetes基础设施

本文最初发布于 Medium 工程博客。

图片来自 Unsplash，由 orbtal media 提供

本文概要介绍了我们如何使用 Kubernetes 来管理微服务。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 集群超额配置（cluster-overprovisioner）的目标是在任何时间为 backend-A 的纵向扩展（scale-up）事件额外提供 200 个 pod 的资源。

• 当需要调度新增的 backend-A  pod 时，集群超额配置的 pod 将被抢占（也就是驱逐）。

• 超额配置的 pod 被驱逐后需要重新调度。因此，它们通过集群自动缩放器触发节点纵向扩展事件。

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

在超额配置和适型化（right-sizin）之前，节点总数（在所有 4 个集群中）定期爆增至 800-900 个节点以上

在进行超额配置和应用程序适型化之后，在所有生产集群中，峰值节点数量下降到接近 400 个，很少超过 600 个

Kubernetes 非常复杂，并且根据组织需要提供了无数可能的配置。在 Medium，我们根据自己的需求塑造了 Kubernetes，我们对此非常自豪。我们还会一如既往地探索增强基础设施的新方法，并利用新技术提高可靠性和可扩展性。

原文链接：

https://medium.engineering/kubernetes-infrastructure-at-medium-d9e2444932ef

声明：本文为 InfoQ 翻译，未经许可禁止转载。