Add --image-repository flag so that users can select an alternative repository mirror

[laozc]

This PR is aiming to support a new command line argument --image-repository for some users which has difficulty accessing gcr.io.

Closes #3166

[minikube-bot]

Can one of the admins verify this patch?

[tstromberg]

Thank you so much for writing this. This PR could potentially make minikube work much better in China, as well as environments with limited internet connectivity. I'll give this a closer look tomorrow, but at least initially this seems to be doing the right things.

Do you have a mirror or two to recommend that I could test this PR against?

One potential concern to eventually address is cache-poisoning, which will require minikube addressing images with hashes instead of versions -- but I won't let "perfect be the enemy of good".

A potential eventual enhancement would be to have an automated fall-back mechanism between a set of known-good image repositories (similar to "apt" or other systems), so that minikube in users in China would not have to manually specify a --image-repository URL unless they wish to.

Thanks again!

[tstromberg]

@minikube-bot OK to test

[laozc]

You may start with registry.cn-hangzhou.aliyuncs.com/google_containers.
This is one of the well known mirrors for gcr.io maintained by Aliyun guys.
I verified with this mirror so it should work as expected (v1.13.3).

We may use --image-repository as an ultimate workaround
if none of mirrors provided is accessible in user's environment.
I agree that maintaining a mirror list as like the APT / pacman world also helps,
or even trying to guess a reliable mirror by IP address during the setup.
I can work on that later.

Let me know if you have any other concerns.

[tstromberg]

How does this new --image-repository flag interact with the existing --registry-mirror flag?

--registry-mirror - Registry mirrors to pass to the Docker daemon

I'll admit, I didn't know about this flag up until today. I haven't looked into it's implementation yet to see if it's compatible with non-docker container runtimes, which your flag seems to allow for.

[laozc]

I believe --registry-mirror only impacts those images with no repository prefix - images that come from the Docker official registry.
It won't work on images from private registries, which is the case like gcr.io/kube-proxy. For private images, docker will still go to the private registry and fetch them.

If you set up minikube with --registry-mirror, it could work for pods/deployments that use ubuntu/18.04, but not for gcr.io/ - you will need to wipe the "gcr.io/" out from the references to make it look like an image from the official registry. For the latter case, it could be achieved using --registry-mirror https://private_server --image-registry [private_server/]google_containers

[afbjorklund]

For instance crio has a --registryflag, but that only works for images without prefix ("unqualified"):

   --registry value              registry to be prepended when pulling unqualified images, can be specified multiple times

The same goes for the global /etc/containers/registries.conf, which lists the default registries:

[registries.search]
registries = ['docker.io']

[registries.insecure]
registries = []

And /etc/crio/crio.conf with CRI-O's:

# insecure_registries is used to skip TLS verification when pulling images.
insecure_registries = [
]

# registries is used to specify a comma separated list of registries to be used
# when pulling an unqualified image (e.g. fedora:rawhide).
registries = [
        "docker.io"
]

As stated above, this would not help for the k8s.gcr.io images.

[tstromberg]

/approve

Thank you for the clarification and excellent work here. I've added a few nitpicks, but it's good enough as is. This is really going to help minikube users around the world.

We're going to want to add an integration test for this, but until #3767 lands it's rather painful to add start arguments. We can do that in a follow-up PR.

[tstromberg]

@minikube-bot OK to test

[tstromberg]

@minikube-bot OK to test

[laozc]

Have some other work based on this PR.
Any chance to have it merged sooner?
Let me know if you have any concerns.

[tstromberg]

@minikube-bot OK to test

[tstromberg]

I think it may have been my attempt at merging to master, but it appears that "minikube dashboard" is broken with this PR at the moment.

[tstromberg]

Do you mind remerging this PR? I'd like to also confirm that minikube dashboard still works.

[laozc]

I'm checking the case you describe and looking into the PR.

[tstromberg]

Thanks for making the changes!

/lgtm /approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: laozc, tstromberg

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [tstromberg]

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

[laozc]

This flag only take affect when you execute minikube start. You may check the output of minikube start --help. If you don’t see the flag appearing in the help text it might suggest you’re using an old release. The flag can be used as shown in the following examples: minikube start --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers or minikube start --image-repository=auto Regards, Zhongcheng From: Adnan Hodzic <[email protected]> Sent: Tuesday, July 23, 2019 7:10 PM To: kubernetes/minikube <[email protected]> Cc: Zhongcheng Lao <[email protected]>; Author <[email protected]> Subject: Re: [kubernetes/minikube] Add --image-repository flag so that users can select an alternative repository mirror (#3714) It says this PR has been merged with master, however if I run minikube --image-repository I'll get an error with unknown flag: --image-repository message. Could somebody please clarify how can this flag be used exactly, as I'm in need of one such functionality. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fminikube%2Fpull%2F3714%3Femail_source%3Dnotifications%26email_token%3DAAFCTMJOZNIRPRKFXVAOZWDQA3RJ5A5CNFSM4GX73PFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2SYRUY%23issuecomment-514164947&data=02%7C01%7Czhongcheng.lao%40microsoft.com%7Cb3d05083b1e2412b7dc808d70f5e5b48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636994770246142938&sdata=6aOGVgMx1IlGdlUPTzTe2euIuDgP0U3hV91XOhjb1WE%3D&reserved=0>, or mute the thread<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAFCTMMAKADWVBAJXE43NBLQA3RJ5ANCNFSM4GX73PFA&data=02%7C01%7Czhongcheng.lao%40microsoft.com%7Cb3d05083b1e2412b7dc808d70f5e5b48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636994770246152934&sdata=QgrEZkdp%2B7DYp%2BG6yvect0aV81wd2agAW%2BlYVhhHfc4%3D&reserved=0>.

[AdnanHodzic]

@laozc got it, thank you for the clarification!