EKS Cluster Creation Quiz - Part 1

This quiz tests your understanding of concepts, tools, and best practices related to Amazon EKS cluster creation. It covers topics such as cluster creation methods, VPC configuration, and node group setup.

Basic Concept Questions

Which is NOT a tool that can be used to create an Amazon EKS cluster?
- A) AWS Management Console
- B) AWS CLI
- C) eksctl
- D) kubectl

Show Answer

Answer: D) kubectl

Explanation: kubectl is a command-line tool for managing Kubernetes clusters, but it cannot be used to create EKS clusters. kubectl is used to connect to an existing Kubernetes cluster to manage resources.

Tools that can be used to create Amazon EKS clusters include:

AWS Management Console:
- Create EKS clusters through a web interface.
- Suitable for beginners as it allows visual configuration of cluster components.
- Guides through the cluster creation process via a step-by-step wizard.

AWS CLI:

Create EKS clusters from the command line.
Uses the aws eks create-cluster command.
Suitable for scripts and automation.

bash

aws eks create-cluster \
  --name my-cluster \
  --role-arn arn:aws:iam::123456789012:role/EksClusterRole \
  --resources-vpc-config subnetIds=subnet-12345,subnet-67890,securityGroupIds=sg-12345

eksctl:
- A command-line tool specifically designed for EKS cluster creation.
- An open-source tool developed by Weaveworks that simplifies EKS cluster creation and management.
- Can create a cluster with a single command.
bash
```
eksctl create cluster --name my-cluster --region us-west-2 --nodegroup-name standard-workers --node-type t3.medium --nodes 3 --nodes-min 1 --nodes-max 4
```
Infrastructure as Code (IaC) tools:
- AWS CloudFormation
- Terraform
- AWS CDK
- Pulumi
These tools allow defining and deploying EKS clusters as code.

kubectl is used to manage Kubernetes resources (pods, services, deployments, etc.) after a cluster is created. To connect to an EKS cluster, you must first update the kubectl configuration using the aws eks update-kubeconfig command.

bash

aws eks update-kubeconfig --name my-cluster --region us-west-2

After that, you can use kubectl to manage cluster resources.

What VPC component must be specified when creating an Amazon EKS cluster?
- A) Public subnets only
- B) Private subnets only
- C) Subnets across at least 2 availability zones
- D) NAT Gateway

Show Answer

Answer: C) Subnets across at least 2 availability zones

Explanation: When creating an Amazon EKS cluster, the VPC component that must be specified is subnets across at least 2 availability zones. This is an AWS requirement to ensure high availability of EKS clusters.

EKS cluster VPC requirements:

Subnets required in at least 2 availability zones (AZs):
- Since the EKS control plane is deployed across multiple availability zones, subnets must be specified in at least 2 availability zones when creating a cluster.
- This ensures the cluster continues to operate even during single availability zone failures.
Subnet types:
- You can use only public subnets, only private subnets, or a mix of public and private subnets.
- For production environments, it's recommended to place worker nodes in private subnets for security, and use public subnets for load balancers.
Subnet CIDR size:
- Each subnet must have sufficient IP addresses.
- Since EKS assigns VPC IP addresses to each pod, sufficiently large CIDR blocks are needed based on expected pod counts.
Tag requirements:
- Specific tags are required for EKS to identify and properly use subnets:
  - Shared subnets: kubernetes.io/cluster/<cluster-name>: shared
  - Public subnets: kubernetes.io/role/elb: 1
  - Private subnets: kubernetes.io/role/internal-elb: 1

VPC configuration example (using eksctl):

yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: us-west-2

vpc:
  cidr: 192.168.0.0/16
  clusterEndpoints:
    publicAccess: true
    privateAccess: true
  subnets:
    private:
      us-west-2a:
        id: subnet-0123456789abcdef0
      us-west-2b:
        id: subnet-0123456789abcdef1
    public:
      us-west-2a:
        id: subnet-0123456789abcdef2
      us-west-2b:
        id: subnet-0123456789abcdef3

VPC configuration using AWS CLI:

bash

aws eks create-cluster \
  --name my-cluster \
  --role-arn arn:aws:iam::123456789012:role/EksClusterRole \
  --resources-vpc-config subnetIds=subnet-0123456789abcdef0,subnet-0123456789abcdef1,subnet-0123456789abcdef2,subnet-0123456789abcdef3

A NAT Gateway is required when worker nodes in private subnets need internet access, but it is not a required component for EKS cluster creation itself. If using only public subnets, you can create a cluster without a NAT Gateway (not recommended for production environments).

What IAM roles are required when creating an Amazon EKS cluster?
- A) EKS service role only
- B) Node instance role only
- C) EKS service role and node instance role
- D) Fargate execution role

Show Answer

Answer: C) EKS service role and node instance role

Explanation: To create and operate an Amazon EKS cluster, two main IAM roles are required: the EKS service role and the node instance role. These two roles serve different purposes and are both necessary for proper cluster operation.

1. EKS Service Role (EKS Cluster Role):

Purpose: Allows the AWS EKS service to call other AWS services on behalf of users.
Required permissions:
- Access to AWS services such as EC2, ELB, CloudWatch, KMS, etc.
- VPC resource management
- Log group creation and management
Managed policy: AmazonEKSClusterPolicy

Creation method:

bash

# Create role using AWS CLI
aws iam create-role \
  --role-name EKSClusterRole \
  --assume-role-policy-document file://eks-cluster-trust-policy.json

# Attach managed policy
aws iam attach-role-policy \
  --role-name EKSClusterRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

Trust policy (eks-cluster-trust-policy.json):

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

2. Node Instance Role (Node Instance Role):

Purpose: Allows EKS worker nodes (EC2 instances) to interact with AWS services.
Required permissions:
- Pulling container images from ECR
- Writing logs to CloudWatch
- Managing EBS/EFS volumes
- Load balancer registration/deregistration
Managed policies:
- AmazonEKSWorkerNodePolicy
- AmazonEC2ContainerRegistryReadOnly
- AmazonEKS_CNI_Policy

Creation method:

bash

# Create role using AWS CLI
aws iam create-role \
  --role-name EKSNodeRole \
  --assume-role-policy-document file://ec2-trust-policy.json

# Attach managed policies
aws iam attach-role-policy \
  --role-name EKSNodeRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy

aws iam attach-role-policy \
  --role-name EKSNodeRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly

aws iam attach-role-policy \
  --role-name EKSNodeRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy

Trust policy (ec2-trust-policy.json):

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Automatic role creation using eksctl:

When creating a cluster using eksctl, the required IAM roles can be automatically created:

bash

eksctl create cluster --name my-cluster --region us-west-2

Additional roles (optional):

