附录C Box：案例研究

附录C Box：案例研究

以下内容最初由CNCF发布在Kubernetes.io上，并且在此获得许可。

在2014年夏天，Box感到十年的硬件和软件基础设施的痛苦，这与公司的需求无法保持一致。

一个平台允许其超过5000万用户（包括政府和大型企业如通用电气公司）管理和共享云中的内容，Box最初是一个庞大的数百万行代码的庞大的PHP代码，内置裸机数据中心。它已经开始在巨石上慢慢消失，分解成微服务。 “随着我们扩展到全球各地，公共云战争正在升温，我们开始专注于如何在许多不同的环境和许多不同的云基础设施提供商之间运行我们的工作负载，”Box联合创始人和服务架构师Sam Ghods。 “迄今为止，这是一个巨大的挑战，因为所有这些不同的提供商，特别是裸机，都有非常不同的界面和与他们合作的方式。”

当Ghods参加DockerCon时，Box的云本土之旅加速了。该公司已经认识到，它不能再仅仅使用裸机来运行其应用程序，并正在研究与Docker的容器化，使用OpenStack进行虚拟化以及支持公共云。

在那次会议上，Google宣布发布Kubernetes容器管理系统，Ghods赢得了胜利。 “我们研究了许多不同的选择，但Kubernetes确实很出色，特别是因为博格老兵的团队非常强大，并且具有完全基础架构不可知的方式来运行云软件，”他说，内部集装箱协调人Borg。 “事实上，第一天它的设计与裸机一样运行，就像我们可以在我们的数据中心内实际迁移到它一样，然后使用相同的工具和概念在公共云提供商上运行，好。”

另外：Ghods喜欢Kubernetes拥有一套通用的API对象，如pod，服务，副本集和部署，这些对象创建了一个一致的表面来构建工具。 “甚至像OpenShift或Deis这样的构建在Kubernetes之上的PaaS层仍然将这些对象视为一流的原则，”他说。 “我们很高兴能够在整个生态系统中共享这些抽象概念，这会产生比我们在其他潜在解决方案中更多的动力。”

Box六个月后在一个生产数据中心的集群中部署了Kubernetes。 Kubernetes在0.11版本之前仍然是预测版。他们从小开始：Ghods的团队在Kubernetes上运行的第一件事就是Box API监视器，它确认了Boxis。 “这只是一个让整个管道运作正常的测试服务，”他说。接下来是一些处理作业的守护进程，它们“很好而且安全，因为如果他们遇到任何中断，我们不会失败来自客户的同步传入请求。”

几个月后，该团队可以发送并要求提供信息的第一个现场服务启动。那时，Ghods说：“我们对Kubernetes集群的稳定性感到满意。我们开始移植一些服务，然后我们将增加集群的大小和端口数量，最后每个数据中心的服务器数量大约为100台，这些服务器纯粹专用于Kubernetes。而且在未来的12个月里，这个数字将会增长很多，达到数百甚至数千。“

在观察开始使用Kubernetes进行微服务的团队时，“我们立即看到正在发布的微服务数量有所增加，”Ghodsnotes说。 “显然，通过微服务构建软件的更好方式已被压抑，并且灵活性的提高帮助我们的开发人员提高了生产力，并为更好的架构选择做好了准备。”

Ghods反映，作为早期采用者，Box与公司现在的经历有不同的旅程。他说：“我们肯定是在等待某些事情稳定或获得释放功能的锁定步骤，”他说。 “在早期，我们对Kubectl应用等组件做了很多贡献，并等待Kubernetes释放它们中的每一个，然后我们会升级，贡献更多，并来回多次。整个项目从我们第一次在Kubernetes上进行实际部署到整体可用性需要大约18个月的时间。如果我们今天完成同样的事情，它可能会少于六个。“

无论如何，Box无需为Kubernetes对公司工作做过多修改。 Ghods说：“我们团队在Box中实施Kubernetes所做的绝大多数工作一直致力于在我们现有的（往往是遗留下来的）基础架构内工作，例如将我们的基础操作系统从RHEL6升级到RHEL7或整合它将纳入我们的监控基础架构Nagios。但总体而言，Kubernetes非常灵活，能够适应我们的许多限制因素，并且我们在裸机基础架构上非常成功地运行它。“

