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