Box 公司：
Box 是一家上市云存储公司，成立于 2005 年，在线为企业提供在线文件共享和内容管理服务。该公司使用免费增值业务模式为个人账户和企业提供云存储和文件托管。
作为一家云存储公司，数据中心基础设施是他们一直头疼的问题。数据中心性能规划以及运行时间 SLA 曾一度面临压力。他们努力的方向是，基础设施能够做到弹性伸缩，节约资源的同时也能够处理突如其来的数据增长。
本文由 Box 后端工程师 Sam Ghods 撰写，剖析了后端人员从遇到问题，到选择 Kubernetes 来解决问题的具体过程。希望能够给企业以及个人用户带去借鉴意义。

几年前，我们开始分离单个 PHP 应用程序，将 Box 分解成多个微服务。我们知道我们最终需要几十个（甚至几百个）微服务才能取得成功，但是过程中还存在一个严重的问题：我们提供新服务的模式稍微过时。

最开始的时候

如果想部署一个新的产品服务，首先必须要向运营团队要特定的硬件。因为我们在 AWS 之前和虚拟化之前启动 Box，在内部实践。我们的大部分技术栈仍然基于专用于特定服务的裸机服务器。它可能需要几个星期（甚至几个月）订购、搁置、上线您的硬件。然后你必须写 Puppet 配置文件来自定义你的特定服务器。 Puppet 仓库当然是高度安全和锁定的，以防止任何事故的发生，就安全性和稳定性来说，这十分了不起，但是对于程序员的开发速度来说，就差强人意了。

经过几个星期的时间，定义完你的 Puppet 配置之后，获得一些服务器的负载均衡器，进行设定，部署自己的 Nagios 检查，以确保您的服务器和服务在运行，可能完成几乎所有在维基百科上的文章，然后才准备好部署你的代码。之后的开发、预览版本和产品环境等步骤还需要一些人力。这项工作是个负担，于是一些团队会跳过部署，直接到预发布阶段（或者跳过“不一致”，比如负载均衡或者服务授权），会在环境间出现很明显的不一致。

所有的这些工作只是为了推出一个新的服务——现在，想象一下，将之前的那些努力乘以几十或几百，就能够知道我们的这个问题有多严重了。但是有的事情是必须要去做的，所以我们开始研究如何使服务部署和管理变得更加简单。

选择解决方案

我们知道我们需要一个内部 PaaS 平台——这个平台，可以使开发人员能够快速方便地对服务进行部署，预发布到产品环境。我们必须做出的第一个决定是要不要构建基于虚拟机／容器的平台。我们知道容器拥有快速开发和部署的特性，这与我们的目标完美契合。我们想要到达定位器所到达的地方，所以我们选择使用容器化技术来构建我们的平台。

Docker 是镜像和容器格式的大众选择，但是用于跨多个服务器管理容器的技术就不那么好选了，特别是在 2014 年的时候，那会儿我们正在考虑要做什么样的决定。在这一点上，Kubernetes 刚刚发布， Amazon ECS 还没有发布，而 Mesos 不支持本地 Docker 容器。

我们最后选择了 Kubernetes 而不是 Mesos，这个原因可以专门开个帖子来写，但概括来说是因为 Kubernetes 所提供的性能以及它对于容器编排系统的世界观，都更贴近我们自己的架构愿景。说实话，Kubernetes 提供的 API 是我们一直想要的 API。除此之外，我们对 Kubernetes 团队印象深刻——毕竟，他们能更好地构建这个编排平台，并且能够构建和维护世界上最大的容器化平台。

新的工作流程

经过大概 18 个月的艰辛，我们建立并部署了一个平台，大大简化了工程师在生产中获得服务所需要做的工作。新的工作流程如下：
一个工程师写一个 Dockerfile 把他们的服务打包成一个 Docker 镜像。一旦 Jenkins 创建了它们的镜像，并且发布到我们的内部仓库中，他们就编写并测试运行其服务的 Kubernetes 对象，设置服务发现，生成和加载 secrets，提供运行时间配置等等。

注意：这是 Kubernetes 和其他编排解决方案之间的一个关键区别——虽然大多数解决方案需要你去许多不同的系统来管理这些部分（或者自己编写来将这些系统绑在一起），Kubernetes 认为你的基础设施应该基本上可以通过一组 Kubernetes 对象来描述，这些对象被提交并存储在主机上。这不是与 Kubernetes 本身混淆是整体的——上述每个部分的实际实现是通过 Kubernetes 内的个别微服务实现的。只有数据模型是统一的。

一旦工程师写了他们的配置（在 Jsonnet 模板语言中更容易重构），他们将配置添加到中央 git 存储库。然后我们有一个“应用程序”负责不断地调和 git 存储库的状态与我们在每个数据中心使用“kubectl apply”的各个 Kubernetes 主机的状态。（我们帮助贡献了大量的代码“kubectlapply”，我们将在短期内开源应用程序（由我们的实习生构建））。

此时 Kubernetes 接管并在各种服务器上创建 Docker 容器，使用 service-loadbalancer 自动配置我们的 haproxy 负载平衡器，向实例提供秘密和配置等。部署到不同的环境或集群就像添加一个 if 语句在中央 git 存储库中生成更多的文件一样简单。

结果

上述工作流程使得服务从六个月缩短至平均不到一周。我们的一些微服务在不到一个小时内从多个数据中心的本地开发到生产。

我们目前在我们的每个生产数据中心运行 Kubernetes 集群，几个关键路径服务已迁移到平台，还有更多的需要迁移。我们对 Kubernetes 1.3 中新的 PetSet 支持特别兴奋，所以我们最终可以在 Kubernetes 上运行像 Hadoop 这样的服务了。

毫无疑问，如果没有 Kubernetes，这个项目是不可能实现的。 Kubernetes 社区是真正开源协作的一个绝对惊人的模型。我们一直对整个设计和开发过程的透明开放印象深刻，对这个平台有信心，是一个我们会继续投资下去的项目。

本文转载自才云Caicloud公众号。

原文链接：https://mp.weixin.qq.com/s/osopYANbiIoBx1SHhhJrmw

创作场景

Kubernetes 在云存储领域的实践：为 Box 加速微服务构建保驾护航