以下内容最初由 CNCF 发布在 Kubernetes.io 上，并且在此获得许可。
在 2014 年夏天，Box 对沉淀了十年的硬件和软件基础架构的痛苦，这无法与公司的需求保持一致。
该平台为超过 5000 万用户（包括政府和大型企业如通用电气公司）管理和共享云中的内容，Box 最初是一个使用 PHP 写的具有数百万行的庞大代码，内置裸机数据中心。它已经开始将单体应用分解成微服务。 “随着我们扩展到全球各地，公有云战争正在升温，我们开始专注于如何在许多不同的环境和许多不同的云基础架构提供商之间运行我们的工作负载”，Box 联合创始人和服务架构师 Sam Ghods 说。 “迄今为止，这是一个巨大的挑战，因为所有这些不同的提供商，特别是裸机，都有非常不同的接口和与合作方式。”
当 Ghods 参加 DockerCon 时，Box 的云原生之旅加速了。该公司已经认识到，它不能再仅仅使用裸机来运行应用程序，正在研究 Docker 容器化，使用 OpenStack 进行虚拟化以及支持公有云。
在那次会议上，Google 宣布发布 Kubernetes 容器管理系统，Ghods 成功了。 “我们研究了许多不同的选择，但 Kubernetes 确实很出色，特别是因为 Borg 老兵的团队非常强大，可以以基础架构不可知的方式来运行云软件，”他谈到 Google 内部的容器调度器 Borg。 “事实上，一开始它设计与裸机一样运行，就像我们可以在数据中心内迁移到它一样，然后也使用相同的工具和概念在公有云提供商上运行。”
另外：Ghods 喜欢 Kubernetes 拥有一套通用的 API 对象，如 pod、服务、副本集和部署，这些对象创建了一个一致的接口来构建工具。 “甚至像 OpenShift 或 Deis 这样的构建在 Kubernetes 之上的 PaaS 层仍然将这些对象视为统一的原则，”他说。 “我们很高兴能够在整个生态系统中共享这些抽象概念，这会产生比我们在其他潜在解决方案中更多的动力。”
六个月后 Box 在一个生产数据中心的集群中部署了 Kubernetes。Kubernetes 在 0.11 版本之前仍然是测试版。他们从小版本开始：Ghods 的团队在 Kubernetes 上运行的第一个服务就是 Box API 监视器，确认了 Box 可以运行。 “这只是一个让整个管道运作正常的测试服务，”他说。接下来是一些处理作业的守护进程，它们“很好而且安全，因为如果他们遇到任何中断，也不会让来自客户的同步传入请求失败。”
几个月后，该团队可以发送并要求提供信息的第一个实时服务启动。那时，Ghods 说：“我们对 Kubernetes 集群的稳定性感到满意。我们开始迁移一些服务，然后我们将扩大集群的规模和端口数量，最后每个数据中心的服务器数量大约为 100 台，这些服务器纯粹专用于 Kubernetes。在未来的 12 个月里，这个数字将会增长很多，达到数百甚至数千。“
在观察开始使用 Kubernetes 进行微服务的团队时，“我们看到正在发布的微服务数量有所增加，”Ghodsnotes 说。 “显然，通过微服务构建软件的方式已被压抑很久，随着灵活性的提高帮助我们的开发人员提高了生产力，并为更好的架构选择做好了准备。”
Ghods 反映，作为早期采用者，Box 经历了不同的旅程。他说：“我们肯定是在等待某些事情稳定和功能发布，我们在这一步上被锁定，”他说。 “在早期，我们对 Kubectl 应用等组件做了很多贡献，并等待 Kubernetes 发布，然后我们会升级，贡献更多，并来回多次。整个项目从我们第一次在 Kubernetes 上进行实际部署到 GA 需要大约 18 个月的时间。如果我们今天自己来做一遍同样的事情，可能会少于六个月。“
无论如何，Box 无需为 Kubernetes 做过多修改。Ghods 说：“我们团队在 Box 中实施 Kubernetes 所做的绝大多数工作一直致力于在我们现有的（往往是遗留下来的）基础架构内的工作，例如将我们的基础操作系统从 RHEL6 升级到 RHEL7 或将其整合纳入到我们的监控基础架构 Nagios。但总体而言，Kubernetes 非常灵活，能够适应我们的许多限制因素，并且它在我们的裸机基础架构上运行非常成功。“
对于 Box 来说，更大的挑战也许是文化上的挑战。Ghods 说：“Kubernetes 和一般的云本身代表了一个非常大的范式转换，并且它不是非常渐进的，”Ghods 说。 “我们可以这样说，Kubernetes 将会解决所有问题，因为它能够以正确的方式做事，一切都会变得更好。但是要记住，它不像其他许多解决方案那样可靠。你不能说这家或那家公司花了多少时间做这件事，因为还没有那么多。我们的团队必须真正为资源而战，因为我们的项目有一点点的恐惧。“
从经验中学习，Ghods 为经历类似挑战的公司提供了以下两条建议：
- 提前和经常交付。对于 Box 来说，服务发现是一个巨大的问题，团队必须决定是建立一个临时解决方案还是等待 Kubernetes 本身满足 Box 的独特要求。经过多次辩论之后，“我们刚开始专注于提供可行的解决方案，然后处理可能在稍后迁移到更原始的解决方案，”Ghods 说。 “无论多么微不足道，团队的上述目标应始终是为基础架构上的实际生产用例服务。这有助于保持团队本身和组织对项目的看法。“
- 保持开放的态度，了解公司必须从开发人员那里抽象出什么和没有抽象出什么。早期，团队在 Dockerfiles 之上构建了一个抽象，以帮助确保所有容器镜像具有正确的安全更新。事实证明这是多余的工作，因为容器镜像是不可变的，您可以在构建后扫描它们以确保它们不包含漏洞。因为通过容器化来管理基础架构是一个不连续的飞跃，所以最好先直接使用本地工具学习其独特的优势和注意事项。抽象只能在实际需要出现之后才能建立。
最后，影响力非常强大。“在 Kubernetes 之前，”Ghods 说，“我们的基础架构非常陈旧，需要 6 个多月才能部署一个新的微服务。现在，一个新的微服务部署时间不到五天。我们正在努力让它达到不到一天。诚然，这六个月的大部分时间都是由于我们的系统有多么糟糕，但裸机本质上是一个难以支持的平台，除非您有像 Kubernetes 这样的系统来帮助管理它。“
按 Ghods 的估计，Box 距离完成 90％运行在 Kubernetes 上的目标还有几年的时间。 “到目前为止，我们已经完成了一项稳定的，关键任务的 Kubernetes 部署，它提供了很多价值，”他说。 “现在我们 10％左右服务器都运行在 Kubernetes 上，我认为明年我们可能会超过一半。我们正在努力实现所有无状态服务使用案例，并计划在此之后将我们的重点转移到有状态服务。“
事实上，这就是他在整个行业中的设想：Ghods 预测 Kubernetes 有机会成为新的云平台。Kubernetes 提供了一个涵盖不同云平台的 API，包括裸机，以及“当我们可以针对单一界面进行编程时，我不认为人们已经看到了可能的全部潜力”，他说。 “与 AWS 改变基础架构一样，您不必再考虑服务器或机柜或网络设备，Kubernetes 使您能够专注于您正在运行的软件，这非常令人兴奋。这是愿景。“
Ghods 指出了已经在开发或最近发布的作为云平台的项目：集群联邦，Dashboard UI 和 CoreOS 的 etcd operator。 “我真的相信这是我在云基础架构中看到的最激动人心的事情，”他说，“因为它是一个前所未有的自动化和智能环境，其基础架构对每个基础架构平台都是可移植和不可知的。”
由于早期决定使用裸机，Box 不得已开始了 Kubernetes 之旅。但是 Ghods 表示，即使公司现在不必对云提供商不可知，Kubernetes 也可能很快成为行业标准，因为越来越多的工具和扩展是围绕 API 构建的。
“同样的方式，偏离 Linux 是没有意义的，因为它是如此的标准，”Ghods 说，“我认为 Kubernetes 正在走相同的道路。现在还处于早期阶段 —— 文档仍然需要工作，用于编写和发布 YAML 到 Kubernetes 集群的用户体验仍然很艰难。当你处于潮流最前线时，你可能会做出一些牺牲。但底线是，这是行业发展的方向。从现在开始的三到五年，如果您还会以其他方式运行基础架构，那么真的会让人非常震惊。“