本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

Qbox 如何使用 Kubernetes 和 Supergiant 在 AWS 账单上每月节省 50% 的费用

编者注：今天的文章由托管 Elasticsearch 提供商 Qbox 团队撰写，分享他们使用 Kubernetes 的经验以及如何帮助他们节省了 50% 的云账单。

大约一年前，Qbox 的我们面临着一个生存问题。几乎所有主要的 IaaS 提供商都推出或收购了与我们的 托管 Elasticsearch 服务直接竞争的服务，并且他们中的许多人开始免费提供该服务。除非我们可以重新设计我们的基础设施，使其比我们以前的 VM 方法（以及我们的 IaaS 同行正在使用的方法）具有更高的性能、更高的稳定性和更低的成本，否则这场零和竞赛将会继续。在 Kubernetes、Docker 和 Supergiant（我们自己用于管理分布式和有状态数据的定制层）的帮助下，我们实现了 50% 的节省，这是一个中等五位数的金额。与此同时，支持工单数量急剧下降。我们对结果非常满意，因此我们决定将 Supergiant 开源，使其成为一个独立的产品。这篇文章将演示我们是如何实现这一点的。

早在 2013 年，当很多人甚至还不熟悉 Elasticsearch 时，我们推出了采用专用、直接 VM 模型的即服务产品。我们手工选择了针对 Elasticsearch 优化的特定实例类型，用户配置了在任何区域的隔离虚拟机上运行的单租户、多节点集群。我们在每计算小时的价格上增加了 DevOps 支持和监控的加价，随着 Elasticsearch 成为当今的全球现象，一切都运行良好。

背景
随着我们增长到数千个集群和更多的数千个节点，不仅仅是我们的 AWS 账单失控。我们有 4 名工程师全天候更换死节点并回答支持工单。更糟糕的是，分配的资源量与使用量相比。我们有数千台服务器，它们的总 CPU 利用率低于 5%。我们花了太多钱在绝对没用的处理器上。

我们是如何走到这一步的并不是什么大谜团。VM 是一种有限的资源，对于像 Elasticsearch 这样计算密集型、可突发性的应用程序，我们将需要在那些会缩小集群规模以节省资金的用户和那些会过度配置和超支的用户之间进行协调。当上述竞争压力迫使我们出手时，我们不得不重新评估一切。

采用 Docker 和 Kubernetes
我们的团队曾经避免使用 Docker 一段时间，大概是基于一种模糊的假设，即我们在 VM 中获得的网络和磁盘性能不可能在容器中实现。事实证明，这种假设是完全错误的。

为了运行性能测试，我们必须找到一个可以管理联网容器和卷的系统。那时我们发现了 Kubernetes。起初它对我们来说很陌生，但是当我们熟悉它并构建了性能测试工具后，我们就爱上了它。它不仅和以前一样好，而且更好。

我们观察到的性能提升是由于我们可以在一台机器上“打包”的容器数量。具有讽刺意味的是，我们开始 Docker 实验时是想避免“嘈杂的邻居”，我们认为当多个容器共享同一个 VM 时，这是不可避免的。但是，这种隔离也充当了性能和成本上的瓶颈。举一个现实世界的例子，如果一台机器有 2 个核心，而你需要 3 个核心，那么你就会遇到问题。很少有公共云 VM 配备 3 个核心，因此典型的解决方案是购买 4 个核心，而不是完全利用它们。

这就是 Kubernetes 真正开始发光的地方。它具有 请求和限制 的概念，可以对资源共享提供精细的控制。多个容器可以共享一个底层主机 VM，而不必担心“嘈杂的邻居”。例如，它们可以请求对一定数量的 RAM 的独占控制，并且它们可以定义一个限制以应对溢出。这是一种实用、高性能且具有成本效益的多租户。我们能够提供单租户和多租户世界的最佳组合。

Kubernetes + Supergiant
我们最初为我们自己的 Elasticsearch 客户构建了 Supergiant。Supergiant 通过允许预打包和可重新部署的应用程序拓扑来解决 Kubernetes 的复杂性。更具体地说，Supergiant 允许你使用组件，这些组件有点类似于微服务。组件表示几乎统一的一组软件实例（例如，Elasticsearch、MongoDB、你的 Web 应用程序等）。它们将部署复杂拓扑所需的所有各种 Kubernetes 和云操作汇总到一个易于管理的紧凑实体中。

对于 Qbox，我们从需要 1:1 的节点转变为大约需要 1:11 的节点。当然，节点更大，但是利用率产生了很大的差异。如下图所示，我们可以将一大堆小实例塞到一个大实例上，而不会损失任何性能。较小的用户将受益于更大的资源，从而获得更高的网络吞吐量，并且他们还将获得更大的 CPU 和 RAM 突发。

sg-example.png

计算成本节省
Supergiant 中的 打包算法 及其更高的利用率，导致我们的基础设施占用立即减少了 25%。请记住，这是在更好的性能和更少支持工单的情况下实现的。我们可以调高打包算法，并可能节省更多资金。同时，由于我们的节点更大且更可预测，我们可以更充分地利用 AWS 预留实例带来的经济优势。我们选择了 1 年的部分 RI，这使剩余成本减少了 40% 左右。我们的客户仍然可以灵活地启动、关闭和扩展其 Elasticsearch 节点，而无需我们不断地调整、组合、拆分和重新组合我们的预留。最终，我们节省了 50%。这意味着每年可以节省 60 万美元，这笔钱可以用于支付工程师的工资，而不是让我们的 IaaS 提供商变得更富有。