aws / aws/containers-roadmap

[EKS] [request]: managed node groups need support for defining registry mirrors

Open
#1,475 3 comments 74 reactions 0 assignees View on GitHub
EKS EKS Managed Nodes Proposed
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.