[EKS] [CoreDNS add-on]: Respect existing number of replicas during add-on update

[david-a-aws]

Community Note

• Please vote on this issue by adding a 👍 reaction 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 EKS add-on for CoreDNS to respect the current number of replicas of the deployment during updates.

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? I would like the EKS add-on updates for CoreDNS to not revert to the default replica count of 2, but instead to respect the existing number of replicas, and complete a rolling update based off that value.

Are you currently working around this issue? You can set the "replicaCount" add-on configuration to override the default value of 2. For example, setting it to 5 would override the default value of 2. If "autoscaling.minReplicas" is set to 10 and "replicaCount" is set to 5, it will terminate 5 pods to meet replicaCount, then scale up to 10 to meet autoScaling minReplicas.

This would not be required if the deployment respected the existing number of replicas.

Additional context To replicate the issue:

1. Update the EKS add on to use autoscaling with minReplicas 5
2. Observe it auto-scale to 5 replicas (from default 2)
3. Make an update to the EKS add-on configuration (can be whitespace change)
4. Observe that it drops the replica count down to 2 (default value), and then back up to 5 (minReplicas value) in < 1 min

Attachments N/A

[oliviassss]

@david-a-aws, thanks for the information. When you upgrade addon, if you pass the flag --resolve-conflicts= PRESERVE, would it help with this case by respecting the current replica counts?