使用 K8s 进行作业调度实战分享 _K8s

最近在公司的数据同步项目（以下简称 ZDTP）中，需要使用到分布式调度数据同步执行单元，目前使用的方案是将数据同步执行单元打包成镜像，使用 K8s 进行调度。
在 ZDTP 中，数据同步的动作可抽象成一个执行单元（以下称为 worker），类似于线程执行单元 Runnable ， Runnable 放入一个队列中等待线程的调度执行，执行完 Runnable 即完成了它的使命。当用户在 ZDTP 控制台中创建同步任务并启动任务时，会根据同步任务的配置，产生若干个用于该任务的 worker ，假设这些 worker 都在本地执行，可以将其包装成一个 Runnable ，然后创建一个线程执行，如下图表示：

文章插图

但是在单机模式下，就会遇到性能瓶颈，此时就需要分布式调度，将 worker 调度到其他机器执行：

文章插图

问题是我们如何将 worker 更好地调度到其它机器中执行呢？
Worker 部署方式调研1、基于虚拟机部署 Worker
Worker 在提前创建好的虚拟机中运行，任务启动时需要根据当前 Worker 负载情况进行选择空闲的 Worker ，相当于 Worker 是以 Agent 的形式运行，如下图表示：

文章插图

伴随而来的缺点主要有以下几点：

Worker Agent 数量相对固定，虚拟机创建成本高，扩/缩容麻烦；
任务运行情况依赖 zk 监听机制，如果某个任务在运行中挂掉了，需要自行实现故障转移与自动重启机制，增加开发周期；
Worker Agent 负载获取逻辑需要项目实现，精确获取负载信息实现难度大，增加开发周期。

2、基于 K8s 部署 Worker
将 Worker 打包成 Docker 镜像，使用 K8s 对 worker 容器进行调度作业，并且一个 Worker 只运行一个任务，如下图表示：

文章插图

使用 K8s 的优点如下：

使用 K8s 集群调度的 Worker 容器具备故障恢复功能，只要将 Pod 的重启策略设置为 restartPolicy=Always ，无论 Worker 容器在运行过程中发生什么异常， K8s 都会自动尝试重启 Worker 容器，大大减少了运维成本，提高了数据同步的高可用性；
自动实现负载，比如当某个节点负载高，就会将 Worker 容器调度到负载低的节点上，更重要的是，某个节点宕机，其上的工作负载会被 K8s 自动将其转移到其它节点上面；
Worker 的生命周期完全交由 K8s 集群管理，只需调用相关接口即可清楚 Worker 运行情况，大大减少开发周期。

K8s 容器调度方案调研K8s 集群的调度对象是 Pod ，调度方式有多种，这里主要介绍以下几种方式：
1、Deployment（全自动调度）
在讲 Deployment 前，先来说下 Replica Set ，它是 K8s 一个非常重要的概念，它是在 Pod 这个抽象上更为上层的一个抽象，一般大家用 Deployment 这个抽象来做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元。它可以定义某种 Pod（比如包装了 ZDTP Worker 容器的 Pod）在任意时刻都保持符合 Replica Set 设定的预期值，比如 Replica Set 可预期设定 Pod 副本数，当 k8s 集群定期巡检发现某种 Pod 的副本数少于 Replica Set 设定的预期值，它就会按照 Replica Set 设定的 Pod 模版创建 Pod 实例，使得 Pod 的数量维持在预期值，也是通过 Replica Set 的特性，实现了集群的高可用性，同时减少了运维成本。
Deployment 内部使用了 Replica Set 来实现，他们之间高度相似，也可以将 Deployment 看作是 Replica Set 的升级版本。