Amazon EKS

এই লেসন শেষে তুমি পারবে

• Kubernetes কী (Google-এর বানানো একটা open-source orchestrator, এখন যার দেখভাল করে CNCF), সেটা বুঝিয়ে বলতে, আর এর মূল শব্দগুলো ব্যবহার করতে: cluster, control plane, node, pod, Deployment, Service, namespace, kubectl, Helm।
• Amazon EKS কী, সেটা বলতে: তিনটা AZ জুড়ে ছড়ানো একটা managed Kubernetes control plane, যার bill হয় cluster-hour ধরে (standard support-এ $০.১০, extended support-এ $০.৬০), আর worker node থাকে তোমার নিজের VPC-তে।
• Worker capacity বেছে নিতে: managed node group, self-managed node, Fargate profile, নাকি EKS Auto Mode, আর Cluster Autoscaler বা Karpenter দিয়ে node scale করতে।
• CSI driver দিয়ে pod-কে টেকসই storage দিতে: EBS (ReadWriteOnce, এক AZ), EFS (ReadWriteMany, Fargate-এ একমাত্র উপায়), ML আর HPC-র জন্য FSx for Lustre, আর বাকিগুলো।
• IRSA বা EKS Pod Identity দিয়ে প্রতিটা pod-কে আলাদা IAM অনুমতি দিতে, আর AWS Load Balancer Controller দিয়ে সামনে একটা ALB বা NLB বসাতে।
• পরীক্ষার keyword দেখে ECS আর EKS-এর মধ্যে বেছে নিতে, আর যেকোনো container workload-এর জন্য App Runner, Fargate-এ ECS, EC2-তে ECS, EKS আর Lambda-র মধ্যে সিদ্ধান্ত নিতে।

#এক পাতায় Kubernetes

Lesson 14.2-এ দেখেছ Amazon ECS, AWS-এর নিজের container orchestrator। Kubernetes (ছোট করে লেখে K8s: K, মাঝে আটটা অক্ষর, শেষে s) একই কাজ করে: শত শত container চালু রাখা, crash করলে বদলে দেওয়া, চাপ বাড়লে আরও চালু করা। তফাত হলো এটা open source। Google নিজের ভেতরে container চালানোর অভিজ্ঞতা থেকে এটা বানায়, ২০১৪ সালে সবার জন্য ছেড়ে দেয়, আর ২০১৫ সালে তুলে দেয় Cloud Native Computing Foundation (CNCF)-এর হাতে, যেটা Linux Foundation-এর অংশ। কোনো একটা cloud এর মালিক না, বড় সব cloud-ই এটা দেয়, আর চাইলে নিজের data center-এও চালাতে পারো। এ কারণেই container-এর দুনিয়ায় এটা industry standard হয়ে গেছে।

Amazon EKS (Elastic Kubernetes Service) হলো AWS-এ managed Kubernetes। ECS-এর বিকল্প: লক্ষ্য একই, API আলাদা। এর সাথে তুমি কথা বলো Kubernetes-এর standard tool দিয়ে, ECS task definition দিয়ে না।

যে শব্দগুলো লাগবে:

Kubernetes declarative: তুমি লিখে দাও “checkout:1.4.2-এর তিনটা replica চাই”, আর controller-রা সারাক্ষণ মিলিয়ে দেখে কী চাওয়া হয়েছে আর কী আছে, যা অমিল তা ঠিক করতে থাকে, চিরকাল। Crash করা container আবার চালু হয়; মরে যাওয়া node-এর pod অন্য কোথাও বসে।

#Amazon EKS: control plane চালায় AWS

নিজে Kubernetes cluster বানালে control plane-ও নিজেকেই চালাতে হয়: কমপক্ষে তিনটা etcd server, load balancer-এর পেছনে API server, certificate, backup, upgrade। Kubernetes-এর সবচেয়ে কঠিন অংশ এটাই। EKS-এ control plane চালায় AWS:

