[WIP]Adapt offline installation

[helen-frank]

Signed-off-by: helen helenfrank@protonmail.com

What type of PR is this?
/kind feature

What this PR does / why we need it:
When you cannot access the external network, you can simply install the karmada by specifying the KubeImageRegistry.
Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

When the KubeImageRegistry is specified, the EtcdInitImage will also be changed

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign prodanlabs after the PR has been reviewed.
You can assign the PR to them by writing /assign @prodanlabs in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• pkg/karmadactl/cmdinit/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[RainbowMango]

When you cannot access the external network, you can simply install the karmada by specifying the KubeImageRegistry.

I don't get it. Without this path, I think people also can get the image from the --kube-image-registry.

[helen-frank]

When you cannot access the external network, you can simply install the karmada by specifying the KubeImageRegistry.

I don't get it. Without this path, I think people also can get the image from the --kube-image-registry.

What I want to achieve is that since I have specified--kube-image-registry, all image should be in my image registry, but etcd-init-image seems to be an exception.

[helen-frank]

@RainbowMango In other words, the expected design here is etcd-init-image requires additional designation when the installation environment handles the isolation of the external network.

[RainbowMango]

I guess you mean let karmadactl get docker.io/alpine:3.15.1 image from kube-image-registry.

My concern is the flag --kube-image-registry is used for kubernetes images, but the docker.io/alpine:3.15.1 not maintains by Kubernetes.
It might be not a good idea to mix them up. On other hand, how about the Karmada images, should they download from a private registry?

[RainbowMango]

Let me try to understand your case.

1. you set --kube-image-registry flag to a private or local registry.
2. since you can't access the external network, you still need to set --etcd-init-image which probably is the same registry as --kube-image-registry

Am I right?

[helen-frank]

Let me try to understand your case.

1. you set --kube-image-registry flag to a private or local registry.
2. since you can't access the external network, you still need to set --etcd-init-image which probably is the same registry as --kube-image-registry

Am I right?

Yes, I want to find a solution to make it easier for karmada to install in an offline environment. I think the idea of "karmada-image-registry" is feasible.
(I'm very sorry, my English level is relatively poor, which brings you some difficulty in understanding the review. ^_^)

[helen-frank]

I have another idea. When image-registry is specified, the default application version in the karmadactl will definitely be installed (for example, kube-apiserver is 1.24.2). Is there any modification plan for karmadactl in this regard? @RainbowMango

[helen-frank]

My idea is to add a parameter karmada-image-tag , when you specify --karmada-image-registry, you can specify the installation version.
For example, when my multi-cloud cluster decides on a unified version, I only need to use docker tag & docker push to upload these required images to my image-registry in batches, and karmadactl init --karmada-image-registry=xxx.io -- karmada-image-tag=m1 during installation.
I want to know what you think about this? ^_^ @RainbowMango

[RainbowMango]

Yes, I want to find a solution to make it easier for karmada to install in an offline environment.

That makes sense to me. You are welcome to talk at the community meeting.
cc @lonelyCZ @prodanlabs for comment

[liangyuanpeng]

We have a param of global.imageRegistry on helm chart, is it the same case?

[helen-frank]

We have a param of global.imageRegistry on helm chart, is it the same case?

Hi @liangyuanpeng , It looks similar，but I prefer to use a single group to manage karmada images when installing in an offline environmen.

[liangyuanpeng]

For example, when my multi-cloud cluster decides on a unified version, I only need to use docker tag & docker push to upload these required images to my image-registry in batches, and karmadactl init --karmada-image-registry=xxx.io -- karmada-image-tag=m1 during installation.

@helen-frank
Just for confirm that, So it would be manager image for karmada containers?
It include this container:

• karmada-aggregated-apiserver
• karmada-controller-manager
• karmada-scheduler
• karmada-webhook
• karmada-search
• karmada-descheduler
• karmada-scheduler-estimator

[helen-frank]

For example, when my multi-cloud cluster decides on a unified version, I only need to use docker tag & docker push to upload these required images to my image-registry in batches, and karmadactl init --karmada-image-registry=xxx.io -- karmada-image-tag=m1 during installation.

@helen-frank Just for confirm that, So it would be manager image for karmada containers? It include this container:

• karmada-aggregated-apiserver
• karmada-controller-manager
• karmada-scheduler
• karmada-webhook
• karmada-search
• karmada-descheduler
• karmada-scheduler-estimator

Yes！My idea is to unify the management of the images involved in the karmada and simplify offline installation.

[liangyuanpeng]

SGTM!

[helen-frank]

/close

[karmada-bot]

@helen-frank: Closed this PR.

In response to this:

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