Create an EKS Cluster with Managed, Self-Managed, and Fargate Node Groups
📖 Scenario: You are setting up a Kubernetes cluster on AWS using Amazon EKS. You want to create three types of node groups to run your workloads: a managed node group, a self-managed node group, and a Fargate profile for serverless compute.This setup helps you understand how to configure different node groups for various workload needs.
🎯 Goal: Build an Amazon EKS cluster with one managed node group, one self-managed node group, and one Fargate profile using AWS CloudFormation YAML syntax.This will demonstrate how to configure each node group type properly.
📋 What You'll Learn
Create an EKS cluster resource named MyEKSCluster.
Create a managed node group named ManagedNodeGroup attached to MyEKSCluster.
Create a self-managed node group using an Auto Scaling Group named SelfManagedNodeGroup.
Create a Fargate profile named MyFargateProfile for the cluster.
Use valid AWS CloudFormation YAML syntax with correct resource types and properties.
💡 Why This Matters
🌍 Real World
This project simulates setting up a Kubernetes cluster on AWS with different node group types to optimize cost and performance for various workloads.
💼 Career
Understanding how to configure managed, self-managed, and Fargate node groups is essential for cloud engineers and DevOps professionals working with AWS EKS.
Progress0 / 4 steps
1
Create the EKS Cluster Resource
Write the AWS CloudFormation YAML code to create an EKS cluster resource named MyEKSCluster with the Kubernetes version set to 1.27 and role ARN as arn:aws:iam::123456789012:role/EKSClusterRole.
AWS
Hint
Use AWS::EKS::Cluster resource type and specify Version and RoleArn properties.
2
Add a Managed Node Group
Add a managed node group resource named ManagedNodeGroup attached to the cluster MyEKSCluster. Use instance types t3.medium and set the node group scaling to minimum 1, maximum 3, and desired 2 nodes.
AWS
Hint
Use AWS::EKS::Nodegroup resource type and link it to MyEKSCluster with ClusterName.
3
Add a Self-Managed Node Group with Auto Scaling Group
Add a self-managed node group by creating an Auto Scaling Group resource named SelfManagedNodeGroup with launch configuration SelfManagedLaunchConfig. Use instance type t3.medium, minimum size 1, maximum size 3, and desired capacity 2. Attach the Auto Scaling Group to subnets subnet-abc12345 and subnet-def67890.
AWS
Hint
Create a launch configuration and an Auto Scaling Group with the specified properties.
4
Add a Fargate Profile for Serverless Compute
Add a Fargate profile resource named MyFargateProfile for the cluster MyEKSCluster. Set the pod execution role ARN to arn:aws:iam::123456789012:role/AmazonEKSFargatePodExecutionRole. Configure selectors to run pods in namespace default.
AWS
Hint
Use AWS::EKS::FargateProfile resource type and specify selectors for the default namespace.
Practice
(1/5)
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
Step 1: Understand node group types in EKS
Managed node groups are designed to let AWS handle the worker nodes, including updates and scaling.
Step 2: Compare with other node groups
Self-managed node groups require manual management of EC2 instances, and Fargate runs containers without servers.
Final Answer:
Managed node group -> Option B
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
Step 1: Recall Fargate profile setup
Fargate profiles use selectors to match pods by namespace and labels to run on Fargate.
Step 2: Eliminate incorrect options
EC2 instance types, Auto Scaling groups, and launch configurations relate to EC2, not Fargate.
Final Answer:
Define selectors with namespaces and labels for Fargate profile -> Option C
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
Step 1: Check pod namespace against Fargate profile
The pod is in 'production' namespace, which matches the Fargate profile selector.
Step 2: Understand pod scheduling priority
Pods matching Fargate profiles run on Fargate instead of node groups.
Final Answer:
Fargate -> Option D
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
Step 1: Understand self-managed node group requirements
Self-managed nodes must register with the cluster to run pods.
Step 2: Identify cause of Pending pods
If EC2 instances are not registered, pods cannot schedule and remain Pending.
Final Answer:
EC2 instances in the node group are not registered with the cluster -> Option A
Quick Check:
Unregistered EC2 nodes cause Pending pods [OK]
Hint: Self-managed nodes must register to run pods [OK]