挑战
这家企业内容管理公司成立于 2005 年，允许其超过 5000 万的用户在云端管理内容。Box 主要使用公司自己数据中心内的裸机以及单体 PHP 代码库构建。 随着公司在全球范围内的扩张，它需要专注于“我们如何在从裸机到公有云的多种不同云基础设施上运行我们的工作负载”，Box 的联合创始人兼服务架构师 Sam Ghods 说。“这是一个巨大的挑战，因为不同的云，尤其是裸机，具有非常不同的接口。”
解决方案
在过去的几年里，Box 一直在将其基础设施分解为微服务，并成为 Kubernetes 容器编排的早期采用者和贡献者。Ghods 说，Kubernetes 使 Box 的开发人员能够“针对一套通用于所有云的可移植概念”。
影响
Ghods 说：“在 Kubernetes 之前，我们的基础设施非常陈旧，部署一个新的微服务需要六个多月的时间。现在，部署一个新的微服务不到五天。我们正在努力将其缩短到一个小时。”
Box 是一个允许其超过 5000 万用户（包括政府和像 通用电气 这样的大型企业）在云端管理和共享内容的平台，最初是一个 PHP 单体，由数百万行代码组成，完全使用其自身数据中心内的裸机构建。它已经开始慢慢地剥离这个单体，将其分解为微服务。Box 联合创始人兼服务架构师 Sam Ghods 说：“随着我们扩展到全球各个地区，以及公有云竞争的加剧，我们更加关注如何跨许多不同的环境和许多不同的云基础设施提供商运行我们的工作负载。迄今为止，这是一个巨大的挑战，因为所有这些不同的提供商，尤其是裸机，都具有非常不同的接口和与之交互的方式。”
Box 的云原生之旅在 6 月份加速，当时 Ghods 参加了 DockerCon。该公司已经意识到它不能再仅在裸机上运行其应用程序，并且正在研究使用 Docker 进行容器化、使用 OpenStack 进行虚拟化以及支持公有云。
在那次会议上，Google 宣布发布其 Kubernetes 容器管理系统，Ghods 被说服了。他说：“我们研究了很多不同的选择，但 Kubernetes 确实脱颖而出，尤其是因为它拥有由 Borg 资深人士组成的非常强大的团队，以及拥有完全与基础设施无关的方式来运行云软件的愿景。”他指的是 Google 内部的容器编排器 Borg。“它在第一天就被设计为在裸机上运行，就像在 Google Cloud 上运行一样，这意味着我们实际上可以迁移到我们数据中心内部，然后使用相同的工具和概念在公有云提供商上运行。”
另一个优点是：Ghods 喜欢 Kubernetes 拥有一组通用的 API 对象，如 pod、service、replica set 和 deployment 对象，这创建了一个一致的表面来构建工具。“即使像 OpenShift 或 Deis 这样构建在 Kubernetes 之上的 PaaS 层仍然将这些对象视为第一原则，”他说。“我们对在整个生态系统中共享这些抽象感到兴奋，这将比我们在其他潜在解决方案中看到的产生更大的动力。”
六个月后，Box 在生产数据中心的一个集群中部署了 Kubernetes。当时的 Kubernetes 仍然是预测试版，版本号为 0.11。他们从小处着手：Ghods 的团队在 Kubernetes 上运行的第一个东西是一个 Box API 检查器，用于确认 Box 是否启动。“这只是为了编写和部署一些软件来使整个管道正常运行，”他说。接下来是一些处理作业的守护进程，“这很好且安全，因为如果它们遇到任何中断，我们不会让来自客户的同步传入请求失败。”
第一个实时服务（团队可以将其路由并请求信息）在几个月后启动。Ghods 说，那时，“我们对 Kubernetes 集群的稳定性感到满意。我们开始移植一些服务，然后我们扩大集群规模并移植更多服务，最终在每个数据中心大约有 100 台服务器专门用于 Kubernetes。并且在接下来的 12 个月中，这个数字将大大扩展，可能达到数百甚至数千台。”
在观察开始使用 Kubernetes 进行微服务的团队时，“我们立即看到发布的微服务数量增加，”Ghods 指出。“显然，人们迫切需要一种通过微服务构建软件的更好方法，而敏捷性的提高有助于我们的开发人员提高工作效率并做出更好的架构选择。”
Ghods 回顾说，作为早期采用者，Box 的旅程与现在的公司所经历的不同。“我们肯定在等待某些东西稳定或功能发布，”他说。“在早期，我们为 [kubectl apply 等组件] 做了很多贡献，并等待 Kubernetes 发布它们中的每一个，然后我们会升级、贡献更多，并多次来回。从我们在 Kubernetes 上进行首次真正部署到实现普遍可用，整个项目大约花费了 18 个月的时间。如果今天我们做完全相同的事情，可能不会超过六个月。”
无论如何，Box 不需要对 Kubernetes 进行太多修改才能使其为公司工作。“我们的团队为在 Box 上实施 Kubernetes 所做的大部分工作都是使其在我们现有的（通常是遗留的）基础设施中工作，”Ghods 说，“例如将我们的基础操作系统从 RHEL6 升级到 RHEL7，或将其集成到 Nagios，我们的监控基础设施中。但总的来说，Kubernetes 在适应我们的许多约束方面非常灵活，并且我们已经在裸机基础设施上非常成功地运行它。”
也许 Box 面临的更大挑战是文化上的。“Kubernetes 和一般的云原生代表着一种相当大的范式转变，而且它不是渐进式的，”Ghods 说。“我们本质上是在提出这样的观点，即 Kubernetes 将解决所有问题，因为它以正确的方式做事，而且一切都突然变得更好了。但是，重要的是要记住，它不像许多其他解决方案那样久经考验。您不能说这家或那家公司花了多长时间来完成它，因为现在还没有那么多。我们的团队必须真正争取资源，因为我们的项目有点像登月计划。”
从经验中吸取教训后，Ghods 为面临类似挑战的公司提供了以下两条建议
服务发现是 Box 的一个大问题，团队必须决定是构建一个临时解决方案，还是等待 Kubernetes 本身满足 Box 的独特需求。经过一番争论，“我们只是开始专注于交付一些可以工作的东西，然后再处理以后可能迁移到更原生解决方案的问题，”Ghods 说。“团队的首要目标应该是始终在基础设施上服务真正的生产用例，无论多么微不足道。这有助于保持团队本身和组织对项目认知的势头。”
早期，该团队在 Docker 文件之上构建了一个抽象，以帮助确保镜像具有正确的安全更新。事实证明，这是一项多余的工作，因为容器镜像被认为是不可变的，并且您可以在构建后轻松扫描它们，以确保它们不包含漏洞。由于通过容器化管理基础设施是一次不连续的飞跃，因此最好从直接与原生工具交互并了解其独特的优势和注意事项开始。仅在出现实际需要时才应构建抽象。
最后，其影响是巨大的。“在 Kubernetes 之前，”Ghods 说，“我们的基础设施非常陈旧，部署一个新的微服务需要六个多月的时间。现在，部署一个新的微服务不到五天。我们正在努力将其缩短到一个小时。诚然，这六个月中的大部分时间都是由于我们的系统有多么糟糕，但裸机本身就是一个难以支持的平台，除非您有像 Kubernetes 这样的系统来帮助管理它。”
据 Ghods 估计，Box 距离他成为 90% 以上 Kubernetes 商店的目标还有几年时间。“我们在拥有一个提供大量价值的关键任务、稳定的 Kubernetes 部署方面已经取得了很大进展，”他说。“目前我们所有计算中约有百分之五在 Kubernetes 上运行，我认为在未来六个月内，这个比例可能会在 20% 到 50% 之间。我们正在努力启用所有无状态服务用例，然后将重点转移到有状态服务。”
事实上，这就是他对整个行业的展望：Ghods 预测 Kubernetes 有机会成为新的云平台。Kubernetes 提供了一个在不同云平台（包括裸机）上保持一致的 API，“我不认为人们已经看到了当你可以针对一个单一接口进行编程时，可能实现的全部潜力，”他说。“就像 AWS 改变了基础设施，让你不再需要考虑服务器、机柜或网络设备一样，Kubernetes 使你能够完全专注于你正在运行的容器，这非常令人兴奋。这就是愿景。”
Ghods 指出了 Kubernetes 作为云平台已经开发或最近发布的项目：集群联邦、Dashboard UI 和 CoreOS 的 etcd operator。“我真的认为这是我在云基础设施中见过的最令人兴奋的事情，”他说，“因为它在基础设施周围提供了前所未有的自动化和智能化水平，并且可以移植，与你运行基础设施的每种方式无关。”
Box 早期决定使用裸机，因此出于必要开始了 Kubernetes 之旅。但 Ghods 表示，即使公司今天不必对云提供商保持不可知态度，随着越来越多的工具和扩展围绕 API 构建，Kubernetes 可能很快会成为行业标准。
“就像偏离 Linux 没有意义，因为它已成为标准一样，”Ghods 说，“我认为 Kubernetes 正在走同样的道路。现在还处于早期阶段——文档仍然需要改进，并且向 Kubernetes 集群编写和发布规范的用户体验仍然很粗糙。当你处于前沿时，你可能会遇到一些问题。但最重要的是，这就是行业的发展方向。三到五年后，如果你的基础设施以其他方式运行，那将真正令人震惊。”