-
Notifications
You must be signed in to change notification settings - Fork 527
Coredns deployment tolerates all NoSchedule taints. #1325
Comments
👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. |
This was added in #555. The idea was to ensure core system components could always be scheduled. @jackfrancis could we revisit the |
I think we want to enable this as an option. @palma21 drove this effort in response to user feedback that folks wanted this prioritized scheduling toleration for coredns and other system components, |
That sounds like incorrect behavior from the scaling side. Do you have some kind of pod disruption budget? The node should be able to scale down if k8s sees that it can schedule it somewhere else and resources are underutilized. That said, if you don't want the coredns pods on your specific hardware machines, do remove the toleration on your deployment. We have a number of use cases that will break if we remove it for everyone, but we can certainly revisit. |
Thanks for confirming this is expected. Modifying the CoreDNS deployment will work. |
aks-engine/parts/k8s/addons/coredns.yaml
Line 134 in 279a235
For unique hardware we will typically apply a noschedule taint to avoid unnecessary pods getting scheduled onto them. The coredns pod seems to have tolerations for any noschedule taint, which prevents the node from being scaled down by the cluster autoscaler if coredns is scheduled onto it.
The text was updated successfully, but these errors were encountered: