considering the local image repositories changes when migrating from cluster A to B

[wenterjoy]

Describe the problem/challenge you have
[A description of the current limitation/problem/challenge that you are experiencing.]
Cluster A has a private image repository that most pod images depends on is directly named as a LAN ip or private domain name.
So all the images is showed as [LAN ip:port]/[image-name]:[tag], which is commonly in test、development and even production environment.
I met the problem that most of the images are ImagePullBackOff when migrating from Cluster A in Cluster B. Because the images are all pointed to the image repository of Cluster A can't pulled because the network is unreachable while the new private image repository is supplied with new LAN ip or private domain info with Cluster B. I needed to change all the pod's image repository prefix from A to B.

Describe the solution you'd like
[A clear and concise description of what you want to happen.]
It should be an chance to supply a config-map that indicates the image repository can be changed from [old] to [new], when migrating from Cluster A in Cluster B, so all the images meets the (config-map) rule can be changed automatically when restore the cluster.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Inspired by the storage class changing action， I have written a plugin that can change the deployment/daemonset/statefulset/pod's initcontainers and containers' image repository.

Environment:

• Velero version (use velero version):

• Kubernetes version (use kubectl version):

• Kubernetes installer & version:

• Cloud provider or hardware configuration:

• OS (e.g. from /etc/os-release):

Vote on this issue!

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

• 👍 for "The project would be better with this feature added"
• 👎 for "This feature will not enhance the project in a meaningful way"

[sseago]

Note that this can currently be done outside of velero by writing a RestoreItemAction plugin. If we were to decide to do it inside of Velero, the implementation would probably still be implemented via a RestoreItemAction.

Also note that if doing this, it's not just Pod images that will need to be modified. The same substitution will need to be applied to any resource that contains a Pod template. This would include Deployment, ReplicaSet, ReplicationController, DaemonSet, StatefulSet, Job, CronJob.

[wenterjoy]

Note that this can currently be done outside of velero by writing a RestoreItemAction plugin. If we were to decide to do it inside of Velero, the implementation would probably still be implemented via a RestoreItemAction.

Also note that if doing this, it's not just Pod images that will need to be modified. The same substitution will need to be applied to any resource that contains a Pod template. This would include Deployment, ReplicaSet, ReplicationController, DaemonSet, StatefulSet, Job, CronJob.

@sseago thanks a lot for your comments and reminder, it already contains Deployment, DaemonSet, StatefulSet.
I would add code for the resources of ReplicaSet, ReplicationController,Job, CronJob.

[reasonerjt]

Since there's been a few back and forth of the PR let's review and merge it in v1.11

[wenterjoy]

Since there's been a few back and forth of the PR let's review and merge it in v1.11

Thanks for reply.
so what should I do？Create new PR to v1.11？（I can‘t find any branches related to it）
@reasonerjt

[sseago]

@wenterjoy v1.11 development is currently against branch main.

[wenterjoy]

I get it. Thanks. @sseago

[ywk253100]

Closing as the PR #5540 merged