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