• Region-এর তিনটা Availability Zone জুড়ে কমপক্ষে দুটো API server instance আর তিনটা etcd সদস্য চলে, একটা AWS-managed account-এ। অসুস্থ কোনোটা থাকলে নিজে থেকেই বদলে যায়, আর etcd-র backup ও encryption হয়।
• kubectl-এর জন্য তুমি একটা API endpoint পাও (public, private, বা দুটোই)। তোমার subnet-এ EKS যে ENI বসায়, সেগুলো দিয়ে control plane তোমার node-এ পৌঁছায়।
• Kubernetes version তুমি বেছে নাও আর upgrade শুরু করো; কাজটা করে AWS।
• তোমার worker node আর pod থাকে তোমার নিজের VPC-তে, সাধারণত private subnet-এ।

#Control plane-এর খরচ

প্রতিটা EKS cluster-এর খরচ ঘণ্টায় $০.১০, যতদিন তার Kubernetes version standard support-এ আছে (৭৩০ ঘণ্টার মাসে প্রায় $৭৩)। এর ওপরে আলাদা করে লাগে EC2 instance, Fargate pod, EBS volume আর load balancer-এর দাম। একটা Kubernetes version EKS-এ আসার পর ১৪ মাস standard support পায়, তারপর ১২ মাস extended support, তখন দাম প্রতি cluster ঘণ্টায় $০.৬০ (মাসে প্রায় $৪৩৮)। Extended support নিজে থেকেই চালু থাকে; সেটা শেষ হলে AWS control plane নিজেই upgrade করে দেয়। Managed node group আর self-managed node এর সাথে upgrade হয় না; ওগুলো তোমাকেই করতে হবে।

Cluster-এর সংখ্যা দিয়ে গুণ করে দেখো: তিনটা Region-এ dev, staging আর prod মানে নয়টা cluster, একটা pod চালানোর আগেই মাসে প্রায় $৬৫৭। ছোট team-গুলো ECS পছন্দ করে এর একটা কারণ এটাই, কারণ ECS-এর control plane-এর কোনো দাম নেই।

#VPC-র ভেতরে EKS-এর ছবি

সাধারণ architecture তিনটা AZ জুড়ে থাকে। প্রতিটা AZ-এ একটা public subnet, যেখানে NAT gateway থাকে (আর service public করলে public load balancer-এর node-ও), আর একটা private subnet, যেখানে থাকে worker node। Node-গুলো একটা Auto Scaling group-এর সদস্য, pod চালায় ওরাই। একটা Kubernetes Service চাইলে internet-এর user-দের জন্য public load balancer দিয়ে, বা VPC-র ভেতরের অন্য system-এর জন্য private (internal) load balancer দিয়ে প্রকাশ করা যায়। Node-গুলো NAT gateway বা VPC endpoint দিয়ে ECR আর AWS API-তে পৌঁছায় (lesson 22.2)।

Slide থেকে আরও দুটো নিয়ম:

• একটা EKS cluster থাকে একটাই Region-এ। কয়েকটা Region-এর app হলে প্রতি Region-এ একটা করে EKS cluster বানাও, আর user-দের মাঝে route করো (Route 53, Global Accelerator)।
• Log আর metric জোগাড় করো CloudWatch Container Insights দিয়ে, যেটা প্রতিটা node আর pod-এর metric পড়ে (chapter 19, lesson 19.4)।

#কোম্পানিগুলো কেন EKS নেয়

Note থেকে: যে কোম্পানি কোনো একটা cloud provider-এর ওপর নির্ভরশীল হতে চায় না (vendor lock-in), আর যাদের নিজেদের server-এ আগে থেকেই Kubernetes চলছে, তারা সহজে EKS-এ চলে আসতে পারে, কারণ একই manifest, Helm chart আর tool কাজ করতে থাকে। Kubernetes cloud-agnostic: AWS, Azure, Google Cloud বা অফিসের server, সবখানে একই API।

#Worker node: pod চলে কোথায়

Control plane সবসময় AWS-এর দায়িত্ব। Pod-এর নিচের worker capacity চার রকম (note-এ আছে প্রথম তিনটা):

Note বলছে self-managed node খুব একটা ব্যবহার হয় না। কথাটা ঠিকই: আজকাল এগুলো ব্যতিক্রম, সেই team-গুলোর জন্য যাদের বিশেষ OS, শক্ত করে বাঁধা image আর upgrade-এর ওপর কড়া নিয়ন্ত্রণ দরকার। Managed node group-ও launch template দিয়ে custom AMI নিতে পারে, তাই শুধু “custom AMI” কথাটা শুনেই self-managed node বেছে নিতে হবে, এমন না।

