挑战
Box 公司成立于 2005 年，这家企业内容管理公司让其 5000 多万用户能够在云端管理内容。Box 主要使用公司自有数据中心内的裸金属构建，其代码库为单体式 PHP 代码。随着公司在全球扩张，Box 需要关注“我们如何在从裸金属到公有云的多种不同云基础设施上运行我们的工作负载，” Box 的联合创始人兼服务架构师 Sam Ghods 说。“这是一项巨大挑战，因为不同的云，特别是裸金属，接口差异很大。”
解决方案
过去几年，Box 一直将其基础设施分解为微服务，并且成为 Kubernetes 容器编排的早期采用者和贡献者。Ghods 说，Kubernetes 使 Box 的开发者能够“针对一套普遍适用的概念，这些概念可以在所有云上移植。”
影响
“在 Kubernetes 之前，”Ghods 说，“我们的基础设施非常陈旧，部署一个新的微服务需要六个多月。现在，部署一个新的微服务所需时间不到五天。我们正努力将其缩短到一小时。”
Box 是一个平台，允许其 5000 多万用户（包括政府机构和 通用电气 等大型企业）在云端管理和共享内容，它最初是用其自有数据中心内的裸金属构建的、拥有数百万行代码的 PHP 单体应用。它已经开始缓慢地分解这个单体应用，将其拆解成微服务。而且“随着我们向全球各地扩张，以及公有云之战日趋白热化，我们一直在更深入地研究如何在多种不同环境和云基础设施提供商上运行我们的工作负载，” Box 联合创始人兼服务架构师 Sam Ghods 说。“到目前为止，这是一项巨大的挑战，因为所有这些不同的提供商，特别是裸金属，都有非常不同的接口和使用方式。”
Box 的云原生之旅在那年六月加速了，当时 Ghods 参加了 DockerCon 大会。公司已经意识到它不能再只在裸金属上运行其应用程序，并且正在研究使用 Docker 进行容器化、使用 OpenStack 进行虚拟化以及支持公有云。
在那次大会上，Google 宣布发布其 Kubernetes 容器管理系统，Ghods 深受触动。“我们考察了许多不同的方案，但 Kubernetes 脱颖而出，特别是由于其强大的 Borg 元老团队，以及其完全基础设施无关的、运行云软件的愿景，”他说道，同时提到了 Google 内部的容器编排系统 Borg。“它从第一天起就被设计成既能在裸金属上运行，也能在 Google Cloud 上运行，这意味着我们实际上可以在自己的数据中心内部迁移到它，然后使用相同的工具和概念在公有云提供商上运行。”
另一个优势是：Ghods 喜欢 Kubernetes 拥有一套普遍适用的 API 对象，如 Pod、Service、ReplicaSet 和 Deployment 对象，这为构建工具提供了统一的基础。“即使是在 Kubernetes 之上构建的 PaaS 层，例如 OpenShift 或 Deis，仍然将这些对象视为一流原则，”他说道。“我们很高兴这些抽象概念能够在整个生态系统中共享，这将带来比我们在其他潜在解决方案中看到的更大的发展势头。”
仅仅六个月后，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 来说，也许更大的挑战是文化方面的。“Kubernetes，以及通常意义上的云原生，代表着相当大的范式转变，而且它不是非常渐进式的，”Ghods 说。“我们实质上是在推介这样一种观点：Kubernetes 将解决一切问题，因为它以正确的方式做事，一切都会突然变得更好。但重要的是要记住，它不像许多其他现有解决方案那样久经考验。你不能说这家或那家公司花了多长时间来做这件事，因为这样做的公司还不多。我们的团队不得不真正为资源而战，因为我们的项目有点像登月计划。”
吸取经验教训后，Ghods 为面临类似挑战的公司提供了以下两点建议：
服务发现对 Box 来说是一个巨大的问题，团队不得不决定是构建一个临时解决方案，还是等待 Kubernetes 原生满足 Box 的独特需求。经过大量讨论后，Ghods 说，“我们只是开始专注于交付一个可行的东西，然后再考虑将来可能迁移到更原生的解决方案。”“团队的首要目标始终应该是在基础设施上服务于真实的生产用例，无论它们多么微不足道。这有助于保持团队自身和组织对项目的势头和认知。”
早期，团队在 Docker 文件之上构建了一个抽象层，以帮助确保镜像具有正确的安全更新。事实证明这是多余的工作，因为容器镜像被认为是不可变的，并且你可以在构建后轻松扫描它们，以确保它们不包含漏洞。因为通过容器化管理基础设施是一个如此不连续的飞跃，所以最好从直接与原生工具交互并学习它们的独特优势和注意事项开始。抽象层应该只在出现实际需求后才构建。
最终，影响是巨大的。“在 Kubernetes 之前，”Ghods 说，“我们的基础设施非常陈旧，部署一个新的微服务需要六个多月。现在部署一个新的微服务所需时间不到五天。我们正努力将其缩短到一小时。公认的是，那六个月的大部分时间是由于我们系统存在的问题造成的，但裸金属本质上是一个难以支持的平台，除非你有一个像 Kubernetes 这样的系统来帮助管理它。”
据 Ghods 估计，Box 距离实现 90% 以上使用 Kubernetes 的目标还有几年的时间。“在拥有提供巨大价值的关键任务稳定 Kubernetes 部署方面，我们已经取得了很大进展，”他说道。“目前，我们所有计算量的约百分之五运行在 Kubernetes 上，我认为在接下来的六个月内，这一比例可能会达到百分之二十到百分之五十。我们正在努力支持所有无状态服务用例，之后会将重点转移到有状态服务。”
事实上，这也是他在整个行业中所展望的：Ghods 预测，Kubernetes 有机会成为新的云平台。Kubernetes 提供了一个在不同云平台（包括裸金属）上保持一致的 API，“我认为人们还没有看到当你能够基于一个单一接口编程时可能实现的全部潜力，”他说道。“就像 AWS 改变了基础设施，让你不再需要考虑服务器、机柜或网络设备一样，Kubernetes 让你能够完全专注于你正在运行的容器，这非常令人兴奋。这就是愿景。”
Ghods 指出了目前正在开发中或最近发布的一些项目，这些项目将 Kubernetes 作为云平台：集群联邦、Dashboard UI 以及 CoreOS 的 etcd Operator。“我真诚地相信这是我在云基础设施中见过的最令人兴奋的事情，”他说道，“因为它是一个围绕基础设施前所未见的自动化和智能化水平，而且它对于任何运行基础设施的方式都是可移植和无关的。”
Box 凭借其早期使用裸金属的决定，出于必要踏上了 Kubernetes 之旅。但 Ghods 说，即使今天公司不必对云提供商无关，随着越来越多的工具和扩展围绕 API 构建，Kubernetes 可能很快就会成为行业标准。
“就像偏离 Linux 没有意义一样，因为它是一个标准，”Ghods 说，“我认为 Kubernetes 正在沿着同样的道路前进。现在还处于早期阶段——文档仍然需要完善，编写和发布规范到 Kubernetes 集群的用户体验也还很粗糙。站在技术前沿，你可能会付出一点代价。但关键是，这是行业发展方向。从现在起三到五年内，如果你以任何其他方式运行基础设施，那将非常令人震惊。”