Fargate execution role: Required only when using Fargate profiles.
Service account IAM roles: Required when using IRSA (IAM Roles for Service Accounts).
ALB controller role: Required when using AWS Load Balancer Controller.

The Fargate execution role is only required when using Fargate profiles and is not mandatory for basic EKS cluster creation. Therefore, the IAM roles required to create an EKS cluster are the EKS service role and the node instance role.

What is the correct command to create an EKS cluster using eksctl?
- A) eksctl create-cluster --name my-cluster --region us-west-2
- B) eksctl create cluster --name my-cluster --region us-west-2
- C) eksctl new cluster --name my-cluster --region us-west-2
- D) eksctl start cluster --name my-cluster --region us-west-2

Show Answer

Answer: B) eksctl create cluster --name my-cluster --region us-west-2

Explanation: The correct command to create an EKS cluster using eksctl is eksctl create cluster --name my-cluster --region us-west-2. This command creates an EKS cluster with default settings in the specified name and region.

eksctl command structure:

eksctl: Base command
create: Action to create a resource
cluster: Type of resource to create (cluster)
--name my-cluster: Specify cluster name
--region us-west-2: Specify AWS region

Basic cluster creation command:

bash

eksctl create cluster --name my-cluster --region us-west-2

This command creates a cluster with the following default settings:

2 m5.large nodes
New VPC creation
Default Amazon Linux 2 AMI
Managed node groups
Automatic creation of required IAM roles

Advanced command with additional options:

bash

eksctl create cluster \
  --name my-cluster \
  --region us-west-2 \
  --nodegroup-name standard-workers \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 5 \
  --with-oidc \
  --ssh-access \
  --ssh-public-key my-key \
  --managed

Cluster creation using a configuration file:

bash

# Create cluster.yaml file
cat > cluster.yaml << EOF
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: us-west-2
  version: "1.28"

nodeGroups:
  - name: ng-1
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 1
    maxSize: 3
    ssh:
      allow: true
      publicKeyName: my-key
EOF

# Create cluster using configuration file
eksctl create cluster -f cluster.yaml

Problems with other options:

eksctl create-cluster: Incorrect command format. eksctl uses spaces, not hyphens (-), to separate commands.
eksctl new cluster: 'new' is not a valid eksctl command.
eksctl start cluster: 'start' is not a valid eksctl command. The concept of starting an existing cluster does not apply to EKS.

eksctl provides various commands for EKS cluster management:

eksctl create cluster: Create a new cluster
eksctl get cluster: List clusters
eksctl update cluster: Update a cluster
eksctl delete cluster: Delete a cluster
eksctl create nodegroup: Add a node group
eksctl scale nodegroup: Scale a node group

What is correct regarding Kubernetes versions that can be specified when creating an Amazon EKS cluster?
- A) Only the latest version is supported
- B) Only the latest version and the previous 2 versions are supported
- C) All Kubernetes versions supported by AWS
- D) All Kubernetes versions

Show Answer

Answer: C) All Kubernetes versions supported by AWS

Explanation: When creating an Amazon EKS cluster, you can choose from Kubernetes versions currently supported by AWS. AWS typically supports multiple Kubernetes versions simultaneously, including the latest version and several previous versions.

EKS Kubernetes version support policy:

Support period:
- Each Kubernetes version is supported for 14 months after its release on EKS.
- End of support dates are announced at least 60 days in advance.
Supported versions:
- Typically, EKS supports 3-4 Kubernetes versions simultaneously.
- New versions become available on EKS within a few months of the Kubernetes community release.

How to check versions:

bash

# Check supported versions using AWS CLI
aws eks describe-addon-versions | grep kubernetesVersion | sort -u

# Or
aws eks get-cluster-version-list

Version specification examples:

bash

# Specify a specific version using eksctl
eksctl create cluster --name my-cluster --version 1.28 --region us-west-2

# Specify a specific version using AWS CLI
aws eks create-cluster \
  --name my-cluster \
  --kubernetes-version 1.28 \
  --role-arn arn:aws:iam::123456789012:role/EksClusterRole \
  --resources-vpc-config subnetIds=subnet-12345,subnet-67890

Version upgrades:
- After cluster creation, you can upgrade to supported versions.
- It's generally recommended to upgrade one minor version at a time.
bash
```
# Cluster version upgrade
aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.28
```

Considerations when selecting a version:

Stability:
- The latest version provides new features but may have initial bugs.
- For production environments where stability is important, it may be better to select a proven previous version.
Feature requirements:
- If specific Kubernetes features are needed, you must select the minimum version that supports those features.
Support period:
- For long-term support, select a recently released version to maximize the support period.
Ecosystem compatibility:
- Ensure that the tools, add-ons, and operators you're using are compatible with the selected Kubernetes version.

Problems with other options:

Not only the latest version is supported; multiple versions are supported simultaneously.
The number of supported versions is not fixed to "the latest version and previous 2 versions" but varies according to AWS's support policy.
Not all Kubernetes versions are supported; only versions tested and supported by AWS can be used.

What is NOT an option for creating node groups in an Amazon EKS cluster?
- A) Managed node groups
- B) Self-managed node groups
- C) Fargate profiles
- D) Serverless node groups

Show Answer

Answer: D) Serverless node groups

Explanation: "Serverless node groups" is not a concept that exists in Amazon EKS. The three main options for running workloads in EKS are managed node groups, self-managed node groups, and Fargate profiles.

1. Managed Node Groups:

Features:
- AWS manages node provisioning and lifecycle
- Automatic EC2 instance creation and registration
- Automatic ASG (Auto Scaling Group) configuration
- Automatic Kubernetes version upgrades
- Automatic replacement of damaged nodes
- Automatic node AMI updates

Creation method:

bash

# Create managed node group using eksctl
eksctl create nodegroup \
  --cluster my-cluster \
  --name my-mng \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 5

# Create managed node group using AWS CLI
aws eks create-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name my-mng \
  --subnets subnet-12345 subnet-67890 \
  --instance-types t3.medium \
  --scaling-config minSize=1,maxSize=5,desiredSize=3 \
  --node-role arn:aws:iam::123456789012:role/EksNodeRole

2. Self-managed Node Groups:

Features:
- User manages node provisioning and lifecycle
- More customization options
- Can use custom AMIs or bootstrap scripts
- Suitable for specific instance types or configuration requirements

Creation method:

bash

# Create self-managed node group using eksctl
eksctl create nodegroup \
  --cluster my-cluster \
  --name my-smng \
  --node-type t3.medium \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 5 \
  --managed=false

# Can also be created manually using CloudFormation or EC2 launch templates.

3. Fargate Profiles:

Features:
- Serverless container execution environment
- No node management required
- Per-pod resource allocation and billing
- Selective execution based on specific namespaces and labels

Creation method:

