Managed node groups: an Auto Scaling group with EKS manners

Study notes

• A managed node group is an EKS-level object that owns an Auto Scaling group of EC2 instances in your account. EKS supplies the node bootstrap, registers new nodes with the cluster, cordons and drains nodes before scale-in and during updates, monitors node health, and replaces unhealthy nodes. You choose instance types, minimum and maximum size, labels and taints, the AMI type and the update strategy. Reveal the four layers with the right arrow.
• Compared with a self-managed Auto Scaling group, you no longer maintain a bootstrap script or write your own drain-on-terminate logic, and AMI updates are a single API call (update-nodegroup-version) that rolls nodes safely. Taints and labels can be declared on the group so that every future node has them, which is how you reserve a GPU or Spot pool.
• The limits of the model are the reason Karpenter exists: a node group has a fixed instance-type list and scales by changing its desired size, driven by the Cluster Autoscaler or by you. Capacity for a Pod with unusual requirements needs a node group shaped for it, so teams end up with a matrix of groups. That is fine for steady, predictable fleets and still very common.
• Operational gotchas: set the update configuration's maxUnavailable to control rollout speed, make sure PodDisruptionBudgets allow drains, and spread node groups across the Availability Zones your volumes live in (one group per AZ is common for stateful workloads using zonal EBS volumes).

Deck map