Pinterest 的 Kubernetes 平台化之旅

Pinterest 软件工程师 透露 他们在公司采用 Kubernetes 时引入了定制的工具和资源。对于其他希望构建自己的平台即服务（PaaS）和相关开发人员工作流的团队来说，其关键收获包括容器编排系统如何才能提供一种方法来统一管理工作负载，Kubernetes 的工作负载模型可以通过自定义资源定义来增强，并且一个健壮的端到端的测试管道是避免回归的关键。

Pinterest 是一款社交媒体网页和移动应用程序，它允许用户保存或“pin”信息，并且拥有庞大的用户基础，在 40 亿块主板上总共保存了超过 2000 亿个 pin。由于该体量以及与之相关的基础设施堆栈的增长，Pinterest 团队遇到了几个挑战。他们表示，他们的工程师在启动工作负载时没有统一的经验，管理大量的虚拟机给基础设施团队带来了巨大的维护负担。此外，很难跨不同的系统构建基础设施治理工具，也很难确定哪些资源可以被回收利用。这与 Airbnb 在简化 Kubernetes 工作流程方面的经验 相呼应。该团队试图通过三个关键的主题来解决这些问题：服务可靠性、基础设施效率和开发人员生产力。

据主要作者 Lida Li 和她团队所说，云管理平台团队在 2017 年开始与 Kubernetes 合作， docker 化 他们的生产工作负载，并评估不同的容器编排系统。Kubernetes 的本机工作负载模型涵盖了部署、作业和守护进程集，但是团队需要更多的工作负载模型。他们表示，可用性问题是采用 Kubernetes 过程中的“巨大障碍”，在同一个 Kubernetes 集群上支持不同版本的运行时支持是很困难的。他们的解决方案是设计 自定义资源定义 （ custom resource definitions ，CRDs）。这是一个预发布的部署工作流，可用于基于 Kubernetes 的新计算平台的早期采用者。该团队正在将此工作流集成到他们的 CI/CD 平台中，以便为他们的工程师创建一个更干净的服务。

关于如何部署 Pinterest CRDs 的概述（图片来自 Pinterest 工程博客 ）

Pinterest 设计 CRDs 是为了达到各种各样的目的，考虑到 Kubernetes 的采用，这对工程师来说可能也是一种信息。首先，他们希望将各种本地的 Kubernetes 资源打包成一个单一的工作负载，这样就避免了他们的工程师一个接一个地重复做这项工作。其次，他们希望通过在规范中添加必要的 sidecars、init 容器、设备变量和容量，来为应用程序注入必要的运行时支持。最后，这些定义用于对本地资源执行生命周期管理，例如协调规范和更新事件记录。Pinterest 团队推测，这种演变大大减少了工程师的工作量，从而降低了出错的风险。这与 Shopify 团队 去年在纽约 QCon 大会上分享的经验 如出一辙。

处理此类问题的工程师需要考虑的一个问题是，为了避免应用程序之间的不一致，以及过于庞大的维护和支持负担，Pinterest 发现他们的基础设施团队需要部署所有的工作流类型，如 pod 级别的 sidecars、node 级别的守护进程集或 VM（虚拟机）级别的守护程序。Tinder 平台自 2019 年 3 月以来一直只在 Kubernetes 上运行，该公司采取了相反的做法，其基础设施的责任由该公司所有的工程师共同承担。

需要考虑的另一个问题是，Pinterest 团队在本地 Kubernetes 测试基础设施之上构建了一个端到端的测试管道，测试部署到所有集群上。这减轻了与在 Kubernetes 原生工作流模型之上工作的相关风险，工程师们表示，在上生产之前，它捕获到了许多回归。Pinterest 团队也将他们的部署工作流整合到他们的新 CI|CD 平台中。

原文链接：

Pinterest’s Journey to a Kubernetes Platform