拥抱Kubernetes,再见了,SpringBoot cronjob

项目开发中总是需要执行一些定时任务，比如定时处理数据之后发送邮件，定时更新缓存等等。

Java定时任务

基于 java.util.Timer 定时器，实现类似闹钟的定时任务
使用 Quartz、elastic-job、xxl-job 等开源第三方定时任务框架，适合分布式项目应用
使用 Spring 提供的一个注解： @Schedule

项目框架使用的是SpringBoot,所以之前定时任务使用的是SpringBoot中的@Scheduled。可是这种方式并不适合我们现在的cloud环境，为了更加cloud native一点,我删除了使用SpringBoot写的37个定时任务，改为使用Kubernetes cronjob的方式。

定时任务代码编写

public interface Command {
    /**
     * 遵循Unix约定，如果命令执行正常，则返回0；否则为非0。
     */
    int execute(String... args);
}

首先定义一个接口，所有具体的定时任务都必须实现该接口。接下来是具体的某一个定时任务

@Component
@Slf4j
public class ProjectCommandLineRunner implements CommandLineRunner {

  Map<String, Command> commandMap = new HashMap<>();

  @Autowired
  private SendEmailCommand sendEmailCommand;

  @PostConstruct
  private void init() {
    commandMap.put("sendEmail", sendEmailCommand);
  }

  @Override
  public void run(String... args) throws Exception {

    if (args.length == 0) {
        return;
    }

    if (!commandMap.containsKey(args[0])) {
        log.error("'{}' command not found", args[0]);
        System.exit(-1);
    }

    Command command = commandMap.get(args[0]);

    String[] arguments = Arrays.copyOfRange(args, 1, args.length);

    System.exit(command.execute(arguments));
  }
}

@Component
@Slf4j
public class SendEmailCommand implements Command {

  @Override
  public int execute(String... args) {

    try {
      // 省略业务逻辑代码

      log.info("send email success");

      return 0;

    } catch (Exception e) {
      log.error("send email error", e);
      return -1;
    }
  }
}

上面的代码我们采用了策略模式，后面即使新增其他定时任务也只是会改动很少的代码。

本地调试

cronjob不用打包成单独的镜像，它直接和我们的web应用公用同一个镜像,本地调试的时候也是极为方便的,只需要我们启动SpringBoot Application时指定参数即可

调试定时任务

对应的定时任务执行完成之后就会，application就会退出。

cronjob yaml

一个基本的cronjob yaml如下所示

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: send-email-job
spec:
  failedJobsHistoryLimit: 3
  successfulJobsHistoryLimit: 1
  startingDeadlineSeconds: 180
  concurrencyPolicy: Forbid
  schedule: "0 4 * * 1-5"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: send-email-job
              image: harbor.xxx.com/think123/project
              imagePullPolicy: Always
              command: ["java"]
              args: ["-jar","/app/target/think123-task.jar","sendEmail"]
              envFrom:
                - configMapRef:
                    name: smcp-config
                - secretRef:
                    name: smcp-service-secret
              resources:
                requests:
                  cpu: "250m"
                  memory: 1024Mi
                limits:
                  cpu: "500m"
                  memory: 1024Mi
          restartPolicy: Never

在定时任务中,可能某个job还没有执行完，另外一个job就产生了。这个时候我们可以通过spec.concurrencyPolicy字段来定义具体的处理策略。

concurrencyPolicy=Allow，这也是默认情况，这意味着这些Job可以同时存在；
concurrencyPolicy=Forbid，这意味着不会创建新的Pod，该创建周期被跳过；
concurrencyPolicy=Replace，这意味着新产生的Job会替换旧的、没有执行完的Job

几个关键参数解释如下:

schedule : Unix Cron格式的表达式，cron表达式中的五个部分分别代表：分钟、小时、日、月、星期。
startingDeadlineSeconds ：表示在过去的多少秒(这里设置的180)里，如果job创建失败的数据达到了100次，那么这个job就不会被创建执行了。
restartPolicy: 重启策略(有Never和OnFailure两个选项)。当job正常结束之后是否需要重启

restartPolicy在Job对象里只允许被设置为Never和OnFailure；而在Deployment对象里，restartPolicy则只允许被设置为Always。

实际上在jobTemplate.spec.template中可以像pod中那样，指定volume,指定nodeSelector，都是可以的。这个template实际上就是指的pod的template。比如上面示例我们就指定了环境变量，我们的一些参数就可以通过环境变量进行注入，比如redis地址，mongodb用户名密码等。

实际使用

上面的yaml虽然可以直接使用，但是我们用不着每个job都去写一份同样的模板，实际中我们会使用Kustomize控制模板来生成job。比如我们有一个新的任务，是计算热点文章并更新redis

对于这个任务而言，变化的主要有两个地方，第一个是定时任务的时间不同，第二个是指定的参数不同。所以我们的每个任务只需要更新这两个参数就行了

关于kustomize的使用可以参考我之前的kustomize的介绍,打包的话可以看看springboot build的文章

对于模板设定，我们形成了下面的目录结构

$ tree
.
|-- base
|   |-- cronjob.yaml
|   `-- kustomization.yaml
`-- overlay
    `-- beta
        |-- kustomization.yaml
        `-- send-email-patch-args.yaml

cronjob.yaml作为所有job的模板,而send-emial-patch-args.yaml则是针对具体的job的一个替换。涉及到的yaml文件内容如下:


# base/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- cronjob.yaml


# base/cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: think123-
spec:
  failedJobsHistoryLimit: 3
  successfulJobsHistoryLimit: 1
  startingDeadlineSeconds: 180
  concurrencyPolicy: Forbid
  schedule: "0 0 1 * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: cron-job
              image: harbor.xxx.com/think123/my-task
              imagePullPolicy: Always
              args:
                - "help"
              envFrom:
                - configMapRef:
                    name: smcp-config
                - secretRef:
                    name: smcp-service-secret
              resources:
                requests:
                  cpu: "250m"
                  memory: 1024Mi
                limits:
                  cpu: "500m"
                  memory: 1024Mi
          restartPolicy: Never


# overlay/beta/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

nameSuffix: send-email-job

resources:
- ../../base/

patchesStrategicMerge:
  - send-email-patch-args.yaml


# overlay/beta/send-email-patch-args.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: think123-
spec:
  schedule: "0 4 * * 1-5"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: send-email-job
              args: ["sendEmail"]

你可以使用kustomize build beta > send-email-cron-job.yaml命令,然后查看send-email-cron-job.yaml文件，就可以看到生成的具体的cronjob的详细。

kustomize的文档可以参考: https://kubernetes-sigs.github.io/kustomize/api-reference/

为什么要用Kubernetes Cron Job

使用SpringBoot的定时任务不香吗？为什么要还要引入新的东西。再想这个问题的时候，想想为什么你在SpringBoot中不写Servlet,不是一样可以吗？

其实想想还是有原因的，首先我们的服务是分布式的，我们的定时任务应该只需要运行一次，而不是每个实例都运行一次，如果用SpringBoot的task那么我们需要用代码来保证这个行为。

如果引入分布式任务框架，又是引入了一堆其他新的东西，比如注册中心等等，而且还要去学习一项新的技术。

而我们的服务由于是通过Kubernetes部署的，我们的job再使用Kubernetes来，更是相得益彰。