EKS-এ Fargate চলে একটা Fargate profile দিয়ে: একটা নিয়ম, যেমন “checkout namespace-এর pod (এই label-গুলো সহ) চলবে Fargate-এ, এই private subnet-গুলোতে”। যে pod মিলে যায়, সে বসে নিজের একটা micro-VM-এ, যার মাপ ঠিক হয় তার CPU আর memory request থেকে, সাথে ২৫৬ MB kubelet আর তার সঙ্গীদের জন্য, তারপর পরের Fargate মাপে উঠিয়ে। যে pod কোনো profile-এর সাথে মেলে না, আর cluster-এ কোনো EC2 node-ও নেই, সে থেকে যায় Pending। Fargate pod-এ DaemonSet, privileged container, GPU বা EBS volume চলে না, আর এরা চলে শুধু private subnet-এ।

#Node scale করা: Cluster Autoscaler আর Karpenter

Scale হয় দুই স্তরে, ঠিক lesson 14.3-এর ECS service scaling আর capacity provider-এর মতো:

1. Pod: Horizontal Pod Autoscaler CPU, memory বা নিজের বানানো metric দেখে একটা Deployment-এর replica সংখ্যা বদলায় (ECS Service Auto Scaling-এর মতো)। নতুন pod-এর জন্য node-এ জায়গা লাগে।
2. Node: কোনো node-এ জায়গা না থাকায় pod যখন Pending, তখন কাউকে EC2 capacity যোগ করতে হবে। Kubernetes নিজে কখনো machine বানায় না।

নতুন EKS cluster-এ সাধারণত Karpenter-এরই পরামর্শ দেওয়া হয়, আর EKS Auto Mode এটা তোমার হয়ে চালায়। যেটাই নাও, বড় কোনো event-এর আগে সীমাগুলো দেখে নাও: node group যদি তার max size-এ থাকে, বা EC2-এর কোনো service quota ফুরিয়ে যায়, তাহলে autoscaler যত ভালোই হোক, pod Pending-ই থাকবে।

#Data volume: CSI driver

Container থামলে তার file হারিয়ে যায়। যে data টিকে থাকতে হবে, তার জন্য Kubernetes তিনটা object ব্যবহার করে:

• StorageClass: এক রকম storage-এর নাম, যেটা বলে কোন driver এটা বানাবে আর কোন setting দিয়ে (যেমন EBS gp3, encrypted)। Slide মনে করিয়ে দেয়, cluster-এ এটা define করে নিতে হয়।
• PersistentVolumeClaim: একটা pod-এর চাওয়া: “gp3 class-এর ১০০ GiB, access mode ReadWriteOnce”।
• PersistentVolume: claim-এর সাথে জোড়া আসল volume, যেটা driver দরকারের সময় বানায় (dynamic) বা আগে থেকে বানানো থাকে (static)।

Driver-টা হলো একটা CSI (Container Storage Interface) driver, একটা plug-in, যেটা ওই object-গুলোকে AWS API call-এ বদলে দেয়। প্রতিটা storage service-এর জন্য AWS একটা করে driver রাখে:

FSx নিজে পড়েছ lesson 12.2-এ; EBS আর EFS হলো lesson 5.1 আর 5.4। পাশের কথা: EKS-এর তালিকায় Amazon File Cache আর ২০২৬-এর Amazon S3 Files-ও আছে (S3-এর data-কে একটা shared file system হিসেবে দেখানো, EFS CSI driver দিয়ে mount হয়, Fargate-এ না); কোনোটাই এখনো পরীক্ষায় নেই।

যে ফাঁদ পরীক্ষা আর production দুজনেরই প্রিয়: একটা EBS volume একটাই AZ-এর। কোনো StatefulSet pod অন্য AZ-এর একটা node-এ সরে গেলে সে নিজের volume attach করতে পারে না, Pending হয়ে থাকে। StorageClass-এ binding mode WaitForFirstConsumer দাও, যাতে নতুন volume তৈরি হয় pod-এর AZ-এ; যে যে AZ-এ volume আছে, সেখানে node রাখো; আর যে data একটা AZ হারালেও বাঁচাতে হবে, সেটা database-এর স্তরে replicate করো বা EFS-এ রাখো।

