挑战
Box 成立于 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、ReplicaSet 和 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 进行太多修改即可使其在公司中发挥作用。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 部署方面已经取得了很大的进展，它提供了很多价值。目前，我们所有计算的约百分之五在 Kubernetes 上运行，我认为在未来六个月内，我们将可能达到百分之二十到五十之间。我们正在努力实现所有无状态服务用例，之后将把重点转移到有状态服务。”
事实上，这就是他对整个行业的愿景：Ghods 预测 Kubernetes 有机会成为新的云平台。Kubernetes 提供了一个跨不同云平台（包括裸机）一致的 API，他说：“我不认为人们已经看到了当你能够针对一个单一接口进行编程时可能实现的所有潜力。就像 AWS 改变了基础设施，让你不再需要考虑服务器、机柜或网络设备一样，Kubernetes 使你能够专注于你正在运行的容器，这非常令人兴奋。这就是愿景。”
Ghods 指出，作为云平台，Kubernetes 已经有一些正在开发或最近发布的项目：集群联邦、仪表板 UI 以及 CoreOS 的 etcd Operator。他说：“我真心认为这是我在云基础设施中看到的最令人兴奋的事情，因为它达到了前所未有的自动化和智能化水平，围绕着可移植且与您运行基础设施的每种方式无关的基础设施。”
Box 早期决定使用裸机，是出于必要性才开始其 Kubernetes 之旅的。但 Ghods 表示，即使公司今天不必对云提供商保持中立，随着越来越多的工具和扩展围绕 API 构建，Kubernetes 很快也可能成为行业标准。
Ghods 说：“就像偏离 Linux 毫无意义，因为它是一个标准一样，我认为 Kubernetes 正在走同样的道路。现在还处于早期阶段——文档仍然需要改进，编写和发布规范到 Kubernetes 集群的用户体验仍然粗糙。当您处于前沿时，您可能会付出一些代价。但底线是，这是行业发展的方向。三到五年后，如果您以其他任何方式运行您的基础设施，那将是令人震惊的。”