Support the ability to replace the image registry domain

[vsabella]

kustomize/api/types/image.go

Line 8 in f61b075

type Image struct {

In our usage of Kustomize, we use two different registries for images depending on the deployment region (due to use of sovereign clouds).

We are looking to simplify our kustomize so we can have a singe component to replace all instances of with in a single place, instead of the newName tag everywhere for our hundreds of containers.

We're happy to submit a patch but are looking for the best way to solve this problem that is in line with Kustomize philosophy.

1. We could amend the image.go to support a new field (newDomain) and update the processing of image: newImage/NewDigest/newTag to also support newRegistry by processing image tags into the format specified by cncf: (https://github.com/distribution/distribution/blob/main/reference/regexp.go)

2. We could add regex capture group / capture replace support to the image replacement - so we can capture part of the old value and re-use it in the new value.

3. Are there any other options that we haven't considered?

Thanks!

[k8s-ci-robot]

@vsabella: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[natasha41575]

Thank you for submitting your issue. I was wondering if you could provide some more detail about what you are trying to do with option 1, perhaps with an example? I am open to the suggestion of a new field in images to replace registry names but I would like better clarity on what specifically you are proposing.

I'm also curious if your use case can be resolved by the existing replacements feature [link to docs]. For example, if you have some containers that look like:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: the-deployment
spec:
  template:
    spec:
      containers:
      - name: mypostgresdb
        image: myregistrydomain:port/foo/bar/1
      - name: nginxapp
        image: myregistrydomain:port/foo/bar/2

and a ConfigMap with the following:

apiVersion: v1
kind: ConfigMap
metadata:
  name: local-config
  annotations:
    config.kubernetes.io/local-config: "true"
data:
  registry: new-registry

You could write a kustomization file with the following:

replacements:
- source:
    kind: ConfigMap
    name: local-config
    fieldPath: data.registry
  targets:
  - select: 
      kind: Deployment
    fieldpaths:
      - spec.template.spec.containers.[0].image
      - spec.template.spec.containers.[1].image
   options: 
     delimiter: ":"
     index: 0

The biggest downside with this approach is its verbosity and that you would have to list every container individually. This will be fixed by #4053 which will allow you to select every element in an array without having to list them out individually. If you have any other feedback that might make this approach work for you, please let us know.

That being said, a new field targeted specifically for images seems like a reasonable alternative, especially considering how popular the feature is and that replacements is still new and working out its kinks.

/kind feature
/kind support
/triage under-consideration

[vsabella]

@natasha41575 Thank you so much for your quick reply!

I think our use-case may be solved by the replacements feature - let me try it and see if it works. Since each container right now consists of just two images it might be OK even with the limitation fixed by #4053 , I'll try this week.

Generically all we are looking to do is replace every image in every Deployment/Daemonset/Etc that matches

mycompany.azurecr.io/<image>
with
mycompany.azurecr.us/<image>

But in a single component without having to use the "images:" feature in every single one of our deployments.

[k8s-ci-robot]

@vsabella: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[raghulkrishna]

any update on this?