对于Box来说，更大的挑战也许是文化上的挑战。 Ghods说：“Kubernetes和一般的云本身代表了一个非常大的范式转换，并且它不是非常渐进的，”Ghods说。 “我们基本上是这样说的，Kubernetes将会解决所有问题，因为它能够以正确的方式做事，而一切都会突然变得更好。但是要记住，它不像其他许多解决方案那样可靠。你不能说这家或那家公司花了多少时间做这件事，因为还没有那么多。我们的团队必须真正为资源而战，因为我们的项目有一点点的恐惧。“

从经验中学习，Ghods为经历类似挑战的公司提供了以下两条建议：

提前和经常交付。对于Box来说，服务发现是一个巨大的问题，团队必须决定是建立一个临时解决方案还是等待Kubernetesto本身满足Box的独特要求。经过多次辩论之后，“我们刚开始专注于提供可行的解决方案，然后处理可能在稍后迁移到更原始的解决方案，”Ghods说。 “无论多么微不足道，团队的上述目标应始终是为基础架构上的实际生产用例服务。这有助于保持团队本身和组织对项目的看法。“
保持开放的态度，了解公司必须从开发人员那里抽象出什么，以及什么没有。早期，团队在Dockerfiles之上构建了一个抽象，以帮助确保所有容器映像具有正确的安全更新。事实证明这是多余的工作，因为容器映像是不可变的，您可以在构建后扫描它们以确保它们可以不包含漏洞。因为通过集装箱化来管理基础设施是一个不连续的飞跃，所以最好先直接使用本地工具并学习其独特的优势和注意事项。抽象只能在实际需要出现之后才能建立。

最后，影响力非常强大。 “在Kubernetes之前，”Ghods说，“我们的基础设施非常陈旧，需要6个多月才能部署一个新的微服务。现在，一个新的微服务部署时间不到五天。我们正在努力让它达到不到一天。诚然，这六个月的大部分时间都是由于我们的系统有多么糟糕，但裸机本质上是一个难以支持的平台，除非您有像Kubernetes这样的系统来帮助管理它。“

按Ghods的估计，Box距离他成为90％ Kubernetes店的目标还有几年的时间。 “到目前为止，我们已经完成了一项稳定的，关键任务的Kubernetes部署，它提供了很多价值，”他说。 “现在我们所有电脑的10％左右都运行在Kubernetes上，我认为明年我们可能会超过一半。我们正在努力实现所有无状态服务使用案例，并计划在此之后将我们的重点转移到有状态服务。“

事实上，这就是他在整个行业中的设想：Ghods预测Kubernetes有机会成为新的云平台。 Kubernetes提供了一个涵盖不同云平台的API，包括裸机，以及“当我们可以针对单一界面进行编程时，我不认为人们已经看到了可能的全部潜力”，他说。 “与AWS改变基础架构一样，您不必再考虑服务器或机柜或网络设备，Kubernetes使您能够专注于您正在运行的软件，这非常令人兴奋。这是愿景。“

Ghods指出了已经在开发或最近发布的作为云平台的项目：集群联合，仪表板UI和CoreOS’setcd运营商。 “我真的相信这是我在云基础架构中看到的最激动人心的事情，”他说，“因为它是一个前所未有的自动化和智能环境，其基础设施对每个基础设施平台都是可移植和不可知的。”

由于早期决定使用裸机，Box不得已开始了Kubernetes之旅。但是Ghods表示，即使公司现在不必对云提供商不可知，Kubernetes也可能很快成为行业标准，因为越来越多的工具和扩展是围绕API构建的。

“同样的方式，偏离Linux是没有意义的，因为它是如此的标准，”Ghods说，“我认为Kubernetes正在走相同的道路。现在还处于早期阶段 - 文档仍然需要工作，用于编写和发布规格到Kubernetes集群的用户体验仍然很艰难。当你处于尖端时，你可能会出血一点。但底线是，这是行业发展的方向。从现在开始的三到五年，如果以其他方式运行基础设施，真的会非常震惊。“