扩展新类型的Kustomize Image Transformer
是否有一种方法可以扩展Kustomize Image Transformer以识别更多的键作为图像说明器?示例/transformerconfigs/readme.md#name-reference-transformer“ rel =“ noreferrer”> namereference
transformer 适用于nameprefix
namesuffix
namesuffix < /代码>变形金刚。
但是它仅支持嵌入podtemplate
的类型一些硬编码类型。不使用podtemplate
的CRD,尽管它们是非常常见的非常常见的。示例包括kube-prometheus
prometheus
和artermanager
资源和opentelemetry-operator
opentelemetrycollector
资源。
结果,您必须保持一堆凌乱的战略合并或JSON补丁,以将这些图像带有可信赖的注册表或类似图像。
这是问题所在的一个例子。假设我必须用myTrusted.Registred.Registred
用图像:
Transformer列表部署所有内容。为了简洁起见,我将使用一个虚拟的,将所有匹配的图像替换为匹配
,所以我不必全部列出它们:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- "https://github.com/prometheus-operator/kube-prometheus"
images:
- name: "(.*)"
newName: "MATCHED"
newTag: "fake"
您希望结果中唯一的图像会是“匹配:假”,但实际上是:
$ kustomize build | grep 'image: .*' | sort | uniq -c
12 image: MATCHED:fake
1 image: quay.io/prometheus/alertmanager:v0.24.0
1 image: quay.io/prometheus/prometheus:v2.34.0
类型中的图像:Prometheus
and 类型:AlertManager
资源不匹配,因为它们不是> podtemplate
。
您必须为这些编写一个自定义补丁,它会像kustomization.yaml
content:
patches:
- path: prometheus_image.yaml
target:
kind: Prometheus
- path: alertmanager_image.yaml
target:
kind: Alertmanager
with prometheus_image.yaml
:
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: ignored
spec:
image: "MATCHED:fake"
和arper> artermanager_image.yamage.yaml
:
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
name: ignored
spec:
image: "MATCHED:fake"
这是IMO可怕的。
我想要能够做的就是告诉kustomize
的图像变压器,就像可以使用自定义配置毫米生成器等扩展,例如以下 unsupported and imaginary pseudocode modeled on the existing namereference
变形金刚
imageReference:
- kind: Prometheus
fieldSpecs:
- spec/image
Is there a way to extend the kustomize image transformer to recognise more keys as image specifiers? Like the nameReference
transformer does for the namePrefix
and nameSuffix
transformers.
The Kustomize images:
transformer is very useful for image replacement and registry renaming in k8s manifests.
But it only supports types that embed PodTemplate
and maybe some hardcoded types. CRDs that don't use PodTemplate
are not handled despite them being very common. Examples include the kube-prometheus
Prometheus
and AlertManager
resources and the opentelemetry-operator
OpenTelemetryCollector
resource.
As a result you land up having to maintain a bunch of messy strategic merge or json patches to prefix such images with a trusted registry or the like.
Here's an example of the problem as things stand. Say I have to deploy everything prefixed with mytrusted.registry
with an images:
transformer list. For the sake of brevity here I'll use a dummy one that replaces all matched images with MATCHED
, so I don't have to list them all:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- "https://github.com/prometheus-operator/kube-prometheus"
images:
- name: "(.*)"
newName: "MATCHED"
newTag: "fake"
You'd expect the only images in the result to be "MATCHED:fake", but in reality:
$ kustomize build | grep 'image: .*' | sort | uniq -c
12 image: MATCHED:fake
1 image: quay.io/prometheus/alertmanager:v0.24.0
1 image: quay.io/prometheus/prometheus:v2.34.0
the images in the kind: Prometheus
and kind: AlertManager
resources don't get matched because they are not a PodTemplate
.
You have to write a custom patch for these, which creates mess like this kustomization.yaml
content:
patches:
- path: prometheus_image.yaml
target:
kind: Prometheus
- path: alertmanager_image.yaml
target:
kind: Alertmanager
with prometheus_image.yaml
:
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: ignored
spec:
image: "MATCHED:fake"
and alertmanager_image.yaml
:
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
name: ignored
spec:
image: "MATCHED:fake"
which is IMO ghastly.
What I want to be able to do is tell Kustomize
's image transformer about it, like it can be extended with custom configmap generators, etc, like the following unsupported and imaginary pseudocode modeled on the existing nameReference
transformer
imageReference:
- kind: Prometheus
fieldSpecs:
- spec/image
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
写完这篇文章后,我终于偶然发现了答案:kustomize确实支持 Image Transformer Configs 。
表达上述表达的正确方法是
image_transformer_config.yaml
包含的文件:kustomization.yaml
参考它的条目,例如当导入为<时,它似乎正常工作代码>组件。
甚至是所以我要怪这个是盲人的。
Just after writing this up I finally stumbled on the answer: Kustomize does support image transformer configs.
The correct way to express the above would be a
image_transformer_config.yaml
file containing:and a
kustomization.yaml
entry referencing it, likeThis appears to work fine when imported as a
Component
too.It's even pointed out by the transformer docs so I'm going to blame this one on being blind.