EKS Common Use Cases

Amazon EKS thích hợp cho nhiều loại workload khác nhau. Dưới đây là các use case phổ biến nhất trong thực tế, kèm theo kiến trúc tham khảo và mẹo triển khai.

---

🏗️ 1. Microservices Architecture

1.1. Vấn đề

Monolithic application ngày càng khó scale và maintain. Các team phụ thuộc nhau, một thay đổi nhỏ có thể ảnh hưởng toàn bộ hệ thống.

1.2. EKS giải quyết như thế nào?

EKS cung cấp nền tảng lý tưởng để chạy microservices:

• Mỗi service deploy thành một Deployment/StatefulSet riêng biệt.
• Scale độc lập từng service bằng HPA (Horizontal Pod Autoscaler) hoặc Karpenter.
• Cách ly tài nguyên bằng Namespace và Resource Quotas.
• Quản lý traffic nội bộ bằng Kubernetes Service và Service Mesh (Istio, AWS App Mesh).

1.3. Best Practices

Namespace per team

Tạo Namespace riêng cho mỗi team. Dùng ResourceQuota để giới hạn tài nguyên và LimitRange để set default requests/limits.

• Dùng AWS Load Balancer Controller để tạo ALB cho external traffic.
• Dùng ExternalDNS để tự động tạo DNS record cho mỗi service.
• Dùng AWS App Mesh hoặc Istio nếu cần observability và traffic control ở tầng service-to-service.

---

🚀 2. CI/CD Pipeline - Continuous Delivery

2.1. Vấn đề

Deploy ứng dụng thủ công dễ lỗi, chậm và không nhất quán giữa các môi trường (dev, staging, production).

2.2. Kiến trúc tham khảo

2.3. Hai luồng phổ biến

Push-based CI/CD (CodePipeline / GitHub Actions):

1. Developer push code lên Git.
2. Pipeline trigger → Build image → Push lên ECR.
3. Pipeline cập nhật manifest (image tag) → kubectl apply lên EKS.

Pull-based GitOps (Argo CD / Flux):

1. Developer push code lên Git.
2. CI build image → Push lên ECR → Cập nhật Git repo chứa K8s manifest.
3. Argo CD tự động phát hiện thay đổi và sync vào EKS cluster.

GitOps là lựa chọn tốt hơn

GitOps (Argo CD, Flux) có audit trail rõ ràng, dễ rollback, và cluster luôn đồng bộ với Git. Xem thêm EKS Capabilities - Argo CD.

2.4. Ví dụ: Kustomize Overlay cho multi-environment

# base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: app
          image: 123456789.dkr.ecr.ap-southeast-1.amazonaws.com/my-app:latest

# overlays/production/kustomization.yaml
resources:
  - ../../base
patches:
  - patch: |-
      - op: replace
        path: /spec/replicas
        value: 5
    target:
      kind: Deployment
      name: my-app

---

⚡ 3. Batch Processing và Data Pipelines

3.1. Vấn đề

Các job xử lý dữ liệu (ETL, ML training, report generation) thường chạy không liên tục, tốn nhiều CPU/RAM, và cần scale nhanh khi có batch lớn.

3.2. EKS giải quyết như thế nào?

• Dùng Kubernetes Job hoặc CronJob để schedule batch task.
• Dùng Karpenter để tự động provision node EC2 khi có batch job, và terminate ngay khi job xong → tiết kiệm chi phí.
• Dùng EC2 Spot Instances cho node group batch để giảm chi phí tới 70-90%.
• Dùng AWS Batch on EKS cho workload batch phức tạp.

3.3. Ví dụ: CronJob chạy ETL hàng ngày

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-etl
  namespace: data-team
spec:
  schedule: "0 2 * * *"   # Chạy lúc 2h sáng mỗi ngày
  jobTemplate:
    spec:
      template:
        spec:
          nodeSelector:
            workload-type: batch    # Chỉ chạy trên node group batch (Spot)
          restartPolicy: OnFailure
          containers:
            - name: etl
              image: 123456789.dkr.ecr.ap-southeast-1.amazonaws.com/etl-job:v1.2
              resources:
                requests:
                  cpu: "2"
                  memory: "4Gi"
              env:
                - name: S3_BUCKET
                  value: "my-data-bucket"

Spot Instance Interruption

Khi dùng Spot, cần handle Spot Interruption Notice (2 phút cảnh báo). Kubernetes sẽ drain node bị thu hồi, đảm bảo Job được reschedule sang node khác.

---

🤖 4. Machine Learning Workloads

4.1. Vấn đề

Training và serving ML model đòi hỏi GPU, tài nguyên lớn, và khả năng scale linh hoạt.

4.2. Kiến trúc tham khảo

4.3. Các thành phần chính

• GPU Node Group: Dùng instance type p3, p4d, hoặc g4dn trong Managed Node Group. Cài NVIDIA Device Plugin để K8s nhận diện GPU.
• Karpenter cho GPU on-demand: Tự động provision node GPU khi có training job, terminate ngay sau khi xong.
• S3 làm Model Registry: Lưu artifacts của model, versioning bằng S3 prefix.
• KubeFlow / MLflow: Orchestrate toàn bộ ML pipeline trên K8s.

