Node groups (managed, self-managed, Fargate) in AWS - Step-by-Step Execution

Process Flow - Node groups (managed, self-managed, Fargate)

Start: Create EKS Cluster

↓

Choose Node Group Type

↓

Managed

↓

Provision EC2

↓

Register Nodes

↓

Cluster Ready with Nodes

↓

Use Cluster

This flow shows starting an EKS cluster, choosing a node group type (managed, self-managed, or Fargate), provisioning resources accordingly, and having nodes ready for workloads.

Execution Sample

AWS

eksctl create cluster --name my-cluster --managed
# Creates cluster with managed node group

eksctl create nodegroup --cluster my-cluster --name self-managed --nodes 2
# Adds self-managed nodes

kubectl apply -f fargate-profile.yaml
# Enables Fargate for serverless pods

Commands to create an EKS cluster with managed nodes, add self-managed nodes, and enable Fargate for serverless pods.

Process Table

Step	Action	Node Group Type	Resource Provisioned	Node Registration	Cluster State
1	Create EKS cluster	None	Control Plane	No nodes yet	Cluster created, no nodes
2	Create managed node group	Managed	EC2 instances by AWS	Auto-registered	Cluster with managed nodes
3	Create self-managed node group	Self-Managed	EC2 instances by user	Manual registration	Cluster with managed and self-managed nodes
4	Apply Fargate profile	Fargate	Serverless compute	No nodes, pods run serverless	Cluster with all node types
5	Run pods	All	Pods scheduled	Pods run on respective nodes	Cluster fully operational
6	End	-	-	-	All node groups active and ready

💡 All node groups provisioned and cluster ready for workloads

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
Cluster State	No cluster	Cluster with managed nodes	Cluster with managed + self-managed nodes	Cluster with managed + self-managed + Fargate	Fully operational cluster
Managed Nodes	0	Provisioned and registered	Provisioned and registered	Provisioned and registered	Provisioned and registered
Self-Managed Nodes	0	0	Provisioned and registered	Provisioned and registered	Provisioned and registered
Fargate Nodes	0	0	0	Enabled (serverless pods)	Enabled (serverless pods)

Key Moments - 3 Insights

Why do managed node groups auto-register nodes but self-managed require manual registration?

Managed node groups are created and controlled by AWS EKS, so nodes automatically join the cluster (see execution_table step 2). Self-managed nodes are created by the user and need manual setup to join (step 3).

How does Fargate differ from managed and self-managed node groups in resource provisioning?

Fargate runs pods on serverless compute without provisioning EC2 instances (step 4). Managed and self-managed node groups provision EC2 instances.

Can all three node group types run workloads simultaneously?

Yes, after all are set up (step 5), pods can run on managed nodes, self-managed nodes, or Fargate serverless compute.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What is the node registration status for self-managed nodes?

A Auto-registered by AWS

B Manual registration required

C No registration needed

D Registered by Fargate

💡 Hint

Check the 'Node Registration' column at step 3 in execution_table

At which step does the cluster first have serverless compute enabled?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look for 'Fargate' and 'Serverless compute' in the 'Resource Provisioned' column

If you skip creating a self-managed node group, how does the 'Self-Managed Nodes' variable change after step 3?

A It remains 0

B It becomes provisioned

C It becomes enabled but unregistered

D It becomes serverless

💡 Hint

Refer to variable_tracker row for 'Self-Managed Nodes' after step 3

Concept Snapshot

Node groups in EKS are ways to run your workloads:
- Managed node groups: AWS creates and manages EC2 nodes, auto-registered.
- Self-managed node groups: You create EC2 nodes, manual registration.
- Fargate: Serverless, no EC2 nodes, pods run on demand.
Choose based on control, management, and cost needs.

Full Transcript

This visual execution shows how an EKS cluster is created and how different node groups are added. First, the cluster control plane is created. Then, managed node groups provision EC2 instances automatically registered to the cluster. Next, self-managed node groups require the user to provision EC2 instances and manually register them. Fargate profiles enable serverless compute where pods run without EC2 nodes. The cluster can run workloads on all node types simultaneously. Variables track cluster state and node counts after each step. Key moments clarify why registration differs and how Fargate works. Quiz questions test understanding of node registration, serverless enablement, and variable changes.

Practice

1. Which type of node group in AWS EKS automatically manages the worker nodes for you?

easy

A. On-premises node group

B. Managed node group

C. Fargate

