คอนเทนเนอร์· ~16 นาที
Amazon EKS — K8s แบบ managed บน AWS
ปิดหลักสูตรด้วยการเชื่อม K8s เข้ากับโลก AWS
EKS เหมือนเช่าคลัสเตอร์ K8s แบบมีทีมช่างดูแล control plane ให้ — AWS จัดการ API server/etcd (ส่วนที่ยากและต้อง HA) ให้ ส่วนเราโฟกัสที่ worker node และแอปของเรา
Amazon EKS (Elastic Kubernetes Service) คือ K8s ที่ AWS ดูแล control plane ให้ (patch, HA, scaling ของ control plane) · เรายังคงใช้ kubectl และ manifest เดิมทุกอย่าง — สิ่งที่เรียนมาทั้งหลักสูตรใช้ได้หมด
AWS ดูแล control plane · เราดูแล worker + แอป
AWS จัดการให้ (managed)
API server
etcd
Scheduler/Controllers
บัญชี AWS ของเรา
EC2 / Fargateworker nodes
ELB/ALBจาก Service/Ingress
EBS/EFSจาก PVC
IAM (IRSA)สิทธิ์ของ Pod
kubectl และ manifest เดิมใช้ได้หมด — K8s วางบนโครงสร้าง AWS ที่เรียนมา
EKS เชื่อม K8s กับบริการ AWS ยังไง
- Worker nodes — เป็น EC2 (จัดการเองหรือ managed node group) หรือ Fargate (serverless ไม่ต้องดูแล node)
- Service type LoadBalancer → สร้าง AWS ELB/NLB จริงให้ (ผ่าน AWS Load Balancer Controller → ALB สำหรับ Ingress)
- PVC + StorageClass → ผูกกับ EBS/EFS จริง (ทบทวนจาก M4)
- IRSA (IAM Roles for Service Accounts) — ผูก ServiceAccount ของ Pod กับ IAM role เพื่อเรียกบริการ AWS (S3, DynamoDB) อย่างปลอดภัย
- Cluster Autoscaler / Karpenter — เพิ่ม/ลด EC2 node ตามจำนวน Pod ที่ Pending
สรุป Key Takeaways
- EKS = managed K8s ที่ AWS ดูแล control plane ให้ · ใช้ kubectl/manifest เดิมทั้งหมด
- เชื่อม K8s เข้ากับ AWS: node เป็น EC2/Fargate, Service→ELB, PVC→EBS/EFS, IRSA→IAM
- EKS(K8s มาตรฐาน) vs ECS(ของ AWS ง่ายกว่า) · Fargate = serverless compute
- ก้าวต่อไป: สร้าง EKS จริง + GitOps + สอบ CKA
อ่านจบแล้วอย่าลืมทำเครื่องหมาย