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
When working with EKS AutoMode, the default NodePool and NodeClass are not meant to be edited:
Custom NodePools and NodeClasses: Default NodePools and NodeClasses are configured by EKS Auto Mode and you should not edit them.
This is fair, as many customer may just use it "as it is". The issue is that when you initially create the EKS Cluster, the default NodeClass inherits the Subnets from here. If you later modify/update/replace the Subnets in the Cluster configuration, they won't be updated or propagated to the Default NodeClass. Nodes will still be using the old settings. This can be counter-intuitive for customers looking for a zero-touch config. It becomes tricky (or impossible) to change this, forcing the creation of a new NodePool and NodeClass.
I think is fair to lock in and preserve this matching the Cluster configuration. But if the Cluster configuration changes, this must be propagated to the default NodeClass as well. I understand this can have implications as migrating workloads, but this should be modifiable in some way. Otherwise, the only options left are:
- Creating a new Cluster
- Forcing the setup to use a new NodeClass
Which service(s) is this request for?
EKS
Community Note
Tell us about your request
When working with EKS AutoMode, the default NodePool and NodeClass are not meant to be edited:
This is fair, as many customer may just use it "as it is". The issue is that when you initially create the EKS Cluster, the default NodeClass inherits the Subnets from here. If you later modify/update/replace the Subnets in the Cluster configuration, they won't be updated or propagated to the Default NodeClass. Nodes will still be using the old settings. This can be counter-intuitive for customers looking for a zero-touch config. It becomes tricky (or impossible) to change this, forcing the creation of a new NodePool and NodeClass.
I think is fair to lock in and preserve this matching the Cluster configuration. But if the Cluster configuration changes, this must be propagated to the default NodeClass as well. I understand this can have implications as migrating workloads, but this should be modifiable in some way. Otherwise, the only options left are:
Which service(s) is this request for?
EKS