bash

# Create Fargate profile using eksctl
eksctl create fargateprofile \
  --cluster my-cluster \
  --name my-fargate-profile \
  --namespace my-namespace \
  --labels app=my-app

# Create Fargate profile using AWS CLI
aws eks create-fargate-profile \
  --cluster-name my-cluster \
  --fargate-profile-name my-fargate-profile \
  --pod-execution-role-arn arn:aws:iam::123456789012:role/FargatePodExecutionRole \
  --selectors namespace=my-namespace,labels={app=my-app}

Comparison of each option:

Feature	Managed Node Groups	Self-managed Node Groups	Fargate Profiles
Management overhead	Low	High	None
Customization	Medium	High	Low
Cost efficiency	Medium	High (when optimized)	Low (paying for convenience)
Scalability	Automatic	Manual/Automatic	Automatic
Use case	General workloads	Special requirements	Variable workloads, dev/test

The term "serverless node groups" does not officially exist. Fargate provides a serverless container execution environment, but it is configured as "Fargate profiles," not "node groups." When using Fargate, you don't need to manage nodes directly, and only the compute resources needed for pod execution are provisioned.

What is NOT a supported node AMI type in Amazon EKS clusters?
- A) Amazon Linux 2
- B) Amazon Linux 2023
- C) Bottlerocket
- D) Ubuntu Core

Show Answer

Answer: D) Ubuntu Core

Explanation: Ubuntu Core is not an officially supported node AMI type in Amazon EKS. The officially supported node AMI types in EKS are Amazon Linux 2, Amazon Linux 2023, and Bottlerocket.

Supported node AMI types in EKS:

Amazon Linux 2 (AL2):
- Default Linux distribution provided by AWS
- Available as EKS optimized AMI
- Recommended for most EKS workloads
- Long-term support and security updates
bash
```
# Create Amazon Linux 2 based node group
eksctl create nodegroup \
  --cluster my-cluster \
  --name al2-nodes \
  --node-ami-family AmazonLinux2
```

Amazon Linux 2023 (AL2023):

Latest version of Amazon Linux
Enhanced security and performance
Latest kernel and software packages
Available as EKS optimized AMI

bash

# Create Amazon Linux 2023 based node group
eksctl create nodegroup \
  --cluster my-cluster \
  --name al2023-nodes \
  --node-ami-family AmazonLinux2023

Bottlerocket:

Open-source Linux-based OS optimized for container workloads
Minimized attack surface
Transaction-based updates
Container-centric design

bash

# Create Bottlerocket based node group
eksctl create nodegroup \
  --cluster my-cluster \
  --name bottlerocket-nodes \
  --node-ami-family Bottlerocket

Other supported AMI options:

Windows:

Windows Server 2019, 2022 based AMIs
Can run Windows container workloads

bash

# Create Windows based node group
eksctl create nodegroup \
  --cluster my-cluster \
  --name windows-nodes \
  --node-ami-family WindowsServer2022FullContainer

Custom AMIs:

Can use custom AMIs for specific requirements
Mainly used with self-managed node groups

bash

# Create custom AMI based node group
eksctl create nodegroup \
  --cluster my-cluster \
  --name custom-nodes \
  --node-ami ami-1234567890abcdef0

How to use Ubuntu in EKS:

Ubuntu Core is not officially supported, but you can create self-managed node groups using standard Ubuntu Server AMIs. In this case, additional configuration is required:

Select Ubuntu Server AMI
Install necessary Kubernetes components
Use bootstrap script to connect nodes to the cluster

bash

# Example of creating Ubuntu-based self-managed node group
eksctl create nodegroup \
  --cluster my-cluster \
  --name ubuntu-nodes \
  --node-ami ami-ubuntu-server-id \
  --managed=false \
  --ssh-access \
  --ssh-public-key my-key \
  --pre-bootstrap-commands 'apt-get update && apt-get install -y docker.io'

Considerations when selecting AMI:

Security: Regular security updates and patches
Performance: Kernel and configuration optimized for workload
Compatibility: Compatibility with Kubernetes version
Ease of management: Update and maintenance processes
Special requirements: GPU support, kernel modules, etc.

Ubuntu Core is a lightweight operating system for IoT and edge devices, and is not officially supported or optimized for use as EKS nodes. Therefore, Ubuntu Core is not a supported node AMI type in EKS clusters.

What is correct regarding endpoint access configuration for Amazon EKS clusters?
- A) By default, only the public endpoint is enabled
- B) By default, only the private endpoint is enabled
- C) By default, both public and private endpoints are enabled
- D) Endpoint access cannot be changed after cluster creation

Show Answer

Answer: A) By default, only the public endpoint is enabled

Explanation: When creating an Amazon EKS cluster, by default, only the public endpoint is enabled and the private endpoint is disabled. This configuration can be changed after cluster creation, and various endpoint access configurations can be selected according to security requirements.

EKS cluster endpoint access options:

Public endpoint only enabled (default setting):
- Cluster API server accessible via the internet
- Access can be restricted through security groups
- Suitable for development or test environments
bash
```
# Configuration using AWS CLI
aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=false
```

Both public and private endpoints enabled:

Accessible via private IP from within the VPC
Also accessible via the internet
Suitable for hybrid environments

bash

# Configuration using AWS CLI
aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true

Private endpoint only enabled:
- Cluster API server accessible only from within the VPC
- No access via the internet
- Provides the highest level of security
- Recommended for production environments
bash
```
# Configuration using AWS CLI
aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true
```

Restricting public access:

Allow public endpoint access only from specific CIDR blocks
Restrict access only from company network or VPN

bash

# Configuration using AWS CLI
aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=true,endpointPrivateAccess=true,publicAccessCidrs=["203.0.113.0/24","198.51.100.0/24"]

Endpoint configuration when creating cluster with eksctl:

yaml

# cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: us-west-2

vpc:
  clusterEndpoints:
    publicAccess: true   # Enable public endpoint
    privateAccess: true  # Enable private endpoint
  publicAccessCIDRs: ["203.0.113.0/24"]  # Restrict public access

bash

eksctl create cluster -f cluster.yaml

Changing endpoint access configuration:

bash

# Enable private endpoint
aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPrivateAccess=true

# Disable public endpoint
aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=false

Considerations when configuring endpoint access:

Security requirements:
- Using only private endpoint provides the highest level of security
- Apply CIDR restrictions when public access is needed
Network connectivity:
- When using only private endpoint, access is only possible from within VPC or via VPN/Direct Connect
- Enabling both endpoints can be useful in hybrid work environments
Operational requirements:
- Consider when CI/CD pipelines, external tools, etc. need cluster access
Cost:
- No additional cost for endpoint configuration itself
- Consider VPN or Direct Connect costs when using only private endpoint

