liveBook · Manning

AWS-managed node group

As explained in Effective Platform Engineering

An AWS-managed node group is a set of Amazon EKS worker nodes whose provisioning and lifecycle management are handled by AWS.

An AWS-managed node group is a set of Amazon EKS worker nodes whose provisioning and lifecycle management AWS handles. It provides a stable host for administrator-managed cluster services while reducing platform-team maintenance and change-management effort. section 7.4.1 section 7.4

A common pattern reserves one managed node group for management workloads and uses Karpenter for customer workloads. Configuration can specify the AMI type, instance types, capacity type, disk size, minimum and maximum size, desired size, labels, monitoring, and version-update behavior. section 7.4.1 section 7.4

Use the node group as an operational boundary:

  • Place cluster services and extensions that require dependable capacity on the dedicated management group. section 7.4.1
  • Trigger node refreshes through Terraform with -replace rather than deprecated terraform taint. section 7.4.6
  • Let AWS provision replacement nodes first, move workloads, and delete old nodes as a zero-downtime operation. section 7.4.6
  • Add a Pod Disruption Budget to management-group services when rescheduling could otherwise cause failure. section 7.4.6

Refreshing a management node group

A Terraform-managed group named management-arm-rkt-mng can be refreshed with terraform apply -replace. AWS creates replacement nodes from the latest patched AMI, moves workloads, and removes the old nodes; services requiring disruption protection use a Pod Disruption Budget. section 7.4.6

module "eks" {
  ...
  eks_managed_node_group_defaults = {
    version              = var.eks_version
    force_update_version = true#1
    enable_monitoring    = true
  }
  eks_managed_node_groups = {
    # dedicated mgmt node group, other node groups managed by karpenter
    (var.management_node_group_name) = {
      ami_type       = var.management_node_group_ami_type
      instance_types = var.management_node_group_instance_types
      capacity_type  = var.management_node_group_capacity_type
      min_size       = var.management_node_group_min_size
      max_size       = var.management_node_group_max_size
      desired_size   = var.management_node_group_desired_size
      disk_size      = var.management_node_group_disk_size
      labels = {
        "nodegroup"               = var.management_node_group_name
        "node.kubernetes.io/role" = var.management_node_group_role
        "karpenter.sh/controller" = "true"          
      }
      taints = {                                    #2
        dedicated = {
          key    = "dedicated"
          value  = var.management_node_group_role
          effect = "NO_SCHEDULE"
        }
      }
    }
  }
  node_security_group_additional_rules = {        #3
    allow_data_plane_tcp = {
      description                   = "Allow TCP Protocol Port"
      protocol                      = "TCP"
      from_port                     = 1024
      to_port                       = 65535
      type                          = "ingress"
      source_cluster_security_group = true
    }
  }
  tags = {
    "karpenter.sh/discovery" = var.cluster_name    #4
  }
...
}

Inspect the Terraform module configuration for defaults and dedicated management-node-group settings. section 7.4.1

How Effective Platform Engineering covers it

How deep it goes
Explains Terraform configuration, patched-AMI refreshes, replacement sequencing, and disruption protection, but not AWS node-management internals.
Examples
Uses a dedicated management group, Terraform -replace, patched AMI replacement, and Kubernetes workloads protected during rescheduling.
What it assumes
Assumes familiarity with Amazon EKS, Kubernetes workloads, Terraform, node pools, and workload disruption behavior.
What you can do after
Operate and refresh managed EKS nodes through Terraform while preserving service availability during replacement.
How it connects
Connects EKS, Terraform, Karpenter, Amazon Machine Images, Kubernetes scheduling, and Pod Disruption Budgets.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Effective Platform Engineering. The section links point to the parts of the book it draws on.