aws / aws/containers-roadmap

[EKS] [request]: Prevent CoreDNS pods from running on the same Node

Open
#2,530 0 comments 4 reactions 0 assignees View on GitHub
EKS EKS Add-Ons EKS Networking 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?

- Feature request, try to limit the amount of CoreDNS pods from running on the same Node.

**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.

- As of today, [there is a limit of 1024 packets per second](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#vpc-dns-limits) per ENI
- We learned the lesson the hard way, out of stroke of bad luck, we hit this limit because our pods were all scheduled on the same node
- Currently only a preferred spread is done for availability zones, but that is not enough in my opinion
- What I want is to ensure that other people would not have to go through DNS throttling.

The current default topology constraint:

```
topologySpreadConstraints = [
{ #default constraint
maxSkew = 1
topologyKey = "topology.kubernetes.io/zone"
whenUnsatisfiable = "ScheduleAnyway"
labelSelector = {
matchLabels = {
k8s-app = "kube-dns"
}
}
},
```

**Are you currently working around this issue?**
How are you currently solving this problem?

- Yes, by enabling node-local-dns and enforcing to schedule on multiple different nodes/hosts:

```
topologySpreadConstraints = [
{ #default constraint
maxSkew = 1
topologyKey = "topology.kubernetes.io/zone"
whenUnsatisfiable = "ScheduleAnyway"
labelSelector = {
matchLabels = {
k8s-app = "kube-dns"
}
}
},
{
maxSkew = 1
topologyKey = "kubernetes.io/hostname"
whenUnsatisfiable = "DoNotSchedule"
labelSelector = {
matchLabels = {
k8s-app = "kube-dns"
}
}
}
]
```

**Additional context**
Anything else we should know?

**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.)

## Note

Please tell me if this issue has been asked before, as I did not find it (yet).

+ I am interested in working on this

Contributor guide

Open the contributing guide

Research direction

The issue identifies EKS's default topologySpreadConstraints and the proposed node-level constraint, but names no implementation files, tests, or entry points. Start by locating the EKS CoreDNS deployment configuration and its scheduling tests; done means CoreDNS pods are prevented from sharing a node without breaking the existing zone-spread behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, kubernetes
Domain
cloud, devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.