D. Self-managed node group

Solution

1. Step 1: Understand node group types in EKS

   Managed node groups are designed to let AWS handle the worker nodes, including updates and scaling.

2. Step 2: Compare with other node groups

   Self-managed node groups require manual management of EC2 instances, and Fargate runs containers without servers.

3. Final Answer:

   Managed node group -> Option B

4. Quick Check:

   Managed node group = automatic worker node management [OK]

Hint: Managed node groups mean AWS manages nodes for you [OK]

Common Mistakes:

• Confusing self-managed with managed node groups
• Thinking Fargate manages EC2 instances
• Assuming on-premises node groups are managed by AWS

2. Which of the following is the correct way to specify a Fargate profile in AWS EKS configuration?

easy

A. Specify EC2 instance types under node group

B. Set up Auto Scaling group manually

C. Define selectors with namespaces and labels for Fargate profile

D. Create a launch configuration for EC2

Solution

1. Step 1: Recall Fargate profile setup

   Fargate profiles use selectors to match pods by namespace and labels to run on Fargate.

2. Step 2: Eliminate incorrect options

   EC2 instance types, Auto Scaling groups, and launch configurations relate to EC2, not Fargate.

3. Final Answer:

   Define selectors with namespaces and labels for Fargate profile -> Option C

4. Quick Check:

   Fargate profile uses selectors = Define selectors with namespaces and labels for Fargate profile [OK]

Hint: Fargate profiles use selectors, not EC2 settings [OK]

Common Mistakes:

• Trying to specify EC2 instance types for Fargate
• Confusing Auto Scaling with Fargate profiles
• Using launch configurations for Fargate

3. Given the following EKS setup, which node group type will run the pod?

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  namespace: production
spec:
  containers:
  - name: app
    image: myapp:latest

Assuming a Fargate profile exists for namespace 'production' and a managed node group is also present.

medium

A. Managed node group

B. Self-managed node group

C. No node group will run the pod

D. Fargate

Solution

1. Step 1: Check pod namespace against Fargate profile

   The pod is in 'production' namespace, which matches the Fargate profile selector.

2. Step 2: Understand pod scheduling priority

   Pods matching Fargate profiles run on Fargate instead of node groups.

3. Final Answer:

   Fargate -> Option D

4. Quick Check:

   Pod in Fargate profile namespace runs on Fargate [OK]

Hint: Pod namespace matching Fargate profile means Fargate runs it [OK]

Common Mistakes:

• Assuming managed node group runs all pods
• Ignoring Fargate profile selectors
• Thinking self-managed node group runs pods by default

4. You created a self-managed node group but your pods are stuck in Pending state. What is a likely cause?

medium

A. EC2 instances in the node group are not registered with the cluster

B. Fargate profile is missing

C. Managed node group is not enabled

D. Pod namespace does not match Fargate profile

Solution

1. Step 1: Understand self-managed node group requirements

   Self-managed nodes must register with the cluster to run pods.

2. Step 2: Identify cause of Pending pods

   If EC2 instances are not registered, pods cannot schedule and remain Pending.

3. Final Answer:

   EC2 instances in the node group are not registered with the cluster -> Option A

4. Quick Check:

   Unregistered EC2 nodes cause Pending pods [OK]

Hint: Self-managed nodes must register to run pods [OK]

Common Mistakes:

• Assuming Fargate profile affects self-managed nodes
• Thinking managed node group must be enabled for self-managed nodes
• Ignoring node registration status

5. You want to run a highly scalable application without managing any servers. Which AWS EKS node group option should you choose and why?

hard

A. Fargate, because it runs containers without managing servers

B. Managed node group, because AWS handles node updates automatically

C. Self-managed node group, because you control EC2 instances directly

D. On-premises nodes, because they offer full control

Solution

1. Step 1: Identify requirement for no server management

   The question asks for running containers without managing servers.

2. Step 2: Compare node group options

   Self-managed and managed node groups require managing or at least maintaining EC2 instances. Fargate runs containers serverless.

3. Step 3: Confirm scalability and management

   Fargate automatically scales and removes server management burden.

4. Final Answer:

   Fargate, because it runs containers without managing servers -> Option A

5. Quick Check:

   No server management means Fargate [OK]

Hint: No servers to manage? Choose Fargate [OK]

Common Mistakes:

• Choosing self-managed for no server management
• Confusing managed node groups with serverless
• Selecting on-premises nodes for cloud scalability