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

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

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

一年多以前，我们 Qbox 面临一个生存问题。几乎所有主要的 IaaS 提供商都推出或收购了直接与我们的托管 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 开始大放异彩的地方。它拥有请求和限制的概念，提供了对资源共享的精细控制。多个容器可以共享底层主机虚拟机，而无需担心“吵闹的邻居”问题。例如，他们可以请求对一定量内存的独占控制，也可以定义一个限制来应对溢出。这是一种实用、高性能且成本效益高的多租户方式。我们能够兼得单租户和多租户的好处。

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

对于 Qbox 来说，我们从需要 1:1 的节点比例发展到大约 1:11。诚然，节点更大了，但利用率带来了巨大的不同。如下图所示，我们可以将大量小实例塞到一个大实例上，且不损失任何性能。小用户会因为运行在更大的资源上而获得更高的网络吞吐量，同时还能获得更大的 CPU 和内存突发能力。

sg-example.png

计算成本节省
Supergiant 中的打包算法及其提高的利用率，使我们的基础设施占用量立即下降了 25%。请记住，这同时带来了更好的性能和更少的支持工单。我们可以调高打包算法，可能会节省更多钱。与此同时，由于我们的节点更大且更具可预测性，我们能够更充分地利用 AWS 预留实例带来的经济效益。我们选择了 1 年期部分预留实例，这使剩余成本大约降低了 40%。我们的客户仍然可以灵活地启动、停止和扩展他们的 Elasticsearch 节点，而无需我们不断地调整、组合、拆分和重新组合我们的预留。最终，我们节省了 50%。这意味着每年 60 万美元可以用于支付工程师薪水，而不是让我们的 IaaS 提供商更富有。