我在 GKE 集群内运行两个容器的 Kubernetes CronJob 遇到了一些问题。
两个容器中的一个实际上正在执行必须由 CronJob 完成的工作。
这很好用。它在应该启动时启动,完成工作然后终止。到目前为止一切都很好。
似乎导致一些问题的是第二个容器,它是一个用于访问数据库实例的边车容器。这不会终止并且似乎会导致 CronJob 本身不会终止的问题。这是一个问题,因为我看到随着时间的推移运行作业实例的积累。
有没有一种方法可以将 Kubernetes 批处理 CronJob 配置为在其中一个容器成功执行时终止
apiVersion: batch/v1
kind: CronJob
metadata:
name: chron-job-with-a-sidecar
namespace: my-namespace
spec:
# ┌───────────── minute (0 - 59)
# │ ┌───────────── hour (0 - 23)
# │ │ ┌───────────── day of the month (1 - 31)
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │ 7 is also Sunday on some systems)
# │ │ │ │ │ OR sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
schedule: "0 8 * * *" # -> Every day At 8AM
jobTemplate:
metadata:
labels:
app: my-label
spec:
template:
containers:
# --- JOB CONTAINER -----------------------------------------------
- image: my-job-image:latest
imagePullPolicy: Always
name: my-job
command:
- /bin/sh
- -c
- /some-script.sh; exit 0;
# --- SIDECAR CONTAINER ----------------------------------------------
- command:
- "/cloud_sql_proxy"
- "-instances=my-instance:antarctica-south-3:user=tcp:1234"
# ... some other settings ...
image: gcr.io/cloudsql-docker/gce-proxy:1.30.0
imagePullPolicy: Always
name: cloudsql-proxy
# ... some other values ...
不,严格来说,一旦“主”容器完成,就没有办法让 Kubernetes 自动停止边车容器。
我能想到的最接近“kubernetes-native”的解决方案是将 CronJob
concurrencyPolicy
设置为 Replace
(参见 CronJobSpec)。它不会在完成后停止 Sidecar,但至少每个新工作都会覆盖前一个工作,因此工作不会累积。不幸的是,使用此解决方案,您将失去工作经历。
如果此解决方案不符合您的需求,您将需要在容器之间实现某种形式的通信,但 Kubernetes 本身并没有内置此类内容。不过,有一些外部工具可以提供帮助,例如kubexit.
就是这样:
apiVersion: batch/v1
kind: CronJob
metadata:
name: sidecar-example
spec:
schedule: '0 0 * * 5'
jobTemplate:
spec:
template:
spec:
restartPolicy: Never
shareProcessNamespace: true
containers:
- name: myjob
image: myjob:latest
command: ['/bin/sh', '-c']
args:
- |
do-cron-job.sh; \
killall -SIGTERM sidecar-process
- name: sideacr
image: mysidecar:latest
使用
shareProcessNamespace: true
并在退出时终止边车容器的主进程。
让 https://kubernetes.io/docs/tasks/job/pod-failure-policy/ 功能变得稳定。它将有助于边车容器的非 0 退出代码。