Node groups (managed, self-managed, Fargate) in AWS - Commands & Configuration

Introduction

When you run applications on Kubernetes in AWS, you need servers called nodes. Node groups are collections of these servers. Managed node groups are handled by AWS for you, self-managed node groups you control yourself, and Fargate lets you run nodes without managing servers at all.

When you want AWS to handle server updates and scaling automatically for your Kubernetes nodes.

When you need full control over the servers running your Kubernetes workloads.

When you want to run Kubernetes pods without managing any servers or infrastructure.

When you want to save time by letting AWS manage the node lifecycle.

When you want to customize the server setup beyond what managed node groups allow.

Config File - eks-nodegroup.yaml

eks-nodegroup.yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: example-cluster
  region: us-east-1
nodeGroups:
  - name: managed-ng
    instanceType: t3.medium
    desiredCapacity: 2
    iam:
      withAddonPolicies:
        autoScaler: true
  - name: selfmanaged-ng
    instanceType: t3.medium
    desiredCapacity: 2
    ssh:
      allow: true
    privateNetworking: true
fargateProfiles:
  - name: fp-default
    selectors:
      - namespace: default

This file defines an EKS cluster with three types of node groups:

• managed-ng: A managed node group where AWS handles updates and scaling.
• selfmanaged-ng: A self-managed node group where you control the nodes, including SSH access.
• fp-default: A Fargate profile that runs pods in the default namespace without managing servers.

Commands

This command creates the EKS cluster with the managed node group, self-managed node group, and Fargate profile as defined in the config file.

Terminal

eksctl create cluster -f eks-nodegroup.yaml

Expected Output

2024-06-01T12:00:00Z [ℹ]  eksctl version 0.140.0

2024-06-01T12:00:01Z [ℹ]  using region us-east-1

2024-06-01T12:00:02Z [ℹ]  nodegroup managed-ng will use Amazon Linux 2

2024-06-01T12:00:10Z [ℹ]  nodegroup selfmanaged-ng will use Amazon Linux 2

2024-06-01T12:05:00Z [ℹ]  created cluster control plane "example-cluster"

2024-06-01T12:10:00Z [ℹ]  created nodegroup "managed-ng"

2024-06-01T12:15:00Z [ℹ]  created nodegroup "selfmanaged-ng"

2024-06-01T12:20:00Z [ℹ]  created Fargate profile "fp-default"

2024-06-01T12:20:01Z [✔]  all cluster resources created successfully

→

-f - Specifies the config file to create the cluster and node groups

This command lists all the nodes in the Kubernetes cluster, showing nodes from managed and self-managed groups. Fargate nodes do not appear here because they are serverless.

Terminal

kubectl get nodes

Expected Output

NAME                                           STATUS   ROLES    AGE   VERSION

ip-192-168-1-10.us-east-1.compute.internal    Ready    <none>   10m   v1.26.3

ip-192-168-2-11.us-east-1.compute.internal    Ready    <none>   10m   v1.26.3

This command shows pods running in the default namespace. Pods scheduled on Fargate run without visible nodes here.

Terminal

kubectl get pods -n default

Expected Output

NAME                                READY   STATUS    RESTARTS   AGE

example-pod-1                       1/1     Running   0          5m

example-pod-2                       1/1     Running   0          5m

→

-n - Specifies the namespace to list pods from

This command deletes the entire EKS cluster along with all node groups and Fargate profiles, cleaning up all resources.

Terminal

eksctl delete cluster -f eks-nodegroup.yaml

Expected Output

2024-06-01T13:00:00Z [ℹ]  deleting cluster "example-cluster" in "us-east-1"

2024-06-01T13:10:00Z [ℹ]  deleted nodegroup "managed-ng"

2024-06-01T13:15:00Z [ℹ]  deleted nodegroup "selfmanaged-ng"

2024-06-01T13:20:00Z [ℹ]  deleted Fargate profile "fp-default"

2024-06-01T13:25:00Z [✔]  cluster "example-cluster" deleted

→

-f - Specifies the config file to delete the cluster and node groups

Key Concept

If you remember nothing else from this pattern, remember: managed node groups let AWS handle servers, self-managed node groups give you control, and Fargate runs pods without servers.

Common Mistakes

Trying to SSH into Fargate nodes

Fargate runs serverless pods without actual nodes you can access.

Use logs and Kubernetes commands to debug Fargate pods instead of SSH.

Not specifying the correct namespace when checking pods on Fargate

Fargate profiles are tied to namespaces; pods outside those namespaces won't run on Fargate.

Always specify the namespace matching your Fargate profile when listing pods.

Modifying self-managed nodes manually without updating cluster state

Manual changes can cause drift and unexpected behavior in the cluster.

Use automation tools or eksctl to manage self-managed node groups consistently.

Summary

Create an EKS cluster with managed, self-managed node groups, and a Fargate profile using a single config file.

Use kubectl to verify nodes and pods; managed and self-managed nodes appear as nodes, Fargate pods run serverless.

Delete the cluster and all node groups cleanly with eksctl to avoid leftover resources.

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