EKS

Posted on by wpadmin

Sure! Here’s the EKS Control Plane vs. Data Plane comparison without the icons:

EKS: Control Plane vs. Data Plane

Control Plane (Managed by AWS)

This is the “brain” of your Kubernetes cluster. In EKS:

  • You don’t manage or see the EC2 instances running it.
  • AWS automatically scales, patches, and maintains it.
  • High availability is built in by default (spread across 3 AZs).
  • You pay around $0.10/hour per cluster (as of 2024).

Components AWS Manages:

  • kube-apiserver: Handles API requests.
  • etcd: Stores cluster state (encrypted).
  • kube-scheduler: Assigns pods to nodes.
  • kube-controller-manager: Manages replicas, nodes, endpoints.
  • CloudWatch logs can be enabled for observability.

Data Plane (Managed by You)

This is where your actual workloads (pods and containers) run.

You have three options:

1. Managed Node Groups (EKS-managed EC2)

  • AWS provisions and manages EC2 instances in an Auto Scaling Group.
  • You define instance types, scaling rules, and other settings.
  • AWS helps manage the lifecycle (launch, drain, terminate).
  • You manage OS-level updates and Kubernetes component versions (like kubelet).

2. Self-Managed Nodes (Your EC2)

  • You launch and manage EC2 instances yourself.
  • Full control over AMIs, OS, networking, and patching.
  • You manually join the nodes to the cluster.
  • Requires more operational overhead.

3. Fargate (Serverless)

  • You run Kubernetes pods without provisioning or managing servers.
  • AWS provisions compute resources on-demand per pod.
  • Useful for on-demand or short-lived workloads.
  • You trade control for simplicity; slightly higher cost per workload.

Summary Table

FeatureControl Plane (AWS-managed)Data Plane (You manage)
ResponsibilityAWSYou (fully or partially)
ComponentsAPI server, etcd, schedulersEC2 worker nodes or Fargate
VisibilityNo accessFull access to worker nodes (except Fargate)
High AvailabilityBuilt-in (multi-AZ)You configure
UpdatesAWS handlesYou manage or automate
Billing$0.10/hr per clusterBased on EC2 or Fargate usage

Absolutely — here’s a clean breakdown of EKS configuration modes without any icons or emojis:

EKS Configuration Modes

1. Cluster Configuration Modes

These define how you provision and manage the infrastructure for the Kubernetes cluster.

  • Managed Node Groups: EKS provisions and manages the EC2 instances. Easier to use, supports auto-scaling, and integrates with updates.
  • Self-Managed Nodes: You manage EC2 instances yourself. Offers more customization, but with more operational overhead.
  • Fargate: Serverless compute for running pods. No need to manage EC2 instances. Ideal for lightweight or burst workloads.

2. Authentication and Authorization

  • IAM Authentication: Uses AWS IAM to authenticate users and services to the Kubernetes API.
  • RBAC (Role-Based Access Control): Native Kubernetes authorization system used for fine-grained access control.
  • aws-auth ConfigMap: Maps IAM users/roles to Kubernetes RBAC.
  • IAM Roles for Service Accounts (IRSA): Associates IAM roles with Kubernetes service accounts to provide fine-grained permissions to pods.

3. Networking Modes

  • VPC CNI Plugin: Each pod gets an IP address from the VPC, allowing seamless communication across AWS services.
  • Custom Networking: Allows assignment of pods to specific subnets and security groups, improving isolation or multi-tenancy.
  • Network Policies: Kubernetes-native way to control traffic flow between pods. Requires a compatible CNI plugin such as Calico.

4. Deployment Configuration

  • kubectl: Direct command-line tool to deploy and manage workloads.
  • Helm: Package manager for Kubernetes, used for templated deployments.
  • GitOps Tools: Tools like ArgoCD or Flux for managing Kubernetes manifests through version control.
  • Infrastructure-as-Code: Tools like eksctl, Terraform, or AWS CloudFormation for declarative cluster and resource management.

5. Storage Modes

  • Amazon EBS: Block storage for stateful workloads; persistent volumes attached to pods.
  • Amazon EFS: Shared file storage for multiple pods or across Availability Zones.
  • Amazon FSx: High-performance or Windows file systems for specific workloads.

6. Control Plane Configuration

Even though AWS manages the control plane, you can configure:

  • Endpoint Access: Public, private, or both, with CIDR-based access control.
  • Logging: Enable logging for API, audit, scheduler, etc., to CloudWatch.
  • Kubernetes Version: Select version during creation and upgrade when needed.
  • Add-ons: Managed Kubernetes components like CoreDNS, kube-proxy, and VPC CNI can be updated and managed via the EKS console or CLI.

Would you like an architecture example that mixes these modes? For example, using Fargate for some workloads and managed nodes for others?

Sure — here’s the overview of EKS Storage Classes without any examples:

EKS Storage Classes Overview

1. Amazon EBS (Elastic Block Store)

  • Used for block-level storage, ideal for stateful applications like databases.
  • Provisioner: ebs.csi.aws.com (EBS CSI driver).
  • Volume types supported include gp2, gp3, io1, sc1, and st1.
  • Access mode: ReadWriteOnce (volume can be mounted to one node at a time).
  • Recommended for per-pod storage, with performance and capacity options.

2. Amazon EFS (Elastic File System)

  • Provides shared file storage that can be mounted by multiple pods across nodes and Availability Zones.
  • Provisioner: efs.csi.aws.com.
  • Supports ReadWriteMany access mode.
  • Good for workloads that require shared storage, such as content management systems, CI/CD systems, and shared caches.

3. Amazon FSx (for Lustre or Windows File Server)

  • Offers high-performance or Windows-native file systems.
  • Provisioner: fsx.csi.aws.com.
  • Used for HPC, data analytics, machine learning, or Windows-based workloads.
  • Supports ReadWriteMany.

4. Default StorageClass

  • You can define a default StorageClass for your cluster.
  • Only one StorageClass should be marked as default.
  • It is used when a PVC does not explicitly request a specific StorageClass.

Summary Table

Storage TypeProvisionerAccess ModesUse Case
EBSebs.csi.aws.comReadWriteOnceDatabases, stateful apps
EFSefs.csi.aws.comReadWriteManyShared volumes, content systems
FSx Lustrefsx.csi.aws.comReadWriteManyHPC, machine learning, analytics
FSx Windowsfsx.csi.aws.comReadWriteManyWindows applications

Let me know if you want a breakdown of performance or pricing differences across these storage options.