OpenShift CronJob 能否从 ImageStream 中受益?
Can an OpenShift CronJob benefit from ImageStream?
我的 CronJob 在不使用图像流的情况下工作正常。
作业 运行 每 15 分钟执行一次,并且始终拉取标记图像,例如my-cron:stable
.
由于镜像总是被拉取并且调度告诉集群什么时候运行我的工作,知道我的镜像有更新版本对我有什么好处?
如果图像发生变化并且我的作业有一个 运行ning 实例,我希望使用当前版本的图像完成该作业。
在下一个预定 运行 中拉取更新的映像 (AlwaysPull
)。所以我似乎没有获得太多对 cron 作业的图像流的跟踪更改。
ImageStream 根据 https://docs.openshift.com/container-platform/4.7/openshift_images/image-streams-manage.html 仅触发 BuildConfigs 和 DeploymentConfigs。
上游 kubernetes 没有 ImageStream 的概念,所以没有 'vanilla' 资源类型的触发。 CronJob 在 openshift 和 kubernetes(apiVersion:batch/v1beta1)中都使用,据我所知,访问图像流的唯一方法是使用内部注册表的完整路径,这并不方便。如果图像流已更新,您的 cronjob 不会重新启动或不会因某种原因停止,因为从 kubernetes 的角度来看,图像仅在 cronjob 被触发时才会被拉出,之后它只是等待作业完成。
如我所见 - 您不会从使用图像流中获得太多收益,因为要点之一,即使用触发器的能力,不适用于 cronjobs。在 CronJobs 中使用它的唯一原因是如果您出于某种原因直接推送到内部注册表,但这也是一种不好的做法。
参考以下链接:
这里引用redhat解决方案:
Resolution
When using an image stream inside the project to run a cronjob,
specify the full path of the image:
[...]
spec:
jobTemplate:
spec:
template:
spec:
containers:
image: docker-registry.default.svc:5000/my-app-namespace/cronjob-image:latest
name: cronjob-image
[...]
Note that you can also put the ':latest' (or a specific tag) after the
image.
In this example, the cronjob will use the imagestream cronjob-image
from project my-app-namespace:
$ oc get is -n my-app-namespace [...]
imagestream.image.openshift.io/cronjob-image
docker-registry.default.svc:5000/my-app-namespace/cronjob-image
latest 27 minutes ago
Root Cause
The image was specified without its full path to the internal docker
registry. If the full path is not used (i.e. putting only
cronjob-image, OpenShift won't be able to find it.[...]
通过使用 ImageStream 引用,您可以避免在 Cron 作业定义中包含容器映像存储库主机名主机名和端口以及项目名称。
docker 存储库引用如下所示:
image-registry.openshift-image-registry.svc:5000/my-project/my-is:latest
放置在 Cron 作业上的等效注释的值如下所示:
[
{
"from": {
"kind": "ImageStreamTag",
"name": "my-is:latest"
},
"fieldPath": "spec.jobTemplate.spec.template.spec.containers[?(@.name==\"my-container\")].image"
}
]
一方面,这更长。另一方面,它包含的冗余信息较少。
因此,与其他类型的 kubernetes 资源相比,Image Streams 没有为 Cron Jobs 添加大量功能。但是,如果您将 Cron Job YAML 保留在 Git 中并希望将其应用于多个不同的项目,则不必对项目名称进行硬编码可能会受益。
包含 pod 的 Kubernetes-native 资源可以通过添加 image.openshift.io/triggers
注释自动更新以响应图像流标签更新。
这个注解可以放在 CronJobs、Deployments、StatefulSets、DaemonSets、Jobs、ReplicationControllers 等上
最简单的方法是使用 oc
命令。
$ oc set triggers cronjob/my-cronjob
NAME TYPE VALUE AUTO
cronjobs/my-cronjob config true
$ oc set triggers cronjob/my-cronjob --from-image=my-is:latest -c my-container
cronjob.batch/my-cronjob updated
$ oc set triggers cronjob/my-cronjob
NAME TYPE VALUE AUTO
cronjobs/my-cronjob config true
cronjobs/my-cronjob image my-is:latest (my-container) true
oc set triggers
命令的作用是将注释添加到 CronJob,我们可以通过以下方式检查它:
$ oc get cronjob/my-cronjob -o json | jq '.metadata.annotations["image.openshift.io/triggers"]' -r | jq
[
{
"from": {
"kind": "ImageStreamTag",
"name": "my-is:latest"
},
"fieldPath": "spec.jobTemplate.spec.template.spec.containers[?(@.name==\"my-container\")].image"
}
]
这在 Images - Triggering updates on image stream changes 中有记录 - 但文档中的语法似乎是错误的,所以如果您发现您手写的注释不起作用,请使用 oc set triggers
。
我的 CronJob 在不使用图像流的情况下工作正常。
作业 运行 每 15 分钟执行一次,并且始终拉取标记图像,例如my-cron:stable
.
由于镜像总是被拉取并且调度告诉集群什么时候运行我的工作,知道我的镜像有更新版本对我有什么好处?
如果图像发生变化并且我的作业有一个 运行ning 实例,我希望使用当前版本的图像完成该作业。
在下一个预定 运行 中拉取更新的映像 (AlwaysPull
)。所以我似乎没有获得太多对 cron 作业的图像流的跟踪更改。
ImageStream 根据 https://docs.openshift.com/container-platform/4.7/openshift_images/image-streams-manage.html 仅触发 BuildConfigs 和 DeploymentConfigs。 上游 kubernetes 没有 ImageStream 的概念,所以没有 'vanilla' 资源类型的触发。 CronJob 在 openshift 和 kubernetes(apiVersion:batch/v1beta1)中都使用,据我所知,访问图像流的唯一方法是使用内部注册表的完整路径,这并不方便。如果图像流已更新,您的 cronjob 不会重新启动或不会因某种原因停止,因为从 kubernetes 的角度来看,图像仅在 cronjob 被触发时才会被拉出,之后它只是等待作业完成。
如我所见 - 您不会从使用图像流中获得太多收益,因为要点之一,即使用触发器的能力,不适用于 cronjobs。在 CronJobs 中使用它的唯一原因是如果您出于某种原因直接推送到内部注册表,但这也是一种不好的做法。
参考以下链接:
这里引用redhat解决方案:
Resolution
When using an image stream inside the project to run a cronjob, specify the full path of the image:
[...] spec: jobTemplate: spec: template: spec: containers: image: docker-registry.default.svc:5000/my-app-namespace/cronjob-image:latest name: cronjob-image [...]
Note that you can also put the ':latest' (or a specific tag) after the image.
In this example, the cronjob will use the imagestream cronjob-image from project my-app-namespace:
$ oc get is -n my-app-namespace [...] imagestream.image.openshift.io/cronjob-image docker-registry.default.svc:5000/my-app-namespace/cronjob-image latest 27 minutes ago
Root Cause
The image was specified without its full path to the internal docker registry. If the full path is not used (i.e. putting only cronjob-image, OpenShift won't be able to find it.[...]
通过使用 ImageStream 引用,您可以避免在 Cron 作业定义中包含容器映像存储库主机名主机名和端口以及项目名称。
docker 存储库引用如下所示:
image-registry.openshift-image-registry.svc:5000/my-project/my-is:latest
放置在 Cron 作业上的等效注释的值如下所示:
[
{
"from": {
"kind": "ImageStreamTag",
"name": "my-is:latest"
},
"fieldPath": "spec.jobTemplate.spec.template.spec.containers[?(@.name==\"my-container\")].image"
}
]
一方面,这更长。另一方面,它包含的冗余信息较少。
因此,与其他类型的 kubernetes 资源相比,Image Streams 没有为 Cron Jobs 添加大量功能。但是,如果您将 Cron Job YAML 保留在 Git 中并希望将其应用于多个不同的项目,则不必对项目名称进行硬编码可能会受益。
包含 pod 的 Kubernetes-native 资源可以通过添加 image.openshift.io/triggers
注释自动更新以响应图像流标签更新。
这个注解可以放在 CronJobs、Deployments、StatefulSets、DaemonSets、Jobs、ReplicationControllers 等上
最简单的方法是使用 oc
命令。
$ oc set triggers cronjob/my-cronjob
NAME TYPE VALUE AUTO
cronjobs/my-cronjob config true
$ oc set triggers cronjob/my-cronjob --from-image=my-is:latest -c my-container
cronjob.batch/my-cronjob updated
$ oc set triggers cronjob/my-cronjob
NAME TYPE VALUE AUTO
cronjobs/my-cronjob config true
cronjobs/my-cronjob image my-is:latest (my-container) true
oc set triggers
命令的作用是将注释添加到 CronJob,我们可以通过以下方式检查它:
$ oc get cronjob/my-cronjob -o json | jq '.metadata.annotations["image.openshift.io/triggers"]' -r | jq
[
{
"from": {
"kind": "ImageStreamTag",
"name": "my-is:latest"
},
"fieldPath": "spec.jobTemplate.spec.template.spec.containers[?(@.name==\"my-container\")].image"
}
]
这在 Images - Triggering updates on image stream changes 中有记录 - 但文档中的语法似乎是错误的,所以如果您发现您手写的注释不起作用,请使用 oc set triggers
。