时间： 分类：   字数： 842 字 阅读： 2分钟 阅读次数：

migration三种方式

主程序开始时执行

存在的弊端： - 多个POD的情况下，migration执行多次 - 主程序最好有权限隔离，避免破坏性更新数据结构

在CI/CD阶段执行

面临的问题：migration仍需要环境；如果使用serverless，等待时间过长

在gitlab runner机器上，/etc/gitlab-runner/config.toml可以看到concurrent，目前我们的是30

结合K8S InitContainer和Job

initContainer在所有其他container运行前启动，可以运行一个k8s-wait-for，等待Job运行完成。

### 最终实践 使用Job，没有用到initContainer，在gitlab runner阶段执行创建Job和等待Job完成

### Job示例

 apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  activeDeadlineSeconds: 100
  backoffLimit: 4
  completions: 10
  parallelism: 2

运行示例：

 kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml

Job Pod Container restartPolicy 只能设置 OnFailure 和 Never。

backoffLimit是重试次数（默认值是6），重试时间会按指数增长 （从 10 秒、20 秒到 40 秒）最多至 6 分钟。 如果你的 Job 的 restartPolicy 被设置为 “OnFailure”，就要注意运行该 Job 的 Pod 会在 Job 到达失效回退次数上限时自动被终止。这会使得调试 Job 中可执行文件的工作变得非常棘手。

activeDeadlineSeconds不是默认属性，优先级比backoffLimit高。

删除Job可以使用 kubectl delete jobs/pi 或者 kubectl delete -f ./job.yaml

ttlSecondsAfterFinished可以自动清理完成的Job，但是在1.21版本之后才可用

挂起Job可以更改.spec.suspend (true/false)

思考题🤔：使用Job而不是一个Pod的原因？ 答案

### CronJob

 
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

Cron 表达式中的五个部分分别代表：分钟、小时、日、月、星期

spec.concurrencyPolicy (Allow, Forbid, Replace)：由于定时任务的特殊性，很可能某个 Job 还没有执行完，另外一个新 Job 就产生了。这时候，可以通过该字段来定义具体的处理策略。

0%