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

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

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

一年多以前，我们 Qbox 面临一个生存问题。几乎所有主要的 IaaS 提供商都推出或收购了与我们的 Hosted Elasticsearch 服务直接竞争的服务，其中许多甚至开始免费提供。除非我们能重新设计我们的基础设施，使其比我们之前采用的虚拟机方法以及我们的 IaaS 兄弟们正在使用的方法更具性能、更稳定、更便宜，否则“价格战”就不可避免。在 Kubernetes、Docker 和 Supergiant（我们自己开发的用于管理分布式和有状态数据的层）的帮助下，我们成功节省了 50%，这笔节省的金额达到了五位数的中间数。同时，支持工单数量急剧下降。我们对结果非常满意，以至于我们决定将 Supergiant 开源作为一个独立产品。本文将演示我们是如何实现这一目标的。

早在 2013 年，当很多人还不熟悉 Elasticsearch 时，我们推出了专用的、直接虚拟机模式的服务产品。我们手工挑选了针对 Elasticsearch 优化的特定实例类型，用户可以在任何区域配置运行在独立虚拟机上的单租户、多节点集群。我们对每计算小时的价格进行了加价，以提供 DevOps 支持和监控，随着 Elasticsearch 成为今天全球性的现象，世界一度运转良好。

背景
随着我们集群数量增长到数千个，节点数量增长到数万个，不仅我们的 AWS 账单失控。我们有 4 名工程师每天不分昼夜地替换故障节点并回复支持工单。更糟糕的是，分配的资源量与使用量不成比例。我们有数千台服务器，但集体 CPU 利用率不到 5%。我们花费了太多在那些完全没有工作的处理器上。

我们之所以走到这一步，并非什么大秘密。虚拟机是一种有限资源，对于像 Elasticsearch 这样计算密集型、可突发性应用程序，我们将面临用户要么为了省钱而缩小集群规模，要么过度配置和超支的问题。当前述竞争压力迫使我们采取行动时，我们必须重新评估一切。

采用 Docker 和 Kubernetes
我们的团队曾一度回避 Docker，可能是因为我们模糊地认为，在容器中无法实现像虚拟机那样的网络和磁盘性能。事实证明，这种假设是完全错误的。

为了运行性能测试，我们必须找到一个能够管理网络容器和卷的系统。就在那时，我们发现了 Kubernetes。起初它对我们来说很陌生，但当我们熟悉它并构建了一个性能测试工具时，我们就被它征服了。它不仅和以前一样好，甚至更好。

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

这正是 Kubernetes 真正开始大放异彩的地方。它有请求和限制的概念，提供了对资源共享的细粒度控制。多个容器可以共享底层主机虚拟机，而无需担心“嘈杂的邻居”问题。例如，它们可以请求对一定量 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 提供商。