Problems with other options:

By default, only the public endpoint is enabled, not the private endpoint.
By default, not both public and private endpoints are enabled; only the public endpoint is enabled.
Endpoint access can be changed after cluster creation.

What is NOT a consideration when selecting instance types for node groups in Amazon EKS clusters?
- A) Workload requirements (CPU, memory, storage)
- B) Cost optimization
- C) Number of availability zones
- D) Instance generation (e.g., t3 vs t2)

Show Answer

Answer: C) Number of availability zones

Explanation: The number of availability zones is not a direct consideration when selecting instance types for node groups. Availability zones are related to where node groups are deployed, and are separate from the selection of instance types themselves. Instance types should be selected considering workload requirements, cost optimization, instance generation, etc.

Actual considerations when selecting node group instance types:

Workload requirements (CPU, memory, storage):
- Select instance types that match application resource requirements
- Memory-intensive workloads: Memory optimized instances such as r5, r6g
- Compute-intensive workloads: Compute optimized instances such as c5, c6g
- Balanced workloads: General purpose instances such as m5, m6g
- GPU workloads: Accelerated computing instances such as p3, g4dn
Cost optimization:
- On-demand vs Spot instances
- Reserved Instances or Savings Plans
- Proper size instance selection (avoid over-provisioning)
- Cost savings through ARM-based Graviton instances (e.g., m6g, c6g)
Instance generation:
- Latest generation instances generally offer better performance and cost efficiency
- Example: t3 offers better performance and price-to-performance than t2
- Latest generations provide enhanced networking, storage performance, etc.
Networking requirements:
- Enhanced networking support (ENA, EFA, etc.)
- Network bandwidth requirements
- Networking limits related to maximum pods per instance
Storage requirements:
- Whether local instance storage is needed (e.g., i3, d3 instances)
- EBS optimization support
- Storage throughput and IOPS requirements
CPU architecture:
- x86 (Intel, AMD) vs ARM (AWS Graviton)
- Application compatibility considerations

Availability zones and node group deployment:

The number of availability zones is related to node group deployment strategy, not instance type selection:

Deploy node groups across multiple availability zones for high availability
Distribute nodes evenly across each availability zone
Can select all availability zones in the region or specific availability zones

bash

# Deploy node group to specific availability zones
eksctl create nodegroup \
  --cluster my-cluster \
  --name my-nodegroup \
  --node-type m5.large \
  --nodes 3 \
  --nodes-min 1 \
  --nodes-max 5 \
  --node-zones us-west-2a,us-west-2b

Instance type selection examples:

Web application servers:
- General purpose instances: t3.medium, m5.large
- Cost-effective with balanced performance
Databases:
- Memory optimized instances: r5.xlarge, r6g.xlarge
- High memory to CPU ratio
Batch processing jobs:
- Compute optimized instances: c5.xlarge, c6g.xlarge
- High CPU performance
Machine learning workloads:
- GPU instances: p3.2xlarge, g4dn.xlarge
- Accelerated computing capabilities

Instance type selection should be determined by workload characteristics, cost constraints, performance requirements, etc., and the number of availability zones is related to node group deployment strategy rather than the selection of instance types themselves.

What is the correct command to configure kubectl after creating an Amazon EKS cluster?
- A) aws eks update-kubeconfig --name my-cluster --region us-west-2
- B) aws eks get-kubeconfig --name my-cluster --region us-west-2
- C) kubectl config set-cluster my-cluster --region us-west-2
- D) eksctl configure kubectl --name my-cluster --region us-west-2

Show Answer

Answer: A) aws eks update-kubeconfig --name my-cluster --region us-west-2

Explanation: The correct command to configure kubectl after creating an Amazon EKS cluster is aws eks update-kubeconfig --name my-cluster --region us-west-2. This command uses the AWS CLI's EKS module to update the kubeconfig file for the specified cluster.

kubectl configuration process:

Updating kubeconfig file:
- The kubeconfig file stores configuration information needed for kubectl to communicate with Kubernetes clusters.
- By default, it is stored at ~/.kube/config.
- The aws eks update-kubeconfig command automatically updates this file.
Command components:
- --name: EKS cluster name
- --region: AWS region where the cluster is located
- --kubeconfig (optional): Custom kubeconfig file path
- --role-arn (optional): IAM role to use for cluster access

Full command example:

bash

aws eks update-kubeconfig --name my-cluster --region us-west-2

Additional options:

bash

# Use custom kubeconfig file
aws eks update-kubeconfig --name my-cluster --region us-west-2 --kubeconfig ~/.kube/eks-config

# Use specific IAM role
aws eks update-kubeconfig --name my-cluster --region us-west-2 --role-arn arn:aws:iam::123456789012:role/EksAdminRole

# Set alias
aws eks update-kubeconfig --name my-cluster --region us-west-2 --alias my-cluster-alias

Verify configuration:

bash

# Check current context
kubectl config current-context

# List all contexts
kubectl config get-contexts

# Test cluster connection
kubectl cluster-info

Problems with other options:

aws eks get-kubeconfig --name my-cluster --region us-west-2: This command does not exist. There is no get-kubeconfig subcommand in AWS CLI.
kubectl config set-cluster my-cluster --region us-west-2: This command has incorrect syntax. kubectl config set-cluster does not support the --region flag and does not automatically configure the authentication information needed for EKS clusters.
eksctl configure kubectl --name my-cluster --region us-west-2: This command does not exist. eksctl does not have a configure kubectl subcommand. When creating a cluster with eksctl, kubeconfig is automatically configured, but for existing clusters, you must use the aws eks update-kubeconfig command.

Cluster creation and configuration using eksctl:

When creating a cluster using eksctl, kubeconfig is automatically updated:

bash

eksctl create cluster --name my-cluster --region us-west-2

This command creates the cluster and automatically updates kubeconfig. However, to connect to an existing cluster or a cluster created by another tool, you must use the aws eks update-kubeconfig command.

Managing multiple clusters:

When managing multiple EKS clusters, you can add them to the kubeconfig file by running the aws eks update-kubeconfig command for each cluster:

bash

# Configure first cluster
aws eks update-kubeconfig --name cluster1 --region us-west-2

# Configure second cluster
aws eks update-kubeconfig --name cluster2 --region us-east-1

# Switch context
kubectl config use-context arn:aws:eks:us-west-2:123456789012:cluster/cluster1

Therefore, the correct command to configure kubectl after creating an Amazon EKS cluster is aws eks update-kubeconfig --name my-cluster --region us-west-2.

Hands-on Exercises

Exercise 1: Create EKS Cluster Using eksctl

Scenario: You are a DevOps engineer at your company and need to create an Amazon EKS cluster for the development team. The cluster should be cost-effective yet scalable, with basic security settings.

Requirements:

Create EKS cluster using eksctl
Deploy across 2 availability zones
Use t3.medium instance type
Configure auto-scaling (minimum 2, maximum 5 nodes)
Enable both private and public endpoints

Solution:

Show Answer

1. Install eksctl (if not already installed)

bash

# macOS
brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

# Linux
curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version

2. Create cluster configuration file

bash

cat > eks-cluster.yaml << EOF
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: dev-cluster
  region: us-west-2
  version: "1.28"

vpc:
  clusterEndpoints:
    publicAccess: true
    privateAccess: true

availabilityZones: ["us-west-2a", "us-west-2b"]

managedNodeGroups:
  - name: ng-1
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 2
    maxSize: 5
    iam:
      withAddonPolicies:
        imageBuilder: true
        autoScaler: true
        externalDNS: true
        certManager: true
        ebs: true
        albIngress: true
        cloudWatch: true
    ssh:
      allow: false
    privateNetworking: true
    tags:
      Environment: development
      Owner: devops-team
EOF

3. Create the cluster

bash

eksctl create cluster -f eks-cluster.yaml

This command performs the following tasks:

Creates CloudFormation stacks
Creates VPC and subnets
Configures security groups
Creates EKS cluster
Creates managed node groups
Bootstraps nodes and connects to cluster
Configures kubeconfig

4. Verify the cluster

bash

# Check cluster status
eksctl get cluster --name dev-cluster --region us-west-2

# Check nodes
kubectl get nodes -o wide

# Check system pods
kubectl get pods -n kube-system

5. Configure cluster access

bash

# Verify kubeconfig
kubectl config current-context

# Check cluster information
kubectl cluster-info

6. Verify basic security settings

bash

# Check namespaces
kubectl get namespaces

# Check RBAC settings
kubectl get clusterroles
kubectl get clusterrolebindings

7. Monitor cluster resources

bash

# Check node resource usage
kubectl top nodes

# Check pod resource usage
kubectl top pods --all-namespaces

Through this exercise, you learned how to create a cost-effective and scalable EKS cluster using eksctl. t3.medium instances are a cost-effective choice, and auto-scaling configuration allows automatic adjustment of node count based on workload. Both private and public endpoints were enabled to allow cluster access from both internal and external sources.

Exercise 2: Create EKS Cluster Using AWS Management Console

Scenario: You need to create and configure an EKS cluster using the AWS Management Console. This cluster is for a production environment where security and high availability are important.

Requirements:

Create EKS cluster using AWS Management Console
Place nodes in private subnets
Restrict public access to cluster endpoint
Configure managed node groups
Create required IAM roles

Solution:

Show Answer

1. Create required IAM roles

Create EKS cluster role:

Log in to AWS Management Console and navigate to IAM service.
Select "Roles" in the left menu and click "Create role".
Select "AWS service" as the trusted entity type.
Under use case, select "EKS" and then "EKS - Cluster".
Click "Next".
Verify that AmazonEKSClusterPolicy is automatically selected.
Click "Next".
Enter "EKSClusterRole" as the role name and click "Create role".

Create EKS node role:

Click "Create role" again in IAM service.
Select "AWS service" as the trusted entity type.
Select "EC2" under use case.
Click "Next".
Search and select the following policies:
- AmazonEKSWorkerNodePolicy
- AmazonEC2ContainerRegistryReadOnly
- AmazonEKS_CNI_Policy
Click "Next".
Enter "EKSNodeRole" as the role name and click "Create role".

2. Prepare VPC and subnets

A proper VPC configuration is required for production environments. You can use an AWS CloudFormation template to create an EKS-optimized VPC:

Navigate to the CloudFormation console.
Select "Create stack" > "With new resources (standard)".

Enter the following address in Amazon S3 URL:

https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml

Click "Next".
Enter "eks-vpc" as the stack name.
Leave default parameters and click "Next".
Leave default options on the next page and click "Next".
Click "Create stack".
Once stack creation is complete, note the following values from the "Outputs" tab:
- VpcId
- SubnetIds
- SecurityGroups

3. Create EKS cluster

Navigate to EKS service in AWS Management Console.
Click "Create cluster".
On the "Cluster configuration" page:
- Cluster name: "prod-cluster"
- Kubernetes version: Select latest version (e.g., 1.28)
- Cluster service role: Select previously created "EKSClusterRole"
- Click "Next".
On the "Specify networking" page:
- VPC: Select previously created VPC
- Subnets: Select only private subnets (deselect public subnets)
- Security groups: Select default security group
- Cluster endpoint access:
  - Select "Private" or
  - Select "Public and Private" and restrict CIDR blocks to company IP range
- Click "Next".
On the "Configure logging" page:
- Select required log types (API server, Audit, Authenticator, Controller manager, Scheduler)
- Click "Next".
On the "Select add-ons" page:
- Keep default add-ons (kube-proxy, CoreDNS, VPC CNI)
- Click "Next".
Review all settings on the review page and click "Create".
Wait for cluster creation to complete (approximately 15-20 minutes).

4. Create managed node group

Once cluster is created, click on the cluster name.
Go to the "Compute" tab and click "Add node group".
On the "Node group configuration" page:
- Name: "prod-nodes"
- Node IAM role: Select previously created "EKSNodeRole"
- Click "Next".
On the "Set compute and scaling configuration" page:
- AMI type: Amazon Linux 2 (x86)
- Instance type: Select m5.large
- Disk size: 50 GiB
- Node group scaling configuration:
  - Minimum size: 2
  - Maximum size: 5
  - Desired size: 3
- Click "Next".
On the "Specify networking" page:
- Subnets: Select only private subnets
- Click "Next".
Review all settings on the "Review and create" page and click "Create".
Wait for node group creation to complete (approximately 5 minutes).

5. Configure kubectl and access cluster

Verify that AWS CLI is installed.

Run the following command to update kubectl configuration file:

bash

aws eks update-kubeconfig --name prod-cluster --region us-west-2

Verify cluster connection:
bash
```
kubectl get nodes
kubectl cluster-info
```

6. Enhance basic security

Review and restrict AWS security group rules:

bash

# Check cluster information for current context
kubectl config view --minify

Apply network policies (optional):

yaml

# default-deny.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

bash

kubectl apply -f default-deny.yaml

Through this exercise, you learned how to create an EKS cluster with security and high availability settings suitable for production environments using AWS Management Console. Security was enhanced by placing nodes in private subnets and restricting public access to the cluster endpoint, and node management was simplified by using managed node groups.

Advanced Topics

The following are questions about advanced topics related to Amazon EKS cluster creation. This section tests your understanding of advanced concepts and best practices for EKS cluster creation.

What is the main benefit of using custom Launch Templates in Amazon EKS clusters?
- A) Reduced cluster creation time
- B) Customizable node bootstrap scripts and additional volume configuration
- C) Cluster control plane customization
- D) Automatically uses latest AMI version

Show Answer

Answer: B) Customizable node bootstrap scripts and additional volume configuration

Explanation: The main benefit of using custom Launch Templates in Amazon EKS clusters is the ability to customize node bootstrap scripts and configure additional volumes. Launch templates allow fine-grained control over various aspects of EC2 instances, enabling advanced configurations not possible with default node group creation options.

Customizable items with Launch Templates:

Custom bootstrap scripts:

Define custom scripts that run before nodes join the cluster
Install and configure additional software
Adjust system settings (kernel parameters, network settings, etc.)

Example:

bash

#!/bin/bash
# Custom bootstrap script
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p

# Install additional packages
yum install -y amazon-cloudwatch-agent

# Run EKS bootstrap script
/etc/eks/bootstrap.sh my-cluster --kubelet-extra-args '--node-labels=node.kubernetes.io/role=worker'

Additional volume configuration:

Customize root volume size, type, IOPS
Attach additional EBS volumes for data, logs, temporary storage
Configure instance store volumes

Example:

json

{
  "DeviceName": "/dev/xvda",
  "Ebs": {
    "VolumeSize": 100,
    "VolumeType": "gp3",
    "Iops": 3000,
    "Throughput": 125,
    "DeleteOnTermination": true
  }
},
{
  "DeviceName": "/dev/sdf",
  "Ebs": {
    "VolumeSize": 500,
    "VolumeType": "gp3",
    "DeleteOnTermination": true
  }
}

Advanced networking configuration:

Enable enhanced networking
Configure multiple network interfaces
Specify placement groups

Example:

json

{
  "NetworkInterfaces": [
    {
      "DeviceIndex": 0,
      "Groups": ["sg-12345"],
      "DeleteOnTermination": true
    }
  ]
}

Instance metadata options:

Require IMDSv2 (enhanced security)
Set hop limit

Example:

json

{
  "MetadataOptions": {
    "HttpTokens": "required",
    "HttpPutResponseHopLimit": 2
  }
}

User data scripts:
- Provide scripts that run on instance startup
- Perform custom configuration before cluster join
- Example:
  bash
```
#!/bin/bash
# User data script
mkdir -p /opt/app
mount -t tmpfs -o size=10G tmpfs /opt/app
```

Creating and using Launch Templates:

Create Launch Template in AWS Management Console:
- EC2 Console > Launch Templates > Create launch template
- Configure AMI, instance type, key pair, security groups, etc.
- Configure advanced settings like storage, network interfaces, user data

Create node group based on launch template using eksctl:

yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: my-cluster
  region: us-west-2

managedNodeGroups:
  - name: custom-ng
    launchTemplate:
      id: lt-12345abcdef
      version: "1"

Create node group based on launch template using AWS CLI:

bash

aws eks create-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name custom-ng \
  --launch-template id=lt-12345abcdef,version=1 \
  --subnets subnet-12345 subnet-67890 \
  --node-role arn:aws:iam::123456789012:role/EKSNodeRole

Problems with other options:

Reduced cluster creation time: Using launch templates does not reduce cluster creation time. In fact, additional configuration may make it take slightly longer.
Cluster control plane customization: Launch templates only apply to worker nodes; the EKS control plane is managed by AWS and cannot be customized through launch templates.
Automatically uses latest AMI version: Launch templates specify a specific AMI ID, which actually has the effect of locking the AMI version. To automatically use the latest AMI, you must either not use launch templates or regularly update the launch template.

Launch templates are particularly useful when advanced customization of EKS node groups is needed, and should be used when there are special requirements that cannot be met with standard configuration.

What is NOT a cost optimization strategy for Amazon EKS clusters?
- A) Using Spot instances
- B) Configuring Cluster Autoscaler
- C) Using the latest instance types for all worker nodes
- D) Selective use of Fargate profiles

Show Answer

Answer: C) Using the latest instance types for all worker nodes

Explanation: Using the latest instance types for all worker nodes is not necessarily a cost optimization strategy. The latest instance types often provide better performance and features, but are not always cost-effective. Selecting appropriate instance types that match workload requirements is more important.

Actual cost optimization strategies for EKS clusters:

Using Spot instances:

Up to 90% cost savings compared to On-Demand instances
Suitable for interruptible workloads (batch jobs, dev/test environments, etc.)

Configure Spot instances in managed node groups:

bash

eksctl create nodegroup \
  --cluster my-cluster \
  --name spot-ng \
  --node-type m5.large \
  --nodes 2 \
  --nodes-min 1 \
  --nodes-max 5 \
  --spot

Mix multiple instance types to improve availability:

yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: us-west-2
managedNodeGroups:
  - name: spot-ng
    instanceTypes: ["m5.large", "m5a.large", "m5d.large", "m5ad.large"]
    spot: true

Configuring Cluster Autoscaler:

Automatically adjust node count based on workload requirements
Cost savings by automatically removing unused nodes

Installation and configuration:

bash

# Install Cluster Autoscaler using Helm
helm repo add autoscaler https://kubernetes.github.io/autoscaler

helm install cluster-autoscaler autoscaler/cluster-autoscaler \
  --namespace kube-system \
  --set autoDiscovery.clusterName=my-cluster \
  --set awsRegion=us-west-2 \
  --set rbac.create=true

Selective use of Fargate profiles:
- Serverless container execution environment eliminates node management overhead
- Pay only for resources used
- Suitable for intermittent workloads or dev/test environments
- Use Fargate only for specific namespaces or labels:
  bash
```
eksctl create fargateprofile \
  --cluster my-cluster \
  --name fp-dev \
  --namespace dev
```
Selecting appropriate instance sizes:
- Select instance sizes that match workload requirements
- Prevent over-provisioning
- Monitor and analyze resource usage:
  bash
```
kubectl top nodes
kubectl top pods --all-namespaces
```
Using Graviton (ARM) based instances:
- Up to 40% cost savings compared to x86-based instances
- Provides equivalent performance
- Compatibility verification required
- Example:
  bash
```
eksctl create nodegroup \
  --cluster my-cluster \
  --name arm-ng \
  --node-type m6g.large \
  --nodes 2
```
Utilizing Reserved Instances or Savings Plans:
- Cost savings through long-term commitments
- Suitable for predictable workloads
- Up to 72% cost savings compared to On-Demand
Optimizing resource requests and limits:
- Improve node utilization by properly setting pod resource requests
- Prevent over-provisioning
- Example:
  yaml
```
resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi
```
Cost monitoring and analysis:
- Use AWS Cost Explorer
- Set Kubernetes cost allocation tags
- Use third-party cost monitoring tools (Kubecost, CloudHealth, etc.)

Problems with using the latest instance types:

Increased costs:
- Latest instance types can often be more expensive than previous generations
- Not all workloads require features of latest instances
Over-provisioning:
- Providing resources exceeding workload requirements
- Results in unnecessary costs
Availability limitations:
- Latest instance types may not be available in all regions or availability zones
- Especially limited availability when using Spot instances
Compatibility issues:
- Some workloads may be optimized for specific instance types
- Testing required when transitioning to new instance types

For cost optimization, it's important to comprehensively consider workload characteristics, resource requirements, availability requirements, etc., and select appropriate instance types and sizes. The latest instance types are not always the most cost-effective choice, and selecting appropriate instance types for the workload is more important.

What is the correct way to configure a private cluster in Amazon EKS?
- A) Place nodes only in private subnets and disable public endpoint
- B) Place nodes only in private subnets and enable public endpoint
- C) Place nodes in public subnets and disable public endpoint
- D) Place nodes only in private subnets without VPC endpoints

Show Answer

Answer: A) Place nodes only in private subnets and disable public endpoint

Explanation: To configure a fully private cluster in Amazon EKS, you need to place nodes only in private subnets and disable the public endpoint. This ensures that the cluster's Kubernetes API server is not accessible from the internet, and all traffic occurs only within the VPC.

Private EKS cluster configuration components:

Endpoint access configuration:

Disable public endpoint
Enable private endpoint

AWS CLI configuration example:

bash

aws eks update-cluster-config \
  --name my-cluster \
  --resources-vpc-config endpointPublicAccess=false,endpointPrivateAccess=true

eksctl configuration example:

yaml

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
  region: us-west-2
vpc:
  clusterEndpoints:
    publicAccess: false
    privateAccess: true

Node placement:

Place nodes only in private subnets
No public IP assignment

Managed node group configuration example:

bash

eksctl create nodegroup \
  --cluster my-cluster \
  --name private-ng \
  --node-type m5.large \
  --nodes 3 \
  --node-private-networking \
  --subnet-ids subnet-private1,subnet-private2

VPC endpoint configuration: VPC endpoints required for private clusters to access AWS services:

com.amazonaws.region.ecr.api
com.amazonaws.region.ecr.dkr
com.amazonaws.region.s3
com.amazonaws.region.logs (optional)
com.amazonaws.region.sts (optional)

bash

# Create ECR API endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345 \
  --service-name com.amazonaws.us-west-2.ecr.api \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-private1 subnet-private2 \
  --security-group-ids sg-12345 \
  --private-dns-enabled

# Create ECR Docker endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345 \
  --service-name com.amazonaws.us-west-2.ecr.dkr \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-private1 subnet-private2 \
  --security-group-ids sg-12345 \
  --private-dns-enabled

# Create S3 endpoint (Gateway type)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345 \
  --service-name com.amazonaws.us-west-2.s3 \
  --vpc-endpoint-type Gateway \
  --route-table-ids rtb-12345

Network configuration:
- NAT Gateway or VPC endpoints required in private subnets
- Traffic restriction with security group rules
- Routing table configuration

Methods to access private clusters:

Access via VPN or Direct Connect:
- AWS Client VPN
- AWS Site-to-Site VPN
- AWS Direct Connect

Access via Bastion Host:

Place bastion host in public subnet
Access cluster API server from bastion host

bash

# Configure kubeconfig on bastion host
aws eks update-kubeconfig --name my-cluster --region us-west-2

Access via AWS Systems Manager Session Manager:
- Access EC2 instances without internet gateway
- Access control through IAM permissions and logging

Problems with other options:

Place nodes only in private subnets and enable public endpoint: When the public endpoint is enabled, the cluster API server is accessible from the internet, so this is not a fully private cluster. Access can be restricted with security groups or CIDR restrictions, but it's still exposed to public networks.
Place nodes in public subnets and disable public endpoint: When nodes are in public subnets, they can be directly accessed from the internet, so this is not a fully private cluster. Access can be restricted with security groups, but nodes may be assigned public IPs.
Place nodes only in private subnets without VPC endpoints: Placing nodes in private subnets without VPC endpoints prevents nodes from accessing AWS services like ECR, S3, etc. In this case, internet access via NAT Gateway would be required, which is not a fully private cluster configuration.

Private EKS clusters are suitable for environments requiring high security, ensuring all cluster traffic occurs only within the VPC. However, configuration is more complex, and additional infrastructure (VPN, Direct Connect, bastion hosts, etc.) may be needed for cluster access.

What is NOT a valid node group upgrade strategy in Amazon EKS clusters?
- A) Rolling upgrade
- B) Blue/Green deployment
- C) In-place upgrade
- D) Canary deployment

Show Answer

Answer: C) In-place upgrade

Explanation: "In-place upgrade" is not an official upgrade strategy for Amazon EKS node groups. EKS managed node groups use a rolling upgrade approach by default, and for self-managed node groups, strategies like blue/green deployment or canary deployment can be implemented.

EKS node group upgrade strategies:

Rolling Upgrade:
- Default upgrade method for EKS managed node groups
- Minimizes workload disruption by replacing nodes one at a time
- Process:
  1. Create new node
  2. Apply cordoning to existing node (prevent new pod scheduling)
  3. Drain pods from existing node (migrate pods)
  4. Terminate existing node
  5. Repeat for next node
- Configuration example:
  bash
```
# Managed node group upgrade
aws eks update-nodegroup-version \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup

# Check upgrade status
aws eks describe-update \
  --name <update-id> \
  --nodegroup-name my-nodegroup \
  --cluster-name my-cluster
```

Blue/Green Deployment:

Create completely new node group then switch traffic
Easy rollback and low risk
Resource usage temporarily increases (double the nodes running)
Implementation steps:
1. Create new node group (green)
2. Deploy and test workloads on new node group
3. Switch traffic to new node group
4. Delete existing node group (blue)

Configuration example:

bash

# Create new node group
eksctl create nodegroup \
  --cluster my-cluster \
  --name my-nodegroup-v2 \
  --node-type m5.large \
  --nodes 3 \
  --node-ami-family AmazonLinux2

# Check node labels
kubectl get nodes --show-labels

# Delete existing node group
eksctl delete nodegroup \
  --cluster my-cluster \
  --name my-nodegroup-v1

Canary Deployment:

Minimize risk by upgrading only some nodes first
Limits impact scope if problems occur
Gradual rollout possible
Implementation steps:
1. Create small new node group
2. Move some workloads to new node group
3. Monitor and verify
4. Upgrade remaining nodes if no problems

Configuration example:

bash

