EKS and Kubernetes Overview

Amazon EKS ช่วยรัน Kubernetes control plane บน AWS แต่ทีมยังต้องเข้าใจ cluster operations, node capacity, networking, identity และ workload manifests

EKS components

• EKS Cluster: managed Kubernetes control plane
• Managed Node Group: EC2 worker nodes ที่ AWS ช่วยจัดการ lifecycle
• kubectl: CLI สำหรับคุยกับ Kubernetes API
• Deployment: จัดการ replica และ rollout ของ Pods
• Service: stable endpoint สำหรับ Pods
• Ingress: HTTP routing เข้าสู่ cluster มักใช้ร่วมกับ AWS Load Balancer Controller

Workload example

apiVersion: apps/v1
kind: Deployment
metadata:
  name: learning-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: learning-api
  template:
    metadata:
      labels:
        app: learning-api
    spec:
      containers:
        - name: app
          image: ACCOUNT_ID.dkr.ecr.ap-southeast-1.amazonaws.com/learning-api:1.0.0
          ports:
            - containerPort: 3000

Identity, secrets และ access

EKS Pod Identity ช่วยให้ Pods รับ IAM permissions โดยไม่ใช้ long-term credentials สำหรับ secrets มักใช้ External Secrets Operator เพื่อ sync จาก Secrets Manager หรือ Parameter Store เข้าสู่ Kubernetes Secret ส่วน EKS Access Entry และ Kubernetes RBAC ใช้กำหนดว่าใครเข้าถึง cluster และ namespace ได้ระดับใด

ECS vs EKS

หัวข้อ	ECS	EKS
Complexity	เรียบง่ายกว่า เหมาะกับ AWS-native container apps	ยืดหยุ่นกว่า แต่ต้องเข้าใจ Kubernetes ecosystem
Portability	ผูกกับ ECS concepts	ใช้ Kubernetes API ที่พบได้หลาย platform
Operations	น้อยกว่าเมื่อใช้ Fargate	ต้องดูแล add-ons, RBAC, node groups, upgrades

Common mistakes

• เริ่มใช้ EKS ทั้งที่ทีมยังไม่มี Kubernetes operations skill
• ให้ cluster-admin กว้างเกินไปแทนออกแบบ RBAC ตาม namespace/team
• ลืม resource requests/limits ทำให้ scheduling และ capacity planning ยาก

Review questions

1. Deployment, Service และ Ingress ทำหน้าที่ต่างกันอย่างไร?
2. EKS Pod Identity ช่วยแก้ปัญหาอะไร?
3. เมื่อไร ECS อาจเหมาะกว่า EKS?