Which solution will MAXIMIZE node resilience?
Use a separate launch template to deploy the EKS control plane into a second cluster that is separate from the workload node groups.
Update the workload node groups. Use a smaller number of node groups and larger instances in the node groups.
Configure the Kubernetes Cluster Autoscaler to ensure that the compute capacity of the workload node groups stays underprovisioned.
Configure the workload to use topology spread constraints that are based on Availability Zone.
Explanations:
Deploying the EKS control plane in a separate cluster does not improve the resilience of the worker nodes or pods. It may introduce unnecessary complexity and management overhead without addressing the scaling or availability of the workload directly.
Using fewer node groups with larger instances may simplify management, but it could lead to single points of failure and reduced resilience. If a larger instance type fails, it impacts more pods than if they were distributed across smaller instances.
While configuring the Kubernetes Cluster Autoscaler can help manage node scaling, ensuring that compute capacity stays underprovisioned does not maximize resilience. It can lead to insufficient resources during peak loads, potentially causing pod evictions or failures.
Using topology spread constraints based on Availability Zones allows for even distribution of pods across multiple AZs, increasing resilience. This ensures that if one AZ fails, the workload continues to run in other AZs, thereby minimizing downtime and maximizing availability.
If I’m not mistaken, the answer is:
Configure the workload to use topology spread constraints that are based on Availability Zone.