ECR (not ECR Public) repository for EKS-D images

[jbg]

What would you like to be added:

A documented ECR (not ECR Public) repository for all EKS-D components, similar to those documented for AWS VPC CNI driver, EFS CSI driver, kube-proxy, coredns, etc.

Why is this needed:

Sometimes it's desired to run components from EKS-D in-cluster, for example to run kube-scheduler with a different configuration than EKS uses. Because the images are hosted on ECR Public, which has no VPC endpoints and uses CloudFront for serving layers, doing this on a private cluster requires using workarounds such as mirroring the image into an ECR repository that the cluster can safely access. ECR Pull-Through Cache does not currently work on private clusters with restricted Internet access either, and anyway isn't suitable for all use cases.

Other EKS components do not run into this issue because they provide well-known ECR repositories from which the images can be pulled directly, e.g.

602401143452.dkr.ecr.$REGION.amazonaws.com/eks/kube-proxy:$TAG
602401143452.dkr.ecr.$REGION.amazonaws.com/eks/coredns:$TAG
602401143452.dkr.ecr.$REGION.amazonaws.com/eks/aws-efs-csi-driver:$TAG
602401143452.dkr.ecr.$REGION.amazonaws.com/amazon-k8s-cni:$TAG

(The account ID is usually 602401143452 but differs for some regions.)

If other EKS components are in fact already available under 602401143452.dkr.ecr.$REGION.amazonaws.com/eks/, it would be great to document this.

[kschumy]

@jbg Thank you for bringing this to our attention! I can see how this feature would be helpful in use cases like you've described.

We're looking into this and will get back to you within the next week or two with an update.

[markapruett]

We've added this to our backlog and will look at prioritizing it later this year. Will post back with updates when there is any change. Thanks for submitting this!