EKS request: Track CoreDNS and publish manifests, tags, compatibility matrix

[StevenACoffman]

Tell us about your request In EKS, CoreDNS is a default addon. Currently the manifest for CoreDNS lives in lives in an S3 bucket and the container is built to an ECR registry we cannot list, so it is impossible to discover when AWS has blessed a new version for use in EKS. For instance, these directions tell people to: curl -o dns.yaml https://amazon-eks.s3-us-west-2.amazonaws.com/cloudformation/2019-02-11/dns.yaml This manifest points to 602401143452.dkr.ecr.us-east-1.amazonaws.com/eks/coredns:v1.1.3 however I read in a support request that v1.2.2 was the new recommended default.

However, I see that 1.5.0 is out here

Which service(s) is this request for? EKS

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? Public insight into latest recommended and available CoreDNS for EKS

Are you currently working around this issue? Using upstream CoreDNS and carefully vetting in an otherwise useless ephemeral EKS cluster.

[pwdebruin1]

We have our logs flooded with a coredns error when querying a TXT record that doesn't exist, this has been fixed in pull request 2291 with coredns, but I'm unsure whether the versions implementing that (1.3.0 and above) is safe to use with EKS k8s versions 1.11 and 1.12.

[tabern]

This will be partially solved as part of #252

[posquit0]

Is there any update?

[philomory]

I think the real problem here is simply that it's impossible to query any information from the "official" AWS ECR registries like 602401143452.dkr.ecr.us-east-1.amazonaws.com. I'm really confused why we can't just aws ecr describe-repositories --registry-id 602401143452 --repository-name eks/coredns; like, this seems like such an obvious thing to make available.

[bengaywins]

A few months back I was trying to solve this exact issue, and found a way to handle it (in Terraform) to avoid needing to manage this at all.

First you can create a data object for the managed addon.

data "aws_eks_addon_version" "vpc_cni" {
  addon_name         = "vpc-cni"
  kubernetes_version = 1.27
  most_recent        = true
}

And then supplement that, feeding the value into your addon creation.

resource "aws_eks_addon" "vpc_cni" {
  cluster_name                = aws_eks_cluster.eks.id
  addon_name                  = "vpc-cni"
  resolve_conflicts_on_create = "OVERWRITE"
  resolve_conflicts_on_update = "OVERWRITE"
  addon_version               = data.aws_eks_addon_version.vpc_cni.version
}

I have the kubernetes_version set as a variable and is the same variable that feeds the cluster creation/upgrade, so that when I upgrade clusters, this isn't something I have to even bother paying attention to. All of the managed addons get upgraded during cluster upgrade every time now. Been through 3 cluster upgrades this way. FWIW the data object only returns AWS officially supported versions and so you don't have to consider that either.

[tabern]

@bengaywins you're right, this data is now publicly available via the EKS Add-ons versions metadata API. Additionally, the coreDNS image is listed on ECR Public to see the manifest.

Resolving.