Self-Managed Nodes

Self-managed nodes give you full control of the EC2 instances at the cost of handling updates yourself.

With self-managed nodes you run your own Auto Scaling group of EC2 instances and are responsible for the AMI, bootstrap, and update process. EKS just accepts whatever nodes register correctly.

When to choose them

  • You need a custom AMI, custom kernel, or special bootstrap that managed groups don't support.
  • You require Windows nodes or GPU configurations with bespoke drivers.
  • You have an existing Auto Scaling group workflow you want to keep.

The trade-off

You must handle version upgrades, security patches, and node draining yourself. Most teams should prefer managed node groups unless they have a concrete reason not to.

Example

Example · bash
# The bootstrap call baked into a self-managed node's user-data
#!/bin/bash
/etc/eks/bootstrap.sh demo \
  --apiserver-endpoint https://XXXX.eks.amazonaws.com \
  --b64-cluster-ca <BASE64_CA> \
  --kubelet-extra-args '--node-labels=role=custom'

When to use it

  • A team running custom kernel modules for eBPF networking uses self-managed nodes to install packages that are not available in EKS-optimized AMIs.
  • A financial firm images their own hardened AMI with specific security benchmarks and registers it as a self-managed EKS node.
  • A platform team uses self-managed nodes with a custom launch template to mount additional EBS volumes at bootstrap time.

More examples

Create self-managed node group

Creates a self-managed node group, giving the team full control over the EC2 launch configuration and AMI choice.

Example · bash
eksctl create nodegroup \
  --cluster prod \
  --name custom-nodes \
  --node-type m5.xlarge \
  --nodes 3 \
  --node-ami-family AmazonLinux2 \
  --managed=false

Custom bootstrap user data

Custom EC2 user data script that calls the EKS bootstrap script with extra kubelet flags for self-managed nodes.

Example · bash
#!/bin/bash
/etc/eks/bootstrap.sh prod \
  --kubelet-extra-args '--max-pods=110 --node-labels=role=custom' \
  --b64-cluster-ca ${B64_CLUSTER_CA} \
  --apiserver-endpoint ${API_SERVER_URL}

Drain and terminate a self-managed node

Safely removes a self-managed node by cordoning, draining, and then terminating the underlying EC2 instance — steps managed automatically by AWS for managed node groups.

Example · bash
NODE=ip-10-0-1-100.ec2.internal
kubectl cordon $NODE
kubectl drain $NODE \
  --ignore-daemonsets \
  --delete-emptydir-data
aws ec2 terminate-instances \
  --instance-ids $(kubectl get node $NODE -o jsonpath='{.spec.providerID}' | cut -d/ -f5)

Related

eks managed node groupseks instance types scaling

Discussion

  • Be the first to comment on this lesson.