[EKS] [request]: managed node groups need support for defining registry mirrors
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
What do you want us to build?
Add builtin support or documentation for defining registry mirrors for managed node groups.
**Which service(s) is this request for?**
This could be Fargate, ECS, EKS, ECR
EKS
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
The default for most public helm charts is to source images from docker hub (docker.io), and for experimentation we'd like to avoid putting too much process on it. However, syncing directly from docker hub without using authentication triggers rate limits very quickly.
**Are you currently working around this issue?**
How are you currently solving this problem?
The rate limiting issues with docker hub are a huge problem for organizations and the current standard approaches are to:
- Re-host all images on a self-managed ECR registry. Lots of maintenance / process is required to make this work.
- Use Kyverno or other solutions to sync image pull secrets to every namespace and possibly also rewrite image specs to point at a mirror. This requires exposing secrets for the mirror and forcing things into user-space where they shouldn't really need to deal with the problem, especially in experimental phases of development.
- Wait for something like https://kubernetes.io/docs/tasks/kubelet-credential-provider/kubelet-credential-provider/ to standardize to support authenticating with docker hub itself at the node level instead of mirroring/caching images. This still has limitations and would be preferable to specify a mirror to avoid rate limits altogether.
**Additional context**
Anything else we should know?
We'd really like to have integrated support between the coming ECR pull-through caching support https://github.com/aws/containers-roadmap/issues/939 and managed node groups to automatically authenticate with one that the cluster can use.
**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
Contributor guide
Research direction
No repository files, tests, or implementation entry points are identified in the issue. Start by reviewing the EKS managed node group and ECR pull-through caching context linked in the request; done would require a decided approach for defining registry mirrors and either integrated support or documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, docker, kubernetes
- Domain
- cloud, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100