国外手机交友APP Tinder向Kubernetes迁移的过程

Tinder是国外的一款手机交友APP，作用是基于用户的地理位置，每天“推荐”一定距离内的四个对象，根据用户在 Facebook 上面的共同好友数量、共同兴趣和关系网给出评分，得分最高的推荐对象优先展示。

为什么

大概两年前，Tinder决定转向Kubernetes。Kubernetes通过不可变部署推动Tinder Engine向容器化以及低接触式运维发展。应用程序的构建、部署以及基础架构都可以由代码定义。

我们还致力于解决扩展以及稳定性的挑战。当扩展变得至关重要时，我们通常在等待新的EC2实例上线的这几分钟里备受煎熬。容器能够在几秒中内，而不是几分钟，完成调度并且上线，这对于我们很有吸引力。

一切并不容易。2019年初的迁移里，我们的Kubernetes集群一团乱麻，并且遇到各种问题，流量，集群大小以及DNS等。我们解决了这些有意思的问题，迁移了200多个服务，并且运行了一个大规模的Kubernetes集群，一共有1000个节点，15000个Pod以及48000个运行着的容器。

怎么做的

从2018年1月份起，我们就开始实验迁移的各个阶段了。首先将所有服务容器化，并且部署到一系列Kubernetes预生产环境上。从10月份起，我们开始系统性地将所有遗留服务迁移到Kubernetes上。第二年3月份，迁移工作结束，Tinder平台全都跑在了Kubernetes上。

为Kubernetes构建image

在Kubernetes集群里运行着超过30个微服务的源码仓库。这些仓库里的代码是不同语言编写的（比如，Node.js，Java，Scala，Go），同一种语言还有多个运行时环境。

build系统设计成可以为每个微服务做完整自定义的“build上下文”，通常包括Dockerfile以及一系列shell脚本。虽然内容都是全自定义的，这些build的上下文是遵循标准化的格式编写的。这样标准化的build上下文使得单个build系统可以处理所有的微服务。

图1-1 Builder容器的标准化构建流程

为了达到运行时环境的最大一致性，我们在开发和测试阶段使用相同的构建流程。当想设计一种方案来保证跨平台的build环境的一致性时，我们遇到了独特的问题。最终，所有build流程都在一个特别的“Builder”容器内执行。

Builder容器的实现要求一系列高级Docker技术。Builder容器继承本地user ID和secret（比如：SSH key， AWS认证