背景
我们机器学习平台上的任务最初是通过 Marathon 启动在Mesos集群上的，分布式训练框架是 ps-lite。但随着技术的变更升级，Mesos+Marathon 组合所用的技术越来越落后，K8s霸主的地位越来越稳固，我们决定用K8s替代 Mesos+Marathon 组合。如何实现将任务从 Mesos 集群以用户无感知的方式迁移到 K8s 集群是我们要解决的首要问题。
旧的启动流程
ps-lite在 Mesos 集群上的启动过程大体可以分为4个步骤（如下图所示）：
- 向Marathon发送请求创建scheduler Task
- Marathon 向 Mesos 发送请求启动 scheduler任务
- scheduler任务后再执行脚本中的 run_worker 方法调用 Marathon 接口创建 worker Task
- Marathon 向 Mesos 发送请求启动 worker 任务
流程倒是不复杂，但第3步的脚本是放在 Docker 镜像中的，脚本中写死必须调用 Marathon 的接口。我们知道 Docker 镜像一旦发布之后就难以再修改，并且由于之前没有定义 Docker 镜像命名规则，很难找到全部的 Docker 镜像并逐一完成修改。由于之前没有任何文字记录,基础镜像的 Tag 也无从查找。
既然修改镜像中脚本的方式不行，那就研究别的办法吧。
不过好在 Marathon 的域名是以参数的形式传入的,如果我能利用“绞杀者模式”，新建一个服务模拟 Marathon 的接口，然后在启动 scheduler 时传入新服务的域名，把创建 worker 的请求导入到新服务，新服务收到请求后再调用 K8s 的接口创建 worker，问题不就解决了吗？
绞杀者模式
通过使用新的应用程序和服务逐渐替换遗留系统的特定功能部件来逐步迁移。由于替换遗留系统的功能，新系统最终将替代旧系统的所有功能，绞杀并允许停用旧系统。
通俗来讲，就是用新的应用程序和服务逐步替换特定的功能。 创建一个外层来拦截请求前往后端旧版系统。 外层可将这些请求路由到旧版应用程序或新服务。 现有功能可逐步迁移到新系统，使用者可继续使用相同的接口，他们并不知道迁移已发生。
新的启动流程
于是，我在 alpha-exptmgr 模块中新建了一个 MarathonController 用于模拟 Marathon 的接口，同时在启动 scheduler 时传入 alpha-exptmgr 的域名，MarathonController 在接收到创建 worker 的请求后，调用 K8s 的接口创建 worker 任务（如下图所示）。于是就成功实现了将任务从 Mesos 集群以用户无感知的方式迁移到 K8s 集群。
总结
- 绞杀者模式在系统升级和任务迁移时可以用到
- 尽量不要在镜像里写死一些可能发生变化的值，最好是以启动参数的形式传入
