挑战
在 2015 年从 Rackspace 迁移到 AWS 后，VSCO 开始构建 Node.js 和 Go 微服务，同时运行其 PHP 单体应用。机器学习团队工程经理 Melinda Lu 表示，团队使用 Docker 将微服务容器化，“但它们都位于专门用于每个服务的独立 EC2 实例组中”。社区团队高级软件工程师 Naveen Gattu 补充道：“这造成了大量资源浪费。我们开始寻找一种方法来整合资源并在 AWS EC2 实例中提高效率。”
解决方案
该团队开始探索调度系统的概念，并在决定采用 Kubernetes 之前考察了包括 Mesos 和 Swarm 在内的几种解决方案。VSCO 在其云原生堆栈中还使用了 gRPC 和 Envoy。
影响
高级软件工程师 Brendan Ryan 表示，以前，部署需要“大量的手动调整、我们编写的内部脚本，而且由于我们使用的是不同的 EC2 实例，运维团队必须从头到尾全程监控”。“我们没有真正以系统的方式进行测试，也没有以标准化的方式使用可重复使用的容器或构建。”现在，入职流程更快了。以前，首次部署需要两天的动手设置时间；现在只需要两个小时。通过转向持续集成、容器化和 Kubernetes，速度得到了显著提高。对于典型的服务，从代码完成到在真实基础设施上进行生产部署的时间从一到两周缩短到两到四个小时。Gattu 补充道：“从工时来看，以前需要一个人，现在只需要一名开发人员和一名 DevOps 人员同时工作。”随着单个部署在生产环境中所需时间的减少 80%，部署次数也从每年 1200 次增加到 3200 次。此外，还节省了实际的资金：借助 Kubernetes，VSCO 的 EC2 效率提高了 2 到 20 倍，具体取决于服务，这为公司的 EC2 账单节省了大约 70% 的费用。Ryan 指出，该公司能够“使用规模大致相同的开发团队”从管理一个大型单体应用程序转变为管理 50 多个微服务。“我们之所以能够做到这一点，是因为我们对工具的信任度提高了，而且灵活性也大大增强，因此我们不需要雇佣 DevOps 工程师来调整每个服务。”借助 Kubernetes、gRPC 和 Envoy，VSCO 的总停机时间减少了 88%，这主要得益于消除了 JSON 模式错误和特定于服务的基础设施配置错误，以及加快了故障排除速度。
在 VSCO 于 2015 年迁移到 AWS 并且其用户群超过 3000 万之后，该团队很快意识到这种设置已经行不通了。开发人员已经开始构建一些 Node 和 Go 微服务，该团队尝试使用 Docker 对其进行容器化。但机器学习团队工程经理 Melinda Lu 表示，“它们都位于专门用于每个服务的独立 EC2 实例组中”。社区团队高级软件工程师 Naveen Gattu 补充道：“这造成了大量资源浪费。我们开始寻找一种方法来整合资源并在 EC2 实例中提高效率。”
该团队制定了一个清单，其中包括易用性和易实施性、支持级别以及是否是开源的，然后评估了几种调度解决方案，包括 Mesos 和 Swarm，最后决定采用 Kubernetes。Lu 表示：“Kubernetes 似乎拥有最强大的开源社区。”此外，“我们已经开始在很大程度上采用 Google 堆栈作为标准，使用 Go 作为语言，并使用 gRPC 进行数据中心内我们自己的服务之间的几乎所有通信。因此，选择 Kubernetes 对我们来说似乎很自然。”
当时，托管 Kubernetes 产品很少，生态系统中可用的工具也较少，因此该团队建立了自己的集群，并为其特定的部署需求构建了一些自定义组件，例如自动入口控制器和用于金丝雀部署的策略结构。Lu 表示：“我们已经开始拆分单体应用，因此我们逐个迁移，从非常小、风险很低的服务开始。“每个新服务都部署在那里。”第一个服务于 2016 年底迁移，一年后，整个堆栈的 80% 都迁移到了 Kubernetes 上，包括其余的单体应用。
影响非常大。Ryan 表示，部署过去需要“大量的手动调整、我们编写的内部脚本，而且由于我们使用的是不同的 EC2 实例，运维团队必须从头到尾全程监控”。“我们没有真正以系统的方式进行测试，也没有以标准化的方式使用可重复使用的容器或构建。”现在，入职流程更快了。以前，首次部署需要两天的动手设置时间；现在只需要两个小时。
通过转向持续集成、容器化和 Kubernetes，速度得到了显著提高。对于典型的服务，从代码完成到在真实基础设施上进行生产部署的时间从一到两周缩短到两到四个小时。此外，Gattu 表示，“从工时来看，以前需要一个人，现在只需要一名开发人员和一名 DevOps 人员同时工作。”随着单个部署在生产环境中所需时间的减少 80%，部署次数也从每年 1200 次增加到 3200 次。
此外，还节省了实际的资金：借助 Kubernetes，VSCO 的 EC2 效率提高了 2 到 20 倍，具体取决于服务，这为公司的 EC2 账单节省了大约 70% 的费用。
Ryan 指出，该公司能够“使用规模大致相同的开发团队”从管理一个大型单体应用程序转变为管理 50 多个微服务。“我们之所以能够做到这一点，是因为我们对工具的信任度提高了，而且当系统出现压力点时，灵活性也大大增强。你可以增加服务的 CPU 内存需求，而无需启动和关闭实例，也无需通读 AWS 页面来熟悉大量术语，这对于我们这种规模的公司来说是不可接受的。”
Envoy 和 gRPC 也对 VSCO 产生了积极的影响。Lu 表示：“我们从 gRPC 中获得了许多开箱即用的好处：跨多种语言的类型安全、使用 gRPC IDL 定义服务的便利性、内置架构（如拦截器）以及 HTTP/1.1 和 JSON 的性能改进。”
VSCO 是 Envoy 的首批用户之一，在 Envoy 开源五天后就将其投入生产。Lu 表示：“我们希望通过边缘负载均衡器直接向移动客户端提供 gRPC 和 HTTP/2 服务，而 Envoy 是我们唯一合理的解决方案。“能够在所有服务中默认发送一致且详细的统计信息，这使得可观察性和仪表板标准化变得更加容易。”DevOps 工程师 Ryan Nguyen 表示，Envoy 内置的指标也“极大地帮助了调试”。
借助 Kubernetes、gRPC 和 Envoy，VSCO 的总停机时间减少了 88%，这主要得益于消除了 JSON 模式错误和特定于服务的基础设施配置错误，以及加快了故障排除速度。
鉴于使用 CNCF 项目取得的成功，VSCO 开始尝试其他项目，包括 CNI 和 Prometheus。Nguyen 表示：“有大型组织支持这些技术，我们对尝试这些软件并将其部署到生产环境中更有信心。”
该团队已经为 gRPC 和 Envoy 做出了贡献，并希望在 CNCF 社区中更加活跃。Lu 表示：“看到我们的工程师如何仅仅通过组合许多 Kubernetes 原语就提出了创造性的解决方案，我感到非常印象深刻。“为我们的工程师公开 Kubernetes 结构作为服务，而不是公开更高阶的结构，这对我们来说非常有效。它让你熟悉这项技术，并用它做更多有趣的事情。”