Skip to content
This repository has been archived by the owner on Mar 9, 2022. It is now read-only.

Add support for pull-through cache with registry #1196

Closed
awprice opened this issue Jul 8, 2019 · 10 comments · Fixed by #1235
Closed

Add support for pull-through cache with registry #1196

awprice opened this issue Jul 8, 2019 · 10 comments · Fixed by #1235
Milestone

Comments

@awprice
Copy link
Contributor

awprice commented Jul 8, 2019

We'd like to configure a pull-through cache for containerd, so that any images that are pulled by containerd/cri, are pulled through a local registry. This way the image can be cached for multiple Kubernetes nodes in the local registry.

With docker, we can configure this with --registry-mirror=<uri> and all image pulls are done through the URI specified.

See Docker documentation on how to configure the pull-through cache - https://docs.docker.com/registry/recipes/mirror/

With containerd/cri, we can only configure a registry mirror per host, like so:

[plugins.cri.registry.mirrors]
  [plugins.cri.registry.mirrors."docker.io"]
    endpoint = ["<uri>"]

This would require us to determine all of the possible hosts that we pull from and list them in the containerd config, with our local registry as the endpoint.

I believe #351 isn't properly solved, as --registry-mirror in Docker is able to catch all image pulls and pass them through the local registry.

Ideally we could update the image pull registry logic to allow wildcard hosts, like so:

[plugins.cri.registry.mirrors]
  [plugins.cri.registry.mirrors."*"]
    endpoint = ["<uri>"]

Thoughts?

@mikebrow
Copy link
Member

SGTM
@Random-Liu thoughts?

@Random-Liu
Copy link
Member

Random-Liu commented Jul 24, 2019

SGTM, too.

This is a valid use case to me.

@mikebrow @awprice Do we need to support partial wildcard like docker.io.*?

I think we can start from only supporting *, and extend to something like #1096 in the future if there is valid use case. :)

@Random-Liu Random-Liu added this to the v1.3 milestone Jul 24, 2019
@mikebrow
Copy link
Member

@mikebrow @awprice Do we need to support partial wildcard like docker.io.*?

I think we can start from only supporting *, and extend to something like #1096 in the future if there is valid use case. :)

Agreed. Unless there is an existing wild card pattern of use in the space we should try to be consistent with our introductions of wildcarding.

@awprice
Copy link
Contributor Author

awprice commented Jul 24, 2019

+1, I think supporting plugins.cri.registry.mirrors."*" is a good first step.

@Random-Liu
Copy link
Member

@awprice Would you like to contribute a PR for this? :)

@awprice
Copy link
Contributor Author

awprice commented Jul 25, 2019

@Random-Liu I would be happy to. No guarantees it will be ready for the 1.3 due date (if there is one), but I can give it a crack.

@Random-Liu
Copy link
Member

@awprice Thanks! :D

@dmcgowan
Copy link
Member

This would require us to determine all of the possible hosts that we pull from and list them in the containerd config, with our local registry as the endpoint.

I believe #351 isn't properly solved, as --registry-mirror in Docker is able to catch all image pulls and pass them through the local registry.

In Docker the --registry-mirror only applies to docker.io, so it is equivalent to [plugins.cri.registry.mirrors."docker.io"]. Docker will ignore the mirror setting for other registries.

This is actually not a configuration limitation but spec and client limitation today. See containerd/containerd#3451 and opencontainers/distribution-spec#66. I would like to try and get this fixed for 1.3, first RC is mid August.

@Random-Liu
Copy link
Member

Random-Liu commented Aug 6, 2019

@awprice As mentioned by @dmcgowan, this is something docker doesn't support, either.

However, I think "*" support can still be useful in some cases, e.g. a private cluster that all image pull requests should go through a proxy for security.

@awprice
Copy link
Contributor Author

awprice commented Aug 6, 2019

Apologies, I must of been mistaken.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants