调度定期作业

Goal

按计划运行的工作，对触发重叠或错过时会发生什么有明确的答案。

Before you start

• 一个运行工作并退出的镜像。
• 关于时区的决定。它在描述中说明，而不是从平台进程运行的环境中继承。
• 关于重叠触发的决定，以及错过触发可以延迟多久才开始。

Dashboard

Steps

1. 打开 计划工作 并选择 新建计划。
2. 给它一个名称、cron 表达式和时区。
3. 填写它运行的作业：镜像、命令、网络、资源和重试限制。
4. 选择重叠触发时的操作，以及错过触发可以延迟多久才开始。
5. 保存，并确认显示的下一次触发时间是您想要的。

YAML manifest

Steps

1. 编写一个带有计划和作业模板的 kind: CronJob 文档。
2. 应用它。每个字段都在 cronjob 参考。

REST API

Steps

1. 使用计划和作业模板的 POST /api/v1/cronjobs。
2. GET /api/v1/cronjobs/{name} 以查看存储的计划及其状态。
3. PUT /api/v1/cronjobs/{name} 以更改它 — 包括暂停它。

CLI

Steps

1. 没有用于计划工作的 CLI 命令；使用 API 或仪表板。
2. odysseus spec-audit 报告存储的规范，其中包括计划。

apiVersion: odysseus/v1
kind: CronJob
metadata:
  name: addriva-etl-ingest
  labels: {app: addriva-etl-ingest, project: addriva}
spec:
  schedule: "17 1 1 * *"
  # no timezone: UTC, matching the retired host crontab
  concurrencyPolicy: skip
  startingDeadlineSeconds: 300
  suspend: false
  jobTemplate:
    image: registry.delta-telematics.ca/addriva/etl:0.1.0
    placement: {node: vps-71623e00}
    networks: [addriva-internal]
    command: ["ingest", "--sources", "oda,geoyukon,adresses_qc", "--version", "ODA_v1_2021"]
    environment:
      ADDRIVA_S3_ENDPOINT: "http://addriva-seaweedfs:8333"
      ADDRIVA_S3_BUCKET: "addriva-raw"
      ADDRIVA_OS_HOST: "http://addriva-opensearch:9200"
      ADDRIVA_OS_USER: "admin"
    secrets:
      - vaultPath: deployments/addriva-etl
        rotation: restart
    resources:
      limits:   {cpu: "2", memory: 3500Mi}
      requests: {cpu: 500m, memory: 1Gi}
    restartPolicy: "no"
    backoffLimit: 2
    activeDeadlineSeconds: 14400
    ttlAfterFinished: 4392h

Validated against CronJobManifest · testdata/docs-examples/monthly-cronjob.yaml

Verify

计划显示其下次触发在您期望的时间，在您设置的时区，第一次运行出现在其历史记录中。

Evidence this worked

GET /api/v1/cronjobs/{name}下的运行历史显示运行编号在同一个作业上上升，而不是每次触发一个新作业。这是故意的：每次触发一个新名称会给每个运行相同的编号，并将保留限制分散在无限多的名称中。

When it fails

• 计划被拒绝。 语法、接受的字段值和故意拒绝在 cronjob 参考。
• 一个触发没有发生。 它与一个运行重叠，您的策略是跳过它，或者在平台关闭时错过，并晚于您允许的窗口到达。
• 作业模板设置身份或状态。 计划拥有这些；作者的值被归零而不是拒绝。
• 每个代码：拒绝和更改。