EKS-এ Fargate শুধু EFS support করে টেকসই storage হিসেবে (static provisioning: আগে file system আর PersistentVolume বানাও)। Fargate pod-এ EBS volume mount হয় না, FSx for Lustre-ও ওখানে নেই। প্রতিটা Fargate pod default ২০ GiB ephemeral storage পায়, বাড়ানো যায় ১৭৫ GiB পর্যন্ত, pod থামলে মুছে যায়।

#Load balancer আর pod-এর IAM

#AWS Load Balancer Controller

Kubernetes load balancing বোঝায় নিজের object দিয়ে। EKS-এ AWS Load Balancer Controller (একটা add-on, তুমি install করো; Auto Mode-এ ভেতরেই আছে) সেগুলোর ওপর নজর রাখে আর AWS-এর জিনিস বানায়:

• একটা Ingress (host আর path দেখে HTTP routing) → listener, rule আর target group সহ একটা Application Load Balancer।
• LoadBalancer type-এর Service → একটা Network Load Balancer।

Target type ip হলে load balancer সরাসরি প্রতিটা pod-এর VPC IP address-এ traffic পাঠায়; প্রতিটা pod-এর এমন IP থাকে Amazon VPC CNI plugin-এর কারণে, আর Fargate-এর pod-এর জন্য এটাই একমাত্র উপায়। Target type instance হলে traffic যায় প্রতিটা node-এর একটা port-এ, node সেটা pod-এ পৌঁছে দেয়। Controller-এর নিজেরও IAM অনুমতি লাগে; সেটা না থাকলে Ingress কখনো address পায় না। ALB আর NLB নিজেরা পড়েছ lesson 6.3-এ।

#IRSA আর EKS Pod Identity

ECS-এর task role-এর একই নিয়ম (lesson 14.2): application-এর অনুমতি কখনো node-এর IAM role-এ দিও না, কারণ ওই node-এর প্রতিটা pod সেটা ব্যবহার করতে পারে। Node role হলো kubelet-এর জন্য: cluster-এ যোগ দেওয়া, ECR থেকে টানা, network interface জোড়া।

একটা workload-কে নিজস্ব IAM role দেওয়ার দুটো উপায় EKS-এ আছে:

• IRSA (IAM Roles for Service Accounts): cluster-এর একটা OIDC provider IAM-এ নথিভুক্ত থাকে। একটা Kubernetes service account-এ তুমি একটা role ARN লিখে দাও; role-এর trust policy শুধু ওই service account-কেই মানে। Pod একটা signed token পায়, আর AWS SDK সেটা STS-এর কাছে দিয়ে (AssumeRoleWithWebIdentity) অল্প সময়ের credential নেয়। EC2 node আর Fargate, দুটোতেই চলে।
• EKS Pod Identity (২০২৩): আরও সহজ। Role বিশ্বাস করে pods.eks.amazonaws.com service-কে, আর তুমি EKS API দিয়ে একটা association বানাও (cluster, namespace, service account, role)। প্রতিটা node-এর Pod Identity Agent credential বিলি করে। প্রতি cluster-এ OIDC provider লাগে না, আর একটা role trust policy না বদলেই অনেক cluster-এ ব্যবহার করা যায়। এটা চলে শুধু Linux EC2 node-এর pod-এ, Fargate-এ না।

সাথে instance metadata service-ও সীমিত করো (hop limit ১ দিয়ে IMDSv2), যাতে pod node role ধার নিতেই না পারে।

#ECS বনাম EKS

Note-এর উপসংহার (owner-এর অনুমান, chat-এ যেটা “১০০% ঠিক” বলে মেনে নেওয়া হয়েছে): দুটোর লক্ষ্য একই, container orchestration: শত শত container সামলানো, চাপ বাড়লে নতুন container চালু করা, crash করলে আবার চালু করা। কিন্তু সেখানে পৌঁছায় দুটো আলাদা দর্শনে।