# Create canary node group (small scale)
eksctl create nodegroup \
  --cluster my-cluster \
  --name canary-ng \
  --node-type m5.large \
  --nodes 1 \
  --node-labels "deployment=canary"

# Deploy specific workloads to canary nodes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      nodeSelector:
        deployment: canary

Problems with in-place upgrades:

The term "in-place upgrade" can mean upgrading existing nodes without terminating them. This is not suitable for EKS node groups for the following reasons:

Violates immutable infrastructure principles:
- Cloud-native environments recommend replacing resources rather than modifying them
- Prevents node configuration drift
Risk of upgrade failure:
- Nodes may become unstable if in-place upgrade fails
- Rollback is difficult
EKS node AMI structure:
- EKS optimized AMIs have different AMI IDs per version
- AMI cannot be changed through in-place upgrade
Managed node group limitations:
- EKS managed node groups do not support in-place upgrades
- Always uses rolling upgrade method

Node group upgrade best practices:

Configure PodDisruptionBudget:

Ensures application availability during upgrades

yaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 2  # or maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

Ensure sufficient resources:
- Need spare capacity for pod relocation during node draining
- Consider Cluster Autoscaler configuration
Test before upgrade:
- Test upgrades in non-production environments first
- Verify application compatibility
Enhanced monitoring:
- Monitor system during and after upgrade
- Early detection of anomalies

EKS node group upgrades are important tasks for applying security patches, bug fixes, and new features while minimizing workload disruption. Choose strategies like rolling upgrade, blue/green deployment, or canary deployment according to your situation to safely perform upgrades.

What does NOT occur during the node bootstrap process in Amazon EKS clusters?
- A) kubelet configuration and startup
- B) Cluster control plane component installation
- C) AWS IAM Authenticator configuration
- D) Registering node with cluster

Show Answer

Answer: B) Cluster control plane component installation

Explanation: During the Amazon EKS node bootstrap process, cluster control plane components are not installed. EKS is a managed service where the control plane (API server, controller manager, scheduler, etc.) is managed by AWS and runs separately from worker nodes. During the node bootstrap process, only configuration to connect the node to the existing EKS cluster is performed.

What actually occurs during EKS node bootstrap:

kubelet configuration and startup:

Create kubelet configuration file (/etc/kubernetes/kubelet/kubelet-config.json)
Configure cluster endpoint, certificates, cluster DNS, etc.
Start kubelet service

Example configuration:

json

{
  "kind": "KubeletConfiguration",
  "apiVersion": "kubelet.config.k8s.io/v1beta1",
  "address": "0.0.0.0",
  "authentication": {
    "anonymous": {
      "enabled": false
    },
    "webhook": {
      "cacheTTL": "2m0s",
      "enabled": true
    },
    "x509": {
      "clientCAFile": "/etc/kubernetes/pki/ca.crt"
    }
  },
  "clusterDomain": "cluster.local",
  "clusterDNS": ["10.100.0.10"],
  "podCIDR": "",
  "maxPods": 58
}

AWS IAM Authenticator configuration:

Configure aws-iam-authenticator for IAM authentication
Create kubeconfig file
Configure node IAM role

Example configuration:

yaml

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://my-cluster.eks.amazonaws.com
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubelet
  name: kubelet
current-context: kubelet
users:
- name: kubelet
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: aws-iam-authenticator
      args:
        - token
        - -i
        - my-cluster
        - --role
        - arn:aws:iam::123456789012:role/EKSNodeRole

Registering node with cluster:
- Create node object
- Set node labels and taints
- Register with cluster API server
- Example log:
```
Node my-node-1 successfully registered with API server
```

CNI plugin configuration:

Configure Amazon VPC CNI plugin
Set up pod networking
Configure IP address allocation

Example configuration:

json

{
  "cniVersion": "0.3.1",
  "name": "aws-vpc",
  "plugins": [
    {
      "name": "aws-vpc",
      "type": "vpc-cni",
      "vethPrefix": "eni",
      "mtu": "9001",
      "ipam": {
        "type": "aws-cni"
      }
    }
  ]
}

kube-proxy setup:

Configure kube-proxy for cluster networking
Set up service IP routing

Example configuration:

yaml

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
bindAddress: 0.0.0.0
clientConnection:
  acceptContentTypes: ""
  burst: 10
  contentType: application/vnd.kubernetes.protobuf
  kubeconfig: /var/lib/kube-proxy/kubeconfig
  qps: 5

Node labels and taints application:
- Set labels based on instance type, availability zone, etc.
- Apply custom labels
- Apply taints if needed
- Example commands:
  bash
```
kubectl label node my-node-1 eks.amazonaws.com/nodegroup=my-nodegroup
kubectl label node my-node-1 topology.kubernetes.io/zone=us-west-2a
```

Bootstrap script:

EKS node bootstrapping is performed through the /etc/eks/bootstrap.sh script. This script can receive the following parameters:

bash

/etc/eks/bootstrap.sh my-cluster \
  --kubelet-extra-args '--node-labels=node.kubernetes.io/role=worker' \
  --b64-cluster-ca <base64-encoded-ca> \
  --apiserver-endpoint <api-server-endpoint> \
  --dns-cluster-ip 10.100.0.10

When using a custom launch template, you can call this script in the user data section to perform additional configuration:

bash

#!/bin/bash
set -ex
/etc/eks/bootstrap.sh my-cluster \
  --kubelet-extra-args '--node-labels=environment=prod,node-type=worker' \
  --max-pods 110

Cluster control plane components:

EKS cluster control plane components are managed by AWS and are separate from the node bootstrap process:

API server
Controller manager
Scheduler
etcd
CoreDNS

These components run on AWS-managed infrastructure and ensure high availability and scalability. Nodes only connect to these control plane components; they do not install or manage them directly.

Therefore, what does NOT occur during Amazon EKS node bootstrap is "cluster control plane component installation."

Traffic Management

Security

Observability

Resilience

Advanced

Comparison Guide

ArgoCD

Metrics

Logging

Tracing

Alerting

Observability End-to-End Labs

Cilium Deep Dive

Calico Deep Dive

Istio Detailed Quiz

Linkerd Detailed Quiz

Cilium Service Mesh Detailed Quiz

ArgoCD Detailed Quiz

Metrics

Logging

Tracing

Alerting

Observability Labs

EKS Cluster Creation Quiz - Part 1 ​

Basic Concept Questions ​

Hands-on Exercises ​

Exercise 1: Create EKS Cluster Using eksctl ​

Exercise 2: Create EKS Cluster Using AWS Management Console ​

Advanced Topics ​

EKS Cluster Creation Quiz - Part 1

Basic Concept Questions

Hands-on Exercises

Exercise 1: Create EKS Cluster Using eksctl

Exercise 2: Create EKS Cluster Using AWS Management Console

Advanced Topics