在Pinterest存在的多年中，该服务的3亿用户在40亿个板上创建了超过2000亿个引脚。 为了服务于这群用户和广泛的内容基础，该门户网站开发了数千种服务，范围包括多个CPU可以处理的微服务，最后到旋转整个虚拟机群的巨型整体。 然后是公司将目光投向k8的时刻。 “多维数据集”对“兴趣”是什么？ 您将从我们最新的Pinterest工程博客文章的翻译中学到这一点。
因此，亿万用户和数千亿个引脚。 为了服务于这群用户和广泛的内容基础，我们已经开发了数千种服务，从可以由多个CPU处理的微服务到可以旋转整个虚拟机群的巨型整体。 另外，我们有各种框架，它们可能还需要CPU资源，内存或对I / O的访问。
为了支持这个工具动物园，开发团队面临许多挑战：
- 工程师没有统一的方式来运行工作环境。 无状态服务，有状态服务以及正在积极开发的项目均基于完全不同的技术堆栈。 这导致为工程师创建了一个完整的培训课程，并使我们的基础架构团队的工作严重复杂化。
- 拥有自己的虚拟机机群的开发人员会给内部管理员带来巨大的负担。 结果，诸如更新OS或AMI之类的简单操作将持续数周和数月。 这导致看似绝对的日常工作量增加。
- 在现有解决方案之上创建全球基础架构管理工具的困难。 由于发现虚拟机的所有者并不容易，因此情况变得复杂。 也就是说，我们不知道提取这些在基础架构其他部分中工作的能力是否安全。
容器编排系统是统一工作负载管理的一种方式。 由于项目中涉及的所有资源均由一个集中式系统进行管理，因此它们为您打开了提高开发速度并简化基础架构管理的道路。
图1：基础架构优先级（可靠性，开发人员生产力和效率）。Pinterest上的云管理平台团队在2017年遇到了K8s。 到2017年上半年，我们记录了我们的大多数生产设施，包括API和所有Web服务器。 之后，我们仔细评估了容器解决方案编排，构建集群以及与之协作的各种系统。 到2017年底，我们决定使用Kubernetes。 它足够灵活，并在开发人员社区中得到广泛支持。
到目前为止，我们已经创建了自己的基于Kops的集群引导工具，并迁移到Kubernetes现有的基础架构组件，例如网络，安全性，指标，日志记录，身份管理和流量。 我们还为我们的资源实现了工作负载建模系统，其复杂性对于开发人员是隐藏的。 现在，我们专注于确保群集的稳定性，扩展规模和连接新客户端。
Kubernetes：Pinterest的方式
在我们的工程师喜欢的平台上，以Pinterest规模开始使用Kubernetes的工作令人难以置信。
作为一家大公司，我们已经在基础架构工具上进行了大量投资。 示例包括处理证书和分发密钥的安全工具，流量控制组件，服务发现系统，可见性以及发送日志和度量。 所有这些都是出于一个原因而收集的：我们采用了正常的试验和错误方式，因此我们希望将所有经济情况整合到Kubernetes上的新基础架构中，而不是在新平台上重新发明旧自行车。 由于所有应用程序支持已经存在，因此该方法通常简化了迁移，因此无需从头开始创建。
另一方面，Kubernetes本身的负载预测模型（例如，部署，作业和Daemon套件）不足以满足我们的项目要求。 这些可用性问题是迁移到Kubernetes的巨大障碍。 例如，我们听说服务开发人员抱怨缺少或不正确的登录设置。 当使用相同的规范和任务创建数百个副本时，我们还遇到了模板引擎使用不当的问题，这导致了调试方面的噩梦问题。
在同一集群中支持不同版本也非常困难。 想想客户支持的复杂性，如果您需要立即在同一运行时的多个版本中进行工作，以及它们的所有问题，错误和更新。
Pinterest自定义资源和控制器
为了使我们的工程师更轻松地实施Kubernetes，并简化和加快基础架构，我们开发了自己的自定义资源定义（CRD）。
CRD提供以下功能：
- 组合各种本地Kubernetes资源以使它们作为单个负载工作。 例如，PinterestService资源包括部署，登录服务和配置映射。 这使开发人员不必担心设置DNS。
- 实施必要的应用程序支持。 用户应仅根据其业务逻辑关注容器规范，而CRD控制器将实现所有必要的初始化容器，环境变量和容器规范。 这为开发人员提供了根本不同的舒适度。
- CRD控制器还可以管理其自身资源的生命周期并提高调试可用性。 这包括在期望的和实际的规范上达成一致，更新CRD的状态以及维护事件日志等等。 没有CRD，开发人员将不得不管理大量资源，这只会增加出现错误的可能性。
这是PinterestService和我们的控制器控制的内部资源的示例：
如您在上面看到的，要支持自定义容器，我们需要将一个初始化容器和几个附加组件集成到其中，以确保安全性，可见性并处理网络流量。 此外，我们创建了配置图模板并为批处理作业提供了对PVC模板的支持，并跟踪了各种环境变量以跟踪标识，资源消耗和垃圾回收。
很难想象开发人员会想在没有CRD支持的情况下手动编写这些配置文件，更不用说对配置的进一步支持和调试了。
工作流程应用程序部署
上图显示了如何在Kubernetes集群中部署Pinterest自定义资源：
- 开发人员通过CLI和用户界面与我们的Kubernetes集群进行交互。
- CLI / UI工具从Artifactory提取工作流配置YAML文件和其他程序集属性（相同版本标识符），然后将它们发送到Job Submission Service。 此步骤可确保仅将生产版本传送到群集。
- JSS是通往各种平台（包括Kubernetes）的网关。 在此进行用户身份验证，配额发放和CRD配置的部分验证。
- 在JSS端检查CRD之后，该信息将发送到k8s平台API。
- 我们的CRD控制器监视所有用户资源上的事件。 它将CR转换为本地k8s资源，添加必要的模块，设置适当的环境变量并执行其他辅助工作，从而确保容器用户应用程序具有足够的基础结构支持。
- 然后CRD控制器将接收到的数据传输到Kubernetes API，以便由调度程序处理并投入使用。
注意 ：此预发布工作流部署是为新k8s平台的第一批用户创建的。 我们现在正在完成此过程，以便与我们的新CI / CD完全集成。 这意味着我们无法说出与Kubernetes有关的所有信息。 我们期待在下一篇博客文章“为Pinterest构建CI / CD平台”中分享我们的经验并向团队介绍这一进展。
特殊资源的类型
根据Pinterest的特定需求，我们开发了以下CRD，适用于各种工作流程：
- PinterestService是长期运行的无状态服务。 我们的许多主要系统都基于一组此类服务。
- PinterestJobSet对全周期批处理作业进行建模。 Pinterest有一个常见的场景，根据该场景，多个任务并行运行相同的容器，而与其他相似的过程无关。
- PinterestCronJob与小周期性负载一起广泛使用。 这是具有Pinterest支持机制的cron本机外壳，负责安全性，流量，日志和指标。
- PinterestDaemon包括Daemon的基础结构。 随着我们对集群的更多支持，这个家庭继续增长。
- PinterestTrainingJob扩展到Tensorflow和Pytorch流程，提供与所有其他CRD相同水平的在线支持。 由于Pinterest正在积极使用Tensorflow和其他机器学习系统，因此我们有理由围绕它们构建单独的CRD。
我们还在研究PinterestStatefulSet，它将很快适用于数据仓库和其他有状态系统。
运行时支持
当应用程序模块在Kubernetes中运行时，它会自动接收一个证书来标识自己。 该证书用于访问秘密存储或通过mTLS与其他服务通信。 同时，容器初始化配置器和Daemon将在启动容器应用程序之前下载所有必需的依赖项。 一切准备就绪后，便车通行和Daemon将在我们的Zookeeper中注册模块IP地址，以便客户找到它。 由于在启动应用程序之前已配置了网络模块，因此所有这些都将起作用。
以下是运行时工作负载支持的典型示例。 对于其他类型的工作负载，可能需要稍有不同的支持，但它们都将显示为Sidecar Pod级，节点级或Daemon级虚拟机。 我们确保将所有这些部署在管理基础架构的框架内并在应用程序之间进行协调，从而最终显着减少技术工作和客户支持方面的工作量。
测试和质量检查
我们在现有的Kubernetes测试基础架构之上构建了一个端到端测试管道。 这些测试适用于我们所有的集群。 在成为产品集群的一部分之前，我们的管道经历了许多更改。
除了测试系统，我们还有监视和警告系统，它们不断监视系统组件的状态，资源消耗和其他重要指标，仅在必要的人工干预时通知我们。
替代品
我们研究了自定义资源的一些替代方法，例如变异访问控制器和模板系统。 但是，他们所有人都在工作中遇到严重困难，因此我们选择了CRD的道路。
变异公差控制器用于输入边车，环境变量和其他运行时支持。 尽管如此，他仍然面临各种问题，例如资源绑定和生命周期管理，而CRD中不会出现这些问题。
注意：模板系统（例如Helm图）也广泛用于运行具有类似配置的应用程序。 但是，我们的生产应用程序种类繁多，无法使用模板进行管理。 另外，在连续部署期间，使用模板会产生太多错误。
未来的工作
现在，我们正在处理所有集群上的混合负载。 为了支持不同类型和规模的类似流程，我们在以下领域开展工作：
- 集群群集在集群之间分布大型应用程序，以提供可伸缩性和稳定性。
- 确保群集的稳定性，可伸缩性和可见性，以创建应用程序及其SLA的连接。
- 资源和配额管理，以使应用程序不会相互冲突，并且集群规模由我们控制。
- 用于在Kubernetes中支持和部署应用程序的新CI / CD平台。