Note-এর সারসংক্ষেপ: দুটোই Docker container সামলায়, আর দুটোই Fargate (serverless) বা EC2-তে চলতে পারে। তফাত শুধু engine-এ: একটা AWS-এর নিজের (ECS), অন্যটা open-source দুনিয়ার নেতা (EKS, Kubernetes)।

#AWS App Runner: সবচেয়ে সহজ প্রান্ত

AWS App Runner নেয় source code (একটা repository থেকে) বা একটা container image (ECR থেকে), আর বদলে দেয় একটা চালু HTTPS web service: URL, load balancing, auto scaling, আর প্রতিটা push-এ নতুন deploy। কোনো cluster নেই, task definition নেই, load balancer নেই, VPC নকশা নেই। তুমি শুধু প্রতিটা instance-এর CPU আর memory, আর প্রতি instance-এ কতগুলো request একসাথে চলবে, ঠিক করে দাও; সেটা একটা সর্বনিম্ন আর সর্বোচ্চ instance সংখ্যার মধ্যে scale করে।

২০২৬-এ এর অবস্থা বদলেছে: ৩০ এপ্রিল ২০২৬ থেকে App Runner নতুন customer নেয় না। পুরোনো customer-রা আগের মতোই ব্যবহার করতে পারে, নতুন service বানানো সহ, আর AWS এটাকে নিরাপদ ও চালু রাখবে, কিন্তু নতুন কোনো feature আসবে না। নতুন কাজের জন্য AWS-এর পরামর্শ Amazon ECS Express Mode (নভেম্বর ২০২৫): একটা image আর দুটো IAM role দিয়ে একটা API call করলেই তোমার account-এ তৈরি হয় Fargate-এ একটা ECS service, HTTPS সহ একটা ALB, auto scaling আর networking; ওই resource-গুলোর দামের বাইরে বাড়তি কোনো খরচ নেই।

#Container কোথায় চলবে, বেছে নেওয়া

এটা দিয়েই chapter শেষ। সবচেয়ে সহজ থেকে সবচেয়ে বেশি নিয়ন্ত্রণ পর্যন্ত:

1. এটা কি ছোট, event-ভিত্তিক code, যেটা ১৫ মিনিটের মধ্যে শেষ হয়?

   একটা S3 upload, একটা API call, একটা queue message, একটা schedule: Lambda (lesson 15.1)। নাহলে এটা container; এগোও।

2. প্রশ্নে কি Kubernetes, Helm, open source, vendor lock-in বা multi-cloud আছে?

   EKS। তারপর বেছে নাও managed node group (স্বাভাবিক পছন্দ), Fargate profile (node ছাড়া), নাকি self-managed node (পুরো নিয়ন্ত্রণ)।

3. এটা কি code বা image থেকে web app চালানোর “সবচেয়ে সহজ উপায়”?

   পরীক্ষার প্রশ্নে App Runner; নতুন নকশায় ECS Express Mode।

4. GPU, host-এ root বা privileged access, নাকি Reserved Instance লাগবে?

   EC2-তে ECS (EC2 launch type)। নাহলে Fargate-এ ECS, AWS-এ container-এর স্বাভাবিক পছন্দ।

#কোথায় গোলমাল হয়

#System design-এ EKS

• কারণ থাকলে তবেই EKS, অভ্যাসবশে না: আগে থেকে Kubernetes-এর দক্ষতা আর manifest, Kubernetes ecosystem, বহনযোগ্যতা। এসব না থাকলে Fargate-এ ECS চালাতেও সস্তা, লোক রাখতেও সস্তা।
• কম কিন্তু বড় cluster, namespace দিয়ে ভাগ করা, সাথে RBAC, network policy আর resource quota; prod আর non-prod-এর আলাদা cluster, আর multi-Region app-এ প্রতি Region-এ একটা cluster।
• বেশিরভাগ capacity-র জন্য managed node group বা Auto Mode, node scaling-এর জন্য Karpenter, stateless pod-এর জন্য Spot, ছোট বা হঠাৎ বাড়া-কমা namespace-এর জন্য Fargate profile।
• Replica ছড়িয়ে দাও AZ জুড়ে (topology spread constraint, pod disruption budget), যাতে একটা AZ বা একটা upgrade কখনো সব copy একসাথে না নেয়।
• সম্ভব হলে state pod-এর বাইরে রাখো: managed database (RDS, DynamoDB), S3, ভাগের file-এর জন্য EFS; EBS শুধু AZ-সচেতন নকশা সহ।
• প্রতিটা workload-এ least privilege: EC2 node-এ Pod Identity, Fargate-এ IRSA; node role-এ কিছুই না।
• কয়েক মাস পরপর upgrade করো: একটা version ১৪ মাস সস্তা, তারপর ছয় গুণ দামি।
• নজর রাখো CloudWatch Container Insights বা Prometheus আর Grafana দিয়ে; log পাঠাও Fluent Bit দিয়ে, DaemonSet হিসেবে (Fargate-এ sidecar হিসেবে)।

