挑战
在 2015 年从 Rackspace 迁移到 AWS 后，VSCO 除了运行其 PHP 单体应用外，还开始构建 Node.js 和 Go 微服务。据机器学习团队工程经理 Melinda Lu 称，团队使用 Docker 对这些微服务进行了容器化，但“它们都位于独立的 EC2 实例组中，每个服务独享一组”。社区团队高级软件工程师 Naveen Gattu 补充道：“这导致了大量的资源浪费。我们开始寻找一种方法来整合 EC2 实例并提高效率。”
解决方案
团队开始探索调度系统的想法，并评估了包括 Mesos 和 Swarm 在内的几种解决方案，最终决定选择 Kubernetes。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 schema 错误和服务特定的基础设施配置错误，并且提高了修复停机故障的速度。
在 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 的首批用户之一，在它开源五天后就将其用于生产环境。Lu 说：“我们希望通过我们的边缘负载均衡器直接为移动客户端提供 gRPC 和 HTTP/2 服务，而 Envoy 是我们唯一合理的解决方案。”“默认情况下跨所有服务发送一致且详细统计信息的能力极大地简化了可观测性和仪表盘的标准化。”DevOps 工程师 Ryan Nguyen 表示，Envoy 内置的指标也“极大地帮助了调试”。
引入 Kubernetes、gRPC 和 Envoy 后，VSCO 的总停机时间减少了 88%，这主要归因于消除了 JSON schema 错误和服务特定的基础设施配置错误，并且提高了修复停机故障的速度。
鉴于成功使用了 CNCF 项目，VSCO 正开始尝试其他项目，包括 CNI 和 Prometheus。Nguyen 表示：“有大型组织支持这些技术，我们尝试这些软件并部署到生产环境更有信心。”
团队对 gRPC 和 Envoy 做出了贡献，并希望在 CNCF 社区更加活跃。Lu 表示：“我非常赞赏我们的工程师们是如何仅仅通过组合大量 Kubernetes 原语就想出了许多富有创意的解决方案。”“将 Kubernetes 构造作为服务暴露给我们的工程师，而不是暴露更高级别的构造，对我们很有帮助。这让他们熟悉了这项技术，并能用它做更多有趣的事情。”