公司 Pinterest 地点 加利福尼亚州旧金山 行业 Web 和移动应用

挑战

成立八年后,Pinterest 已发展成拥有 1,000 个微服务、多层基础设施以及多样化的设置工具和平台。2016 年,公司启动了一个新的计算平台路线图,其愿景是创建从构思到生产的最快路径,而无需工程师担心底层基础设施。

解决方案

第一阶段包括将服务迁移到 Docker 容器。这些服务在 2017 年初投入生产后,团队开始研究编排,以帮助提高效率并以分散的方式管理它们。在评估了各种解决方案后,Pinterest 选择了 Kubernetes。

影响

Pinterest 云和数据基础设施部门的产品经理 Micheal Benedict 表示:“通过迁移到 Kubernetes,团队能够构建按需扩展和新的故障转移策略,此外还简化了 Jenkins 等复杂基础设施的整体部署和管理。”“我们不仅缩短了构建时间,还取得了巨大的效率提升。例如,团队在非高峰时段回收了超过 80% 的容量。结果,Jenkins Kubernetes 集群现在每天使用的实例小时数比以前的静态集群减少了 30%。”

Pinterest 生于云端——自 2010 年第一天起就运行在 AWS 上——但即使是云原生公司也会经历一些成长的烦恼。

自推出以来,Pinterest 已成为家喻户晓的品牌,每月活跃用户超过 2 亿,保存了 1000 亿个对象。在其内部,运行着 1000 个微服务和数十万个数据作业。

随着这种增长,基础设施层变得越来越复杂,针对不同工作负载的设置工具和平台也多种多样,导致端到端开发人员体验不一致且复杂,最终导致投入生产的速度变慢。因此,在 2016 年,公司启动了一个新的计算平台路线图,其愿景是创建从构思到生产的最快路径,而无需工程师担心底层基础设施。

第一阶段涉及迁移到 Docker。“Pinterest 长期以来一直大量运行在虚拟机上,直接运行在 EC2 实例上,”云和数据基础设施部门的产品经理 Micheal Benedict 说。“为了解决软件打包问题,并避免工程师拥有部分集群以及此类挑战,我们标准化了打包机制,然后将其迁移到虚拟机顶部的容器中。没有太多剧烈的变化。当时我们不想大动干戈。”

第一个迁移的服务是支持 Pinterest 大部分功能的单一 API 集群。同时,Benedict 的基础设施治理团队建立了成本分摊和容量规划系统,以分析公司如何使用其在 AWS 上的虚拟机。“很明显,我们目前运行在虚拟机上是不可持续的,”Benedict 说。“很多资源都被低效利用了。有一些效率提升的努力,在一定规模下运行良好,但现在你必须转向一种更分散的管理方式。所以我们认为编排可以帮助解决这部分问题。”

这导致了路线图的第二阶段。2017 年 7 月,经过八周的评估期,团队选择了 Kubernetes 而非其他编排平台。“Kubernetes 当时缺少一些功能——例如,我们想要在 Kubernetes 上运行 Spark,”Benedict 说。“但我们意识到,我们为尝试构建这些功能所投入的开发周期非常值得,无论是对 Pinterest 还是对社区来说。我们一直在 Big Data SIG 的讨论中。我们意识到,在我们实际生产许多这些功能时,我们将能够利用社区正在做的事情。”

2018 年初,团队开始将第一个用例引入 Kubernetes 系统:Jenkins 工作负载。“尽管我们在一天中的某个特定时段进行构建,但我们总是需要分配峰值容量,”Benedict 说。“它们没有任何自动扩展功能,所以容量保持不变。加速构建很困难,因为启动需要更多时间。考虑到这些担忧,我们认为这将是我们完美的应用场景。”

他们扩大了集群,并与一个四人团队合作,将 Jenkins Kubernetes 集群投入生产。“我们仍然有我们的静态 Jenkins 集群,”Benedict 说,“但在 Kubernetes 上,我们正在进行类似的构建,测试整个管道,准备好工件,然后进行比较,看看这里构建花了多少时间。SLA 是否正常,生成的工件是否正确,是否存在问题?”

“到目前为止一切顺利,”他补充道,“尤其是在我们如何配置 Jenkins 工作负载在 Kubernetes 共享集群上的灵活性方面。这就是我们一直努力争取的目标。”

截至 2018 年第一季度末,团队成功将 Jenkins Master 迁移到 Kubernetes 上原生运行,并协作开发了 Jenkins Kubernetes Plugin 来管理工作器的生命周期。“我们目前正在这个新集群上构建整个 Pinterest JVM 堆栈(Pinterest 中较大的单体仓库之一,最近已进行了 bazel 化改造),”Benedict 说。“在高峰期,我们在几百个节点上运行数千个 Pod。总的来说,通过迁移到 Kubernetes,团队能够构建按需扩展和新的故障转移策略,此外还简化了 Jenkins 等复杂基础设施的整体部署和管理。我们不仅缩短了构建时间,还取得了巨大的效率提升。例如,团队在非高峰时段回收了超过 80% 的容量。结果,Jenkins Kubernetes 集群现在每天使用的实例小时数比以前的静态集群减少了 30%。”

Benedict 指出了一个“相当稳健的未来路线图”。除了 Pinterest 大数据团队在 Kubernetes 上进行的 Spark 实验之外,该公司还与 Amazon 的 EKS 团队合作开发了 ENI/CNI 插件。

一旦 Jenkins 集群脱离暗模式并正常运行,Benedict 希望建立最佳实践,包括建立治理原语(包括与成本分摊系统的集成),然后再迁移下一个服务。“我们有一个健康的用例管道等待上线。在 Jenkins 之后,我们希望启用对 Tensorflow 和 Apache Spark 的支持。在某个时候,我们计划迁移公司的单体 API 服务。如果我们迁移并了解其中的复杂性,它会增强我们的信心,”Benedict 说。“这将为我们迁移所有其他服务做好准备。”

作为云原生领域的先驱多年,Pinterest 渴望分享其持续的旅程。“我们有能力在公共云环境中大规模运行事物,并以许多人可能无法做到的方式进行测试,”Benedict 说。“我们处于一个很好的位置,可以回馈其中一些经验教训。”