扩展新类型的Kustomize Image Transformer

发布于 2025-01-22 16:10:05 字数 2808 浏览 1 评论 0原文

是否有一种方法可以扩展Kustomize Image Transformer以识别更多的键作为图像说明器?示例/transformerconfigs/readme.md#name-reference-transformer“ rel =“ noreferrer”> namereference transformer 适用于nameprefix namesuffix namesuffix < /代码>变形金刚。

对于在K8s中重命名的图像更换和注册表非常有用。

但是它仅支持嵌入podtemplate 的类型一些硬编码类型。不使用podtemplate的CRD,尽管它们是非常常见的非常常见的。示例包括kube-prometheus prometheusartermanager资源和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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

七颜 2025-01-29 16:10:05

写完这篇文章后,我终于偶然发现了答案:kustomize确实支持 Image Transformer Configs

表达上述表达的正确方法是image_transformer_config.yaml包含的文件:

images:
  - path: spec/image
    kind: Prometheus
  - path: spec/image
    kind: Alertmanager

kustomization.yaml参考它的条目,例如

configurations:
  - image_transformer_config.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:

images:
  - path: spec/image
    kind: Prometheus
  - path: spec/image
    kind: Alertmanager

and a kustomization.yaml entry referencing it, like

configurations:
  - image_transformer_config.yaml

This 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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文