挑战
这家企业内容管理公司成立于 2005 年，允许其超过 5000 万用户在云端管理内容。 Box 主要是在公司自己的数据中心内使用裸机构建的，具有单一的 PHP 代码库。随着公司在全球范围内的扩展，它需要专注于“我们如何在从裸机到公共云的许多不同云基础设施上运行我们的工作负载，”Box 联合创始人兼服务架构师 Sam Ghods 说。“这是一个巨大的挑战，因为不同的云，尤其是裸机，具有非常不同的接口。”
解决方案
在过去几年中，Box 一直将基础设施分解为微服务，并成为 Kubernetes 容器编排的早期采用者和贡献者。Ghods 说，Kubernetes 允许 Box 的开发人员“针对在所有云中可移植的一组通用概念。”
影响
“在 Kubernetes 之前，”Ghods 说，“我们的基础设施非常过时，部署一个新的微服务需要超过六个月的时间。今天，部署一个新的微服务需要不到五天的时间。我们正在努力将其缩短到一个小时。”
Box 是一个平台，允许其 5000 多万用户（包括政府和通用电气等大型企业）在云端管理和共享内容，最初是一个 PHP 单体，包含数百万行代码，完全使用裸机构建在自己的数据中心内。它已经开始慢慢地将单体分解成微服务。Box 联合创始人兼服务架构师 Sam Ghods 说：“随着我们不断扩展到全球各地，以及公共云战争的不断升温，我们更加关注如何在许多不同的环境和许多不同的云基础设施提供商中运行我们的工作负载。”“到目前为止，这是一个巨大的挑战，因为所有这些不同的提供商，尤其是裸机，都有非常不同的接口和与它们交互的方式。”
Box 的云原生之旅在当年 6 月加速，当时 Ghods 参加了 DockerCon。该公司意识到它不能再只在裸机上运行应用程序，并正在研究使用 Docker 容器化、使用 OpenStack 虚拟化以及支持公共云。
在该大会上，谷歌宣布发布其 Kubernetes 容器管理系统，Ghods 被说服了。“我们考虑了许多不同的选择，但 Kubernetes 确实脱颖而出，特别是由于 Borg 资深团队的出色能力以及拥有完全基础设施无关的运行云软件方式的愿景，”他说，指的是谷歌内部的容器编排器 Borg。“它从第一天起就被设计为可以在裸机上运行，也可以在 Google Cloud 上运行，这意味着我们实际上可以将其迁移到我们数据中心的内部，然后使用相同的工具和概念在公共云提供商上运行。”
另一个优点是：Ghods 喜欢 Kubernetes 有一组通用的 API 对象，如 pod、服务、副本集和部署对象，这为构建工具提供了统一的表面。“即使像 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 部署，”他说。“现在，我们所有计算量的大约 5% 在 Kubernetes 上运行，我认为在接下来的六个月内，我们可能会达到 20% 到 50%。我们正在努力实现所有无状态服务用例，并在之后将重点转移到有状态服务上。”
事实上，这就是他对整个行业的展望：Ghods 预测 Kubernetes 有机会成为新的云平台。Kubernetes 提供了一个跨不同云平台（包括裸机）一致的 API，而且“我认为人们还没有看到当你能够针对一个单一接口进行编程时所能实现的全部潜力，”他说。“就像 AWS 改变了基础设施，让你不再需要考虑服务器、机柜或网络设备一样，Kubernetes 使你能够专注于正在运行的容器，这非常令人兴奋。这就是愿景。”
Ghods 指出了正在开发中或最近为 Kubernetes 发布的作为云平台的项目：集群联合、仪表板 UI 以及 CoreOS 的 etcd 运算符。“我真诚地相信这是我在云基础设施中见过的最令人兴奋的事情，”他说，“因为它是一个前所未有的自动化和智能水平，围绕着可移植的、与你运行基础设施的每种方式无关的基础设施。”
Box 由于其早期使用裸机的决定，出于必要性踏上了 Kubernetes 之旅。但 Ghods 说，即使公司今天不必对云提供商保持中立，Kubernetes 也可能很快成为行业标准，因为越来越多的工具和扩展围绕着 API 构建。
“就像偏离 Linux 没有意义一样，因为它是一个标准，”Ghods 说，“我认为 Kubernetes 正在走上同一条道路。它还处于早期阶段——文档仍然需要改进，编写和发布规范到 Kubernetes 集群的用户体验仍然很粗糙。当你处于技术前沿时，你可以预期会流血一点。但最重要的是，这就是行业的发展方向。从现在起三到五年，如果你用任何其他方式运行你的基础设施，那真的会令人震惊。”