[EKS] [request]: Prevent CoreDNS pods from running on the same Node
- 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
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