挑战
在 2015 年从 Rackspace 迁移到 AWS 后，VSCO 除了运行其 PHP 单体应用 外，还开始构建 Node.js 和 Go 微服务。机器学习团队的工程经理 Melinda Lu 表示，团队使用 Docker 对微服务进行了容器化，但“它们都位于独立的 EC2 实例组中，每个服务都有专门的实例”。社区团队的高级软件工程师 Naveen Gattu 补充道：“这导致了大量资源浪费。我们开始寻找一种方法来整合并提高 AWS 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 的首批用户之一，在 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 构造作为服务暴露给我们的工程师，而不是暴露更高阶的构造，对我们来说非常有效。它让你熟悉这项技术并用它做更多有趣的事情。”