#নিজে করে দেখো

ap-southeast-1-এ shop-এর checkout service-এর জন্য একটা ছোট cluster, account 111122223333। Output ছোট করে দেখানো। চালু থাকলে টাকা লাগে; শেষে মুছে দিও।

# 1. Managed node group সহ একটা cluster বানাও (eksctl তোমার হয়ে CloudFormation লিখে দেয়)
eksctl create cluster --name shop-example --region ap-southeast-1 --version 1.37 \
  --nodegroup-name general --node-type m6i.large --nodes 2 --nodes-min 2 --nodes-max 6 \
  --node-private-networking --with-oidc
#   [✔]  EKS cluster "shop-example" in "ap-southeast-1" region is ready

aws eks describe-cluster --name shop-example \
  --query 'cluster.{version:version,status:status,endpoint:endpoint,support:upgradePolicy.supportType}'
#   { "version": "1.37", "status": "ACTIVE",
#     "endpoint": "https://A1B2C3D4E5F6.gr7.ap-southeast-1.eks.amazonaws.com", "support": "EXTENDED" }

aws eks update-kubeconfig --name shop-example --region ap-southeast-1
kubectl get nodes -o wide
#   NAME                                            STATUS   VERSION   INTERNAL-IP
#   ip-10-0-101-23.ap-southeast-1.compute.internal  Ready    v1.37.1   10.0.101.23
#   ip-10-0-142-7.ap-southeast-1.compute.internal   Ready    v1.37.1   10.0.142.7

# 2. Checkout API deploy করো: ECR থেকে ২টা replica, ALB দিয়ে প্রকাশ (Load Balancer Controller install করা আছে)
kubectl create deployment checkout \
  --image=111122223333.dkr.ecr.ap-southeast-1.amazonaws.com/checkout-example:1.4.2 --replicas=2
kubectl get pods -o wide
#   NAME                        READY   STATUS    IP            NODE
#   checkout-6d9f7c8b5d-4xk2p   1/1     Running   10.0.101.88   ip-10-0-101-23…
#   checkout-6d9f7c8b5d-q7wz1   1/1     Running   10.0.142.31   ip-10-0-142-7…
kubectl delete pod checkout-6d9f7c8b5d-4xk2p        # কয়েক সেকেন্ডে বদলি pod আসতে দেখো
kubectl get pods -w

# 3. একটা Fargate profile: "reports" namespace-এর সব কিছু চলবে Fargate-এ
eksctl create fargateprofile --cluster shop-example --name reports --namespace reports
kubectl create namespace reports
kubectl -n reports create deployment report-api \
  --image=111122223333.dkr.ecr.ap-southeast-1.amazonaws.com/report-api-example:2.0.0
kubectl -n reports describe pod -l app=report-api | grep CapacityProvisioned
#   CapacityProvisioned: 0.25vCPU 0.5GB

# 4. EKS Pod Identity দিয়ে শুধু payments service account-কে S3-এর অনুমতি
aws eks create-addon --cluster-name shop-example --addon-name eks-pod-identity-agent
aws eks create-pod-identity-association --cluster-name shop-example \
  --namespace payments --service-account payments-sa \
  --role-arn arn:aws:iam::111122223333:role/payments-s3-read-example
#   "association": { "associationId": "a-abcd1234example", "namespace": "payments", … }

# 5. একটা volume: ২০ GiB EBS claim করো (EBS CSI driver add-on install করা থাকতে হবে)
cat <<'EOF' | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata: { name: orders-db-data }
spec:
  accessModes: [ReadWriteOnce]
  storageClassName: gp3
  resources: { requests: { storage: 20Gi } }
