kl个人博客 首页>>分布式,架构>>给 xxljob 加一个 k8s 执行器

给 xxljob 加一个 k8s 执行器

给 xxljob 加一个 k8s 执行器

前言

xxljob 是采用 java 开发的开源的任务调度系统,架构上分为调度管理器、执行器,目前除了官方提供的 java 执行器外,也有 go 开发者提供了 go 语言的执行器(看了 go 执行器的代码,除了任务日志没有实现,其他功能实现都比较完整)。 xxljob 在设计上,抽象出了执行器的接口,所以实现一个语言的执行器并不复杂,这里主要探索下,如何利用 k8s 的 pod 的能力,使用 xxljob 调度 pod 运行,实现一个通用的和语言无关的执行器

执行器接口

实现一个 xxljob 的执行器,如果不考虑执行器节点自动注册,只需要实现如下五个接口即可:
  • /beat :执行器心跳
  • /idleBeat :执行器的某个 job 是否空闲
  • /run :触发 job 执行
  • /kill :终止正在执行的 job
  • /log :查看本节点执行器的 job 执行日志
不过一些调度策略则需要每个执行器自行实现了,比如【阻塞处理策略】,当同一个job 的任务还在执行,突然又收到了一个新的,是串行执行,还是停止之前的任务,或者丢弃当前的任务,这些实现都需要执行器考虑。

k8s 执行器设计

上面已经了解了实现一个执行器的要素。但是让 k8s 实现这些接口,难度有点高。然后又希望不破坏现有的 xxljob 的设计,怎么办?代理解决。可以直接采用现有的 java 执行器,创建一个 job 任务,这个 job 任务专门发起 k8s 的调度,具体的调度 pod 信息通过调度参数传递,下面来实现下,以及看下需要注意的问题。

1、在 xxl-job-admin 模块新增执行器

为了尽量减少系统维护的复杂度,我们可以将代理调度 k8s 的执行器,直接集成到 admin 模块,启动 admin 的时候,自动注册 k8s 执行器。



2、引入 k8s-client-java ,使用 service account 机制与 k8s 交互

		<dependency>
			<groupId>io.fabric8</groupId>
			<artifactId>kubernetes-client</artifactId>
			<version>5.4.0</version>
		</dependency>

这个客户端提供了完整的和 k8s-api-server 交互能力,使用这个客户端,基于 k8s 的 service account 认证,可以轻松在 xxljob 所在 namespace 内完成 pod 的生命周期管理。引入依赖后,首先创建 client 实例:
/**
 * @author kl (http://kailing.pub)
 * @since 2021/6/4
 */
@Configuration
public class KubernetesClientConfig {

    @Bean
    public KubernetesClient kubernetesClient(){
        return new DefaultKubernetesClient(Config.autoConfigure(null));
    }

}
这里初始化客户端时,采用了自动发现配置的模式,如果是本机开发时,就会自动寻找你本机的 kubectl 配置,当 xxljob 部署到 k8s 内时,如果找不到本地的就会尝试寻找 service account 创建出来的配置,然后从环境变量中自发现 k8s 集群的链接地址。所以无论是开发环境还是线上环境,都不用配置k8s 的链接认证信息。但是,部署到 k8s 时,因为需要借助 k8s 的 service account 机制与 k8s 交互,需要多定义一个 service account 的权限声明,可参考如下:
# In GKE need to get RBAC permissions first with
# kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin [--user=|--group=]

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: xxljob

---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: xxljob
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get","list","watch"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["watch"]
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: xxljob
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: xxljob
subjects:
- kind: ServiceAccount
  name: xxljob

3、编写代理执行器调度代码

/**
 * @author kl (http://kailing.pub)
 * @since 2021/5/28
 */
@Component
public class KubernetesExecutorHandler {

    private static final Logger logger = LoggerFactory.getLogger(KubernetesExecutorHandler.class);
    private static final String NAMESPACE = "xxl-job";
    private final KubernetesClient client;

    public KubernetesExecutorHandler(KubernetesClient client) {
        this.client = client;
    }

    @XxlJob(value = "callK8s")
    public void callK8s() throws InterruptedException {
        String podResource = XxlJobHelper.getJobParam();
        Pod pod = Serialization.unmarshal(podResource, Pod.class);
        pod.getSpec().setRestartPolicy("Never");//这里强制设置重启策略为不重启
        pod = client.pods().inNamespace(NAMESPACE).create(pod);
        client.resource(pod).waitUntilCondition(pod1 -> pod1.getStatus().getPhase().equals("Succeeded") || pod1.getStatus().getPhase().equals("Failed"), 2, TimeUnit.MINUTES);
        String log = client.pods().inNamespace(NAMESPACE).withName(pod.getMetadata().getName()).getLog();
        XxlJobHelper.log(log); //记录 pod 日志到 xxl-job
        logger.info(log);
        client.resource(pod).delete();
    }

}

如上,一个简版的 k8s 执行器便完成了,使用时,通过定义 bean 模式的 job ,然后选择 k8s 执行器,jobHandler 名称和填上 callk8s,通过job 参数传递 pod 调度信息,如:

这里定义了一个打印 当前时间和当前环境变量的 pod 任务,执行完成后,就可以从 job 的日志里看到执行结果了,如:

结语

目前的实现方式,单纯从兼容 xxljob 现有的架构模式,以及现有的实现出发的,所以采用了 java 代理执行器代为调度 pod 的方案,基本继承了所有 java 执行器的功能,比如 job 执行日志记录,并发执行策略等。需要注意的是,因为是单 handler 实现,每个job 都会用同一个 handler 去运行,所以创建任务的时候并发策略这块只能选择单机串行执行,否则非常容易丢任务。另一个需要考虑的问题,如果代理执行器非正常关闭,pod 没来的及删除就挂了,这个时候需要启动一个巡检的线程,检测已经完成或者已经出错的 pod ,然后清理掉。
kl个人博客