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