# GPU Training Pod
apiVersion: v1
kind: Pod
metadata:
  name: gpu-training-job
spec:
  containers:
    - name: trainer
      image: pytorch/pytorch:2.1.0-cuda11.8-cudnn8-runtime
      resources:
        limits:
          nvidia.com/gpu: 4     # Yêu cầu 4 GPU
          memory: "64Gi"
          cpu: "16"
      command: ["python", "train.py", "--epochs=100"]
  nodeSelector:
    node.kubernetes.io/instance-type: p3.8xlarge

Dùng Spot GPU cho Training

Training job thường có checkpoint. Dùng Spot p3 instance tiết kiệm chi phí đáng kể. Lưu checkpoint định kỳ lên S3 để resume khi bị interruption.

---

🏢 5. Multi-Tenant SaaS Application

5.1. Vấn đề

Ứng dụng SaaS phục vụ nhiều khách hàng (tenant) cần cách ly tài nguyên, quản lý chi phí theo tenant, và đảm bảo một tenant không ảnh hưởng tenant khác.

5.2. Các mô hình cách ly trên EKS

Mô hình	Cách ly	Chi phí	Độ phức tạp
Namespace per Tenant	Trung bình	Thấp	Thấp
Node Group per Tenant	Cao	Trung bình	Trung bình
Cluster per Tenant	Rất cao	Cao	Cao

5.3. Kiến trúc Namespace per Tenant (phổ biến nhất)

5.4. Cấu hình cách ly tài nguyên

# ResourceQuota cho mỗi tenant namespace
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-a
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    pods: "20"
---
# NetworkPolicy: tenant không nói chuyện được với nhau
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-tenant
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: tenant-a

---

📨 6. Event-Driven Architecture

6.1. Vấn đề

Ứng dụng cần phản ứng với sự kiện (message từ SQS, Kafka, SNS) và tự scale theo số lượng message trong queue.

6.2. Giải pháp với KEDA

KEDA (Kubernetes Event-Driven Autoscaling) là add-on cho phép scale Deployment dựa trên metric từ external source như:

• Amazon SQS queue depth
• Apache Kafka consumer lag
• AWS CloudWatch metric
• Prometheus metric
• Và nhiều nguồn khác

6.3. Ví dụ: Scale Worker theo SQS Queue Depth

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: sqs-worker-scaler
  namespace: processing
spec:
  scaleTargetRef:
    name: sqs-worker-deployment
  minReplicaCount: 0      # Scale về 0 khi queue rỗng
  maxReplicaCount: 50
  pollingInterval: 15     # Kiểm tra mỗi 15 giây
  cooldownPeriod: 60
  triggers:
    - type: aws-sqs-queue
      metadata:
        queueURL: https://sqs.ap-southeast-1.amazonaws.com/123456789/my-queue
        queueLength: "10"       # Scale up khi > 10 messages/pod
        awsRegion: ap-southeast-1
      authenticationRef:
        name: keda-aws-credentials

Scale về 0

KEDA cho phép minReplicaCount: 0, nghĩa là khi không có message, sẽ không có Pod nào chạy → tiết kiệm tối đa tài nguyên.

---

💾 7. Stateful Applications (Databases, Caches)

7.1. Vấn đề

Ứng dụng stateful như Redis, Elasticsearch, Kafka cần quản lý storage, identity ổn định và thứ tự khởi động.

7.2. StatefulSet trên EKS

Kubernetes StatefulSet cung cấp:

• Stable hostname: redis-0, redis-1, redis-2 - Pod restart vẫn giữ tên cũ.
• Stable storage: Mỗi Pod có PVC riêng, gắn với EBS volume tương ứng.
• Ordered deployment: Deploy và terminate theo thứ tự (0 → 1 → 2).

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-cluster
spec:
  serviceName: "redis"
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        - name: redis
          image: redis:7-alpine
          ports:
            - containerPort: 6379
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: gp3
        resources:
          requests:
            storage: 20Gi

EBS và Availability Zone

EBS volume bị gắn với 1 AZ. Khi Pod bị schedule lại sang AZ khác, nó sẽ không mount được volume cũ. Hãy dùng Topology Spread Constraints hoặc pod affinity để đảm bảo Pod luôn quay về đúng AZ.

Nếu cần storage multi-AZ, hãy dùng EFS CSI Driver thay thế.

---

📋 8. Tóm tắt - Chọn Pattern Nào?

Use Case	Công cụ chính	Ghi chú
Microservices	Deployment, HPA, ALB Controller	Namespace per service/team
CI/CD	Argo CD, CodePipeline, ECR	GitOps ưu tiên hơn push-based
Batch Processing	CronJob, Karpenter, Spot	Tiết kiệm chi phí tối đa
ML Training & Serving	GPU NodeGroup, Karpenter, Triton	Spot cho training, On-demand cho serving
Multi-Tenant SaaS	Namespace, NetworkPolicy, ResourceQuota	Cluster per tenant nếu cần cách ly tuyệt đối
Event-Driven	KEDA, SQS, Kafka	Scale về 0 khi không có event
Stateful Apps	StatefulSet, EBS CSI, EFS CSI	Chú ý AZ affinity với EBS