EOF
kubectl get pvc
#   NAME             STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS
#   orders-db-data   Pending                                      gp3     # WaitForFirstConsumer: কোনো pod ব্যবহার করলে তবেই bind হবে

# 6. Version-এর জীবনচক্র দেখো, তারপর পরিষ্কার করো (অলস থাকলেও cluster-এর ঘণ্টায় $0.10)
aws eks describe-cluster-versions --cluster-versions 1.37 \
  --query 'clusterVersions[].{v:clusterVersion,endStandard:endOfStandardSupportDate}'
eksctl delete cluster --name shop-example --region ap-southeast-1

Lesson 14.2-এর সাথে তুলনা করো: ওখানে বানানোর মতো কোনো control plane ছিল না, তার জন্য টাকাও লাগেনি, আর task-প্রতি IAM ছিল task definition-এর একটা field মাত্র। পরিশ্রমের এই ফারাকটাই হাতে-কলমে ECS বনাম EKS-এর পুরো সিদ্ধান্ত।

#সারসংক্ষেপ

মূল কথা

• Kubernetes (K8s) হলো Google-এর বানানো open-source container orchestrator, যার দেখভাল করে CNCF। শব্দগুলো: cluster, control plane, node, pod, Deployment, Service, namespace, kubectl, Helm chart।
• Amazon EKS = managed Kubernetes। AWS নিজের account-এ তিনটা AZ জুড়ে control plane চালায়; তোমার worker node আর pod চলে তোমার VPC-তে। Standard support-এ (১৪ মাস) প্রতি cluster-hour $০.১০, extended support-এ (১২ মাস) $০.৬০, তারপর নিজে থেকে upgrade। প্রতি Region-এ একটা cluster; log আর metric-এর জন্য Container Insights।
• Worker capacity: managed node group (EKS ASG বানায় আর node upgrade করে, On-Demand বা Spot), self-managed node (তুমি বানাও, যোগ করো, upgrade করো), Fargate profile (pod-প্রতি একটা micro-VM, DaemonSet নেই, EBS নেই), EKS Auto Mode (node-ও সামলায় AWS)। EKS বলে node group আর Fargate profile, “launch type” না।
• Node scaling: Horizontal Pod Autoscaler pod বাড়ায়; Cluster Autoscaler node group-এর ASG বড় করে; Karpenter সরাসরি ঠিক মাপের instance চালু করে আর consolidate করে।
• StorageClass আর PersistentVolumeClaim সহ CSI driver দিয়ে storage: EBS = ReadWriteOnce, এক AZ; EFS = ReadWriteMany, multi-AZ, Fargate-এ একমাত্র উপায়; FSx for Lustre = ML/HPC; আরও আছে FSx for NetApp ONTAP, FSx for OpenZFS, Mountpoint for S3।
• Pod-প্রতি IAM: IRSA (OIDC, Fargate-এও চলে) বা EKS Pod Identity (সহজতর, শুধু EC2 node); node role-এ কখনো না। AWS Load Balancer Controller: Ingress → ALB, LoadBalancer type-এর Service → NLB, Fargate-এর জন্য target type ip।
• ECS বনাম EKS: লক্ষ্য এক, দর্শন আলাদা (iOS বনাম Android)। ECS = সহজ, AWS-এর সাথে সবচেয়ে গভীর মেলবন্ধন, operational overhead নেই। EKS = vendor lock-in এড়ানো, আগে থেকে চলা Kubernetes, Helm আর open-source tool, multi-cloud। Hybrid দুটোরই আছে (ECS Anywhere; EKS Anywhere আর Hybrid Nodes)।
• App Runner = code বা image থেকে সবচেয়ে সহজ web app (পরীক্ষার উত্তর), ৩০ এপ্রিল ২০২৬ থেকে নতুন customer নেয় না; আজকের সমতুল্য ECS Express Mode। ছোট event-ভিত্তিক code → Lambda; server ছাড়া container → Fargate-এ ECS; GPU, host access, RI → EC2-তে ECS।

নিজেকে যাচাই করো: Amazon EKS আর container service বেছে নেওয়া৩৩টি প্রশ্ন