DEV Community: Mongkol Thongkraikaew

Deploy LLM บน Amazon EKS ด้วย vLLM แบบ Step-by-Step ( EP.1 )

Mongkol Thongkraikaew — Mon, 10 Aug 2026 05:04:50 +0000

By 2028, 95% of new AI deployments will use Kubernetes, up from less than 30% today

Gartner ® , Magic Quadrant™ for Container Management, 6 August 2025.

จากผลคาดการณ์ของ Gartner ระบุว่า ภายในปี 2028 เกือบทุกองค์กรจะนำ Kubernetes มาใช้เป็นโครงสร้างพื้นฐานมาตรฐานในการบริหารจัดการระบบ AI ระดับ Production เพื่อเพิ่มประสิทธิภาพในการสเกลทรัพยากร GPU และยกระดับความปลอดภัยในระดับองค์กร ตัวเลขนี้เน้นย้ำอย่างชัดเจนถึงความจำเป็นในการ Reskill ทักษะสาย IT ไปสู่สายงาน Platform Engineer และ MLOps

ผมจึงตั้งใจเขียนซีรีส์บทความนี้ขึ้นมาเพื่อแบ่งปันความรู้ให้กับทุกคนที่สนใจ โดยมาในธีมหลักอย่าง "Serving LLM บน Kubernetes Platform"

ประเดิมด้วย EP.1 นี้ ผมจะพาทุกคนมาลอง Deploy LLM Model ด้วย vLLM บน Amazon EKS (Kubernetes) ตั้งแต่ขั้นตอนการสร้าง EKS Cluster ไปจนถึงการได้ OpenAI-compatible API และหน้าเว็บ Chat ที่พร้อมใช้งานจริง โดยทุก Command ในบทความนี้สามารถพิมพ์ตามไปพร้อมกันได้เลยครับ

💡 ความตั้งใจของบทความนี้:
ตอนที่ผมพยายาม Deploy LLM บน Kubernetes ครั้งแรก ผมเสียเวลาลองผิดลองถูกไปหลายชั่วโมงเหมือนกันครับ ถือว่าบทความนี้สรุปจากประสบการณ์จริงมาให้แล้ว หวังว่าจะช่วยให้คนที่กำลังเริ่มต้นไม่ต้องมาเจอ Error หรือเสียเวลาแบบที่ผมเคยเจอครับ 😂

มาเริ่มกันเลยครับ...

Architecture Diagram

🛠️ Tech Stacks

Terminal: AWS CloudShell (ใช้สำหรับรัน Command ทั้งหมดในบทความนี้)
Cloud Provider: AWS (Region: us-east-1)
Kubernetes Platform: Amazon EKS (Auto Mode)
Compute Instance: EC2 Instance Type g6.2xlarge
- GPU Spec: NVIDIA L4 Tensor Core (24GB GPU Memory)
- GPU Driver: NVIDIA CUDA
LLM Inference Engine: vLLM
Chat UI Platform: OpenUI
Model Hub: Hugging Face
LLM Model: meta-llama/Llama-3.1-8B-Instruct
- Parameters: 8B
- Inference Quantization: FP16
- VRAM Requirement: ต้องการ VRAM ขั้นต่ำประมาณ 17–18 GB (รวม Weights + Activations/CUDA Graphs + KV Cache) ดังนั้นจึงต้องใช้ GPU ที่มี VRAM 24 GB ขึ้นไป (เช่น NVIDIA L4 หรือ A10G) เพื่อให้มีพื้นที่เหลือสำหรับ KV Cache
- 💡 ข้อแนะนำ: หากมี VRAM ไม่พอ สามารถเปลี่ยนไปใช้โมเดลที่ทำ Quantization เป็น FP8 แทนได้ : RedHatAI/Meta-Llama-3.1-8B-Instruct-FP8

⚡ ทำไมถึงเลือกใช้ vLLM ?

vLLM คือ Open-source Inference Engine ที่กำลังมาแรงมากในปัจจุบัน และกำลังกลายเป็นมาตรฐานหลักสำหรับการ Serve LLM บน Production เหตุผลหลักๆ ที่ผมเลือกใช้ตัวนี้ ได้แก่:

จัดการ GPU Memory ได้มีประสิทธิภาพสูงสุด:
- PagedAttention: เทคโนโลยีจัดการ KV Cache รูปแบบใหม่ที่ได้แรงบันดาลใจมาจาก Virtual Memory ของ OS ช่วยลด Memory Fragmentation
- Continuous Batching: อนุญาตให้ Request ใหม่แทรกเข้า Batch ที่กำลังประมวลผลอยู่ได้ทันทีโดยไม่ต้องรอให้ Batch เดิมทำงานเสร็จ ส่งผลให้ TTFT (Time to First Token) และ Tokens/s ทำได้ดีกว่า Engine ตัวอื่นอย่างชัดเจน
OpenAI-Compatible API: ให้ API ในรูปแบบเดียวกับ OpenAI ช่วยให้สามารถเชื่อมต่อกับ Application หรือ Tools เดิมที่มีอยู่ได้ทันทีโดยไม่ต้องแก้ Code นอกจากนี้ยังมี Native Endpoints อย่าง /health และ /metrics สำหรับทำ Health Checks หรือตั้งค่า Auto-scaling บน Kubernetes ได้ง่าย
High-Concurrency Production Ready: รองรับการใช้งานที่มี Traffic เข้ามาพร้อมกันจำนวนมาก (High Concurrency) ได้ ในขณะที่การ setup ไม่ยุ่งยากซับซ้อนจนเกินไป
Multi-Node & Multi-GPU Serving: รองรับการทำ Tensor Parallelism และ Pipeline Parallelism ทั้งภายใน Node เดียวกัน และขยายข้ามหลาย Node (Multi-Node)
Kubernetes Ecosystem Friendly: ถูกนำไปใช้เป็น Backend หลักใน Framework สาย Cloud-Native อย่าง KServe รวมถึง AWS เองก็มี Deep Learning Containers (DLC) ที่ปรับแต่ง vLLM มาให้พร้อมรันบน EKS ได้ทันที
Open Source & Active Community: ใช้ใบอนุญาตแบบ Apache 2.0 และมี Community ที่เติบโตอย่างต่อเนื่อง

📋 สิ่งที่ต้องเตรียมก่อนเริ่ม

1. AWS Account

Region: ใน Lab นี้ผมจะใช้ Region us-east-1 (N. Virginia) เนื่องจากเป็น Region ที่มี Instance Family ตระกูล g6 ให้ใช้งาน
EC2 Service Quotas (สำคัญมาก):
- โดยปกติ AWS Account ใหม่จะตั้งค่า Quota สำหรับ GPU Instance (G and O instances) ไว้ที่ 0 vCPUs
- ต้องทำการส่ง Request ขอเพิ่ม Service Quotas สำหรับ Running On-Demand G and VT instances ก่อน (แนะนำให้ขออย่างน้อย 8 vCPUs เพื่อรองรับ g6.2xlarge)

Permissions: หากเป็นการทดสอบใน Sandbox/Lab แนะนำให้ตั้งค่า Permission เป็น AdministratorAccess เพื่อป้องกันปัญหาการติด Permission ระหว่าง Deploy

2. Hugging Face Account

Create Access Token:
- เข้าไปที่ Settings > Access Tokens จากนั้นสร้าง Token ใหม่โดยกำหนด Role เป็น Read เพื่อนำมาใช้ดึงโมเดลลงมายัง Cluster ครับ

Request Model Access:
- เนื่องจากในบทความนี้เลือกใช้โมเดล meta-llama/Llama-3.1-8B-Instruct ซึ่งเป็น Gated Model บน Hugging Face จึงต้องทำการกดยอมรับเงื่อนไขสิทธิ์การใช้งานก่อน
- (หมายเหตุ: หากต้องการหลีกเลี่ยงขั้นตอน Gated Model สามารถเลือกใช้โมเดล Open-weight อื่นๆ เช่น Qwen, DeepSeek หรือ Mistral ก็ได้เช่นกันครับ )
- (หรือใช้ลองใช้ ungated mirror NousResearch/Meta-Llama-3.1-8B-Instruct แทนได้ เพราะใช้ weights ชุดเดียวกันกับของ meta)

📌 ขั้นตอนการขอ Request Access Model:

ไปที่หน้า Model Repository meta-llama/Llama-3.1-8B-Instruct
กรอกข้อมูลส่วนตัวและยอมรับเงื่อนไขใบอนุญาต จากนั้นกด Submit เพื่อส่งคำขอ
ตรวจสอบสถานะการอนุมัติได้ที่หน้า Gated Repos Status ในตั้งค่าบัญชีของตัวเอง

และเมื่อเราเตรียมทั้งหมดแล้ว หลังจากนี้เราจะเริ่ม Deploy LLM บน Amazon EKS กันเลยครับ

🚀 Deploy LLM บน Amazon EKS

ก่อนจะเริ่มลงมือ ทำความเข้าใจกันก่อนว่า เป้าหมายของบทความนี้คือความง่ายและรวดเร็ว เพื่อให้ทุกคนได้เห็นผลลัพธ์จริงแบบเร็วที่สุด รวมถึงเข้าใจ component ต่างในระบบ ดังนั้น สคริปต์และขั้นตอนทั้งหมดผมจึงออกแบบมาให้กระชับและทำตามได้ทันทีครับ (ผมคิดว่าน่าจะเป็นแนวทางง่ายที่สุดละ 😂)

นอกจากนี้ ผมจะใช้ AWS CloudShell ในการรันสคริปต์และคำสั่งทั้งหมดตลอดทั้งบทความ ไม่จำเป็นต้องติดตั้ง Terraform, kubectl, หรือ Tools ใดๆ ลงบนเครื่องตัวเองเลยครับ

เริ่มต้นด้วยการให้เราเปิด AWS CloudShell บน AWS Console ขึ้นมาได้เลยครับ (อย่าลืมตรวจสอบ Region มุมขวาบนให้แน่ใจว่าเลือกเป็น us-east-1 ด้วยนะครับ)

ขั้นตอนที่ 1: ตั้งค่า Environment Variables และติดตั้งเครื่องมือ

รันคำสั่งกำหนดค่าตัวแปลบน AWS CloudShell (อย่าลืมเปลี่ยนค่า HF_TOKEN ให้เป็น Hugging Face Token ด้วยนะครับ):

# กำหนด Hugging Face Access Token (เปลี่ยนเป็น Token ของเรา)
export HF_TOKEN="hf_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  

# กำหนด AWS Region และชื่อ EKS Cluster
export Region=us-east-1
export EKSClusterName=llm-eks-lab

ติดตั้ง CLI Tools ที่จำเป็น


# 1. ติดตั้ง envsubst สำหรับจัดการ Template File
sudo yum install gettext -y 

# 2. ติดตั้ง eksctl (CLI สำหรับจัดการ EKS Cluster)
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH

curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"

tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz

sudo install -m 0755 /tmp/eksctl /usr/local/bin && rm /tmp/eksctl

# 3. ติดตั้ง kubectx และ kubens (สำหรับสลับ Context / Namespace)
sudo git clone https://github.com/ahmetb/kubectx /opt/kubectx

sudo ln -s /opt/kubectx/kubectx /usr/local/bin/kubectx
sudo ln -s /opt/kubectx/kubens /usr/local/bin/kubens

# 4. ตรวจสอบความถูกต้องของการติดตั้ง
eksctl version
kubectx -h

เครื่องมือต่างๆ พร้อมแล้ว!

ขั้นตอนที่ 2: สร้าง AWS EKS Cluster

ในขั้นตอนนี้เราจะใช้ eksctl ในการ provisioning ตัว EKS Cluster โดยเปิดใช้งานฟีเจอร์ EKS Auto Mode เพื่อให้ AWS ช่วยดูแลจัดการเรื่อง Infrastructure และ Node Management ให้อัตโนมัติครับ

cat <<EOF | eksctl create cluster -f -
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ${EKSClusterName}
  region: ${Region}
  version: "1.35"
iam:
  withOIDC: true
autoModeConfig:
  enabled: true
  nodePools: ["general-purpose", "system"]
EOF

📌 สรุปคอนฟิกสำคัญในการสร้าง EKS Cluster

EKS Version: 1.35 #(ระบุเวอร์ชัน EKS ที่จะใช้)
Enable Auto Mode: true #(เปิดใช้งาน EKS Auto Mode ให้ AWS บริหารจัดการ Compute/Node ให้อัตโนมัติ)
Node Pools: กำหนด Built-in Node Pools เริ่มต้น 2 กลุ่ม:
- system: สำหรับรัน System Workloads และ Core Kubernetes Components
- general-purpose: สำหรับรัน General Application Workloads ทั่วไป

(รอประมาณ 10-15 นาทีในการสร้าง EKS Cluster ครับ...)

เมื่อรันคำสั่งสร้าง Cluster เสร็จเรียบร้อยแล้ว ให้ทำการตรวจสอบสถานะของ EKS Cluster ดูครับ (หาก Cluster พร้อมใช้งานแล้ว สถานะจะแสดงผลเป็น "ACTIVE"):

aws eks describe-cluster \
  --name $EKSClusterName \
  --region $Region \
  --output json \
  --query 'cluster.status'

# Output: "ACTIVE"

เมื่อ EKS พร้อมใช้งาน ก็มาทดสอบเรียก Kubernetes API ด้วย kubectl ต่อครับ

# Switch context ไปยัง cluster "llm-eks-la"
kubectx $(kubectx | grep "llm-eks-lab")

# ทดสอบ list node
kubectl get node 

# ทดสอบ list Pod
kubectl get pod -A

จุดเด่นของ Amazon EKS Auto Mode คือการรวบรวม Tools สำคัญมาให้ครบถ้วนตั้งแต่แรก ไม่ว่าจะเป็น Karpenter, AWS Load Balancer Controller รวมถึง Nvidia Device Plugin ทำให้พร้อมรองรับ Workload GPU และเริ่มรัน Pod ได้ทันที

ขั้นตอนที่ 3: เตรียม GPU NodePool (Karpenter)

ในขั้นตอนนี้เราจะสร้าง Karpenter NodePool สำหรับจัดเตรียม GPU Nodeเพื่อใช้สำหรับสั่ง Provision เครื่อง g6.2xlarge มารองรับ vLLM ในขั้นตอนถัดไปครับ

รันคำสั่งสั่งสร้าง NodePool ผ่าน kubectl ได้เลย:

cat <<EOF | kubectl apply -f -
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 5m       
  template:
    metadata:
      labels:
        node-type: gpu         
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: default
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["on-demand"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["g6.2xlarge"]   
      taints:
        - key: nvidia.com/gpu
          value: "true"
          effect: NoSchedule
      terminationGracePeriod: 24h0m0s
EOF

# Output: nodepool.karpenter.sh/gpu created

📌 สรุปคอนฟิกสำคัญของ NodePool

node.kubernetes.io/instance-type: g6.2xlarge # ล็อกประเภท EC2 Instance เป็น g6.2xlarge type
taints: nvidia.com/gpu=true:NoSchedule # ใส่ Taint เพื่อป้องกันไม่ให้ Pod ทั่วไป (ที่ไม่ได้ต้องการ GPU) ถูก Schedule มาลงใน Node นี้
metadata.labels:node-type: gpu # ติด Label ประจำ Node เพื่อให้ vLLM Deployment สามารถใช้ nodeSelector ชี้มาถูกเครื่อง
disruption.consolidationPolicy: WhenEmpty # ตั้งค่าให้คืนเครื่องออโต้เมื่อไม่มี Pod ใช้งานเกิน 5 นาที เพื่อช่วยประหยัดค่าใช้จ่าย

ข้อควรระวังสำหรับผู้ที่ใช้ Custom EKS (Non-Auto Mode):

หากใช้ AL2023 AMI จำเป็นต้องติดตั้ง NVIDIA Device Plugin เพิ่มเติมเอง เพื่อให้ Kubernetes Schedule Pod ลงบน GPU Node ได้
หากใช้ AL2 หรือ Custom AMI นอกเหนือจากการติดตั้ง NVIDIA Device Plugin แล้l จะต้องติดตั้ง NVIDIA Driver บน Node เองด้วย เพื่อให้ Container Runtime สามารถเข้าถึง GPU Card ได้
(ข้อดีของ EKS Auto Mode ในบทความนี้คือ ตัว EKS จะจัดการ Driver และ Device Plugin ให้เราอัตโนมัติทั้งหมดครับ!)

💡Q: ทำไม Kubernetes ต้องมี Device Plugin?
A: เพราะโดยปกติแล้ว Kubernetes ไม่รู้จัก GPU ครับ! ตัว kube-scheduler จะรู้จักและคำนวณ resource พื้นฐานแค่ cpu, memory และ ephemeral-storage เท่านั้น ส่วน GPU นั้นถือเป็น Extended Resource ที่ต้องมีคนช่วย "โฆษณา" (Advertise) ให้ Kubernetes รับรู้ ซึ่งทำหน้าที่โดย NVIDIA Device Plugin นั่นเอง โดยตัว Plugin จะไปบอกกับ kubelet บน Node เพื่อประกาศว่าเครื่องนี้มีทรัพยากร [nvidia.com/gpu]: 1 เพิ่มเข้ามา ทำให้ค่านี้ไปปรากฏอยู่ใน node.status.allocatable และทำให้ Kubernetes สามารถ Schedule งานที่ร้องขอ GPU ได้ถูกต้องครับ

📌ตัวอย่างการติดตั้ง NVIDIA Driver และ Device Plugin
(⚠️ หมายเหตุ: สำหรับ Lab ในบทความนี้ ไม่จำเป็นต้องรันคำสั่งด้านล่างนี้ เนื่องจาก EKS Auto Mode จะจัดการส่วนนี้ให้อัตโนมัติทั้งหมดครับ นำมาลงไว้ให้ศึกษาเพิ่มเติมเท่านั้น)

# เพิ่ม Helm Repository ของ NVIDIA
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update

# กรณีที่ใช้ AMI ที่ยังไม่มี driver (ex. Ubuntu EKS AMI)
# ต้องติดตั้งทั้ง GPU Driver, Container Toolkit และ Device Plugin
helm install gpu-operator nvidia/gpu-operator \
  -n gpu-operator --create-namespace \
  --set driver.enabled=true \
  --set toolkit.enabled=true \
  --version v25.3.0

# กรณีที่ใช้ GPU-Accelerated AMI (ex. Amazon Linux 2023 : AL2023) ที่มี Driver ติดตั้งมาแล้ว 
# ติดตั้งเฉพาะ Device Plugin โดยไม่ต้องลง Driver ซ้ำ
helm install gpu-operator nvidia/gpu-operator \
  -n gpu-operator --create-namespace \
  --set driver.enabled=false \
  --set toolkit.enabled=false

ขั้นตอนที่ 4: เริ่ม Deploy vLLM และ LLM Model

1. สร้าง Namespace และ Hugging Face Secret
เริ่มต้นด้วยการสร้าง Namespace local-llm และสร้าง Kubernetes Secret เพื่อเก็บ HF_TOKEN สำหรับใช้ยืนยันตัวตนในการดาวน์โหลดโมเดลจาก Hugging Face:

# สร้าง Namespace สำหรับระบบ LLM
kubectl create namespace local-llm

# สร้าง Secret เก็บ Hugging Face Access Token 
kubectl create secret generic hf-secret -n local-llm \
  --from-literal=HF_TOKEN=${HF_TOKEN}

2. ตรวจสอบสิทธิ์การเข้าถึง Gated Model
ถ้าใครใช้โมเดล meta-llama/Llama-3.1-8B-Instruct เหมือนในบทความนี้ ให้รันคำสั่งด้านล่างเพื่อทดสอบว่า Hugging Face Token ได้รับการอนุมัติสิทธิ์เข้าถึง Gated Repository เรียบร้อยแล้วหรือยัง:

curl -sS -o /dev/null -w 'HF gated repo check: %{http_code}\n' \
  -H "Authorization: Bearer ${HF_TOKEN}" \
  https://huggingface.co/meta-llama/Llama-3.1-8B-Instruct/resolve/main/config.json

# Output ที่ถูกต้อง: HF gated repo check: 200

⚠️ หมายเหตุ: หากผลลัพธ์แสดงเป็น 401 หรือ 403 แสดงว่า Token ไม่ถูกต้อง หรือยังไม่ได้รับการอนุมัติสิทธิ์เข้าถึงโมเดลบน Hugging Face ให้กลับไปเช็กขั้นตอนในส่วน "สิ่งที่ต้องเตรียมก่อนเริ่ม" อีกครั้งครับ

ถัดมา เราจะทำการสร้างทั้ง Deployment และ Service ของ vLLM ไปพร้อมๆ กัน

cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vllm-llama31-8b
  namespace: local-llm
  labels:
    app: vllm-llama31-8b
spec:
  replicas: 1
  selector:
    matchLabels:
      app: vllm-llama31-8b
  template:
    metadata:
      labels:
        app: vllm-llama31-8b
    spec:
      nodeSelector:
        node-type: gpu
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: vllm
          image: vllm/vllm-openai:v0.26.0
          args:
            - --model=meta-llama/Llama-3.1-8B-Instruct
            - --served-model-name=llama31-8b
            - --max-model-len=8192
            - --gpu-memory-utilization=0.90
            - --port=8000
          env:
            - name: HF_TOKEN
              valueFrom:
                secretKeyRef:
                  name: hf-secret
                  key: HF_TOKEN
            - name: HF_HOME
              value: /root/.cache/huggingface
          ports:
            - containerPort: 8000
              name: http
          resources:
            requests:
              cpu: "4"
              memory: 16Gi
              nvidia.com/gpu: "1"
            limits:
              memory: 22Gi
              nvidia.com/gpu: "1"
          volumeMounts:
            # For shared memory (vLLM requirement)
            - name: dshm
              mountPath: /dev/shm
            - name: model-cache
              mountPath: /root/.cache/huggingface
          startupProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 10
            failureThreshold: 120
          readinessProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 8000
            periodSeconds: 30
            failureThreshold: 5
      volumes:
        - name: dshm
          emptyDir:
            medium: Memory
            sizeLimit: 8Gi
        - name: model-cache
          emptyDir:
            sizeLimit: 60Gi
---
apiVersion: v1
kind: Service
metadata:
  name: vllm-llama31-8b
  namespace: local-llm
  labels:
    app: vllm-llama31-8b
spec:
  type: ClusterIP
  selector:
    app: vllm-llama31-8b
  ports:
    - name: http
      port: 8000
      targetPort: 8000

EOF

📌 สรุปรายละเอียดคอนฟิกสำคัญ

Scheduling & Placement:
- nodeSelector.node-type: gpu # ระบุให้ Pod วิ่งไปลงเฉพาะ Node ที่มี Label node-type: gpu
- tolerations: nvidia.com/gpu:NoSchedule operator: Exists # ปลด Taint บน GPU Node เพื่อให้ Pod สามารถ Schedule ลงไปทำงานได้
vLLM Arguments:
- --model: ระบุ Model Repository บน Hugging Face (meta-llama/Llama-3.1-8B-Instruct)
- --served-model-name: กำหนดชื่อโมเดลอ้างอิงผ่าน API (เช่น เวลาเรียกใช้งานผ่าน /v1/models จะเห็นชื่อ llama31-8b)
- --gpu-memory-utilization=0.90: จอง VRAM ไว้ 90% สำหรับ Model Weights และ KV Cache โดยเหลือไว้ 10% ให้กับ CUDA Context และ System Driver
- --max-model-len=8192: (ค่าสำคัญที่สุดใน Lab นี้!) ควบคุมขนาด Context Window รวม (Prompt + Output) ไว้ที่ 8,192 Tokens แม้ว่า Llama 3.1 จะรองรับสูงสุดถึง 131,072 Tokens แต่เนื่องจาก GPU L4 (VRAM 24GB) มีพื้นที่จำกัด หากไม่จำกัดค่านี้ไว้ VRAM จะเต็มและ Container จะระเบิด (OOM) ทันทีครับ 😂 (เรื่องวิธีคำนวณ VRAM เดี๋ยวผมมาแชร์รายละเอียดใน EP ถัดๆ ไปครับ)
Resource Request & Memory Volumes:
- nvidia.com/gpu: "1": Extended Resource สำหรับแจ้ง kube-scheduler ให้ทำการ Reserve GPU 1 ใบให้กับ Pod
- dshm volume (medium: Memory, sizeLimit: 8Gi): ค่านี้ยังไม่มีผลมาก แต่จะมีประโยชน์เมื่อมีการ share ข้อมูลกับ Worker Processes หลายตัวใน node เดียวกัน
- model-cache volume (emptyDir, sizeLimit: 60Gi): จองดิสก์ขนาด 60GB สำหรับ Cache ตัว Model Weights ที่ดาวน์โหลดมาจาก Hugging Face

หลังจากสั่ง Deploy เรียบร้อยแล้ว ให้รันคำสั่งด้านล่างนี้เพื่อติดตามสถานะการรันและดู Log ของ vLLM Pod:

# ตรวจสอบสถานะของ Pod (กด Ctrl+C เพื่อออกจากโหมด watch)
kubectl get pod -l app=vllm-llama31-8b -n local-llm -w 

# ดู Log การทำงานของ vLLM แบบ Real-time
kubectl logs -l app=vllm-llama31-8b -n local-llm -f

เมื่อดู pod status สถานะของ Pod จะค่อยๆ เปลี่ยนตามลำดับดังนี้:
Pending ➔ ContainerCreating ➔ Running (0/1 Ready) ➔ Running (1/1 Ready)

⏱️ สิ่งที่เกิดขึ้นในช่วง Running (0/1 Ready):
เมื่อ Pod เปลี่ยนเป็น Running แต่สถานะ Ready ยังเป็น 0/1 แปลว่า Karpenter ได้ Provision ตัว GPU Node และ Schedule Pod ลงเครื่องเรียบร้อยแล้ว ในช่วงนี้ระบบกำลังทำขั้นตอนสำคัญคือ

ดาวน์โหลด Weights ของโมเดลจาก Hugging Face ลง Storage Cache
โหลด Model Weights ทั้งหมดขึ้นไปยัง GPU VRAM (NVIDIA L4)
เริ่มต้นเปิดบริการ OpenAI-compatible API Server

เมื่อระบบพร้อมใช้งาน Pod จะเปลี่ยนสถานะเป็น Ready 1/1 และใน Log จะแสดงข้อความการตอบรับ Health Check จาก Kubernetes ดังภาพ:

💡 Troubleshooting Tips:

หาก Pod ค้างที่สถานะ Pending นานเกินไป: ให้เช็กว่า nodeSelector / tolerations ถูกต้องหรือไม่ หรือ Karpenter ติด Quota ในการสร้าง GPU Node

หาก Pod มีการ Restart หรือ CrashLoopBackOff: ให้เช็ก Log ของ vLLM ลำดับแรก มักเกิดจาก HF_TOKEN ไม่ถูกต้อง หรือการตั้งค่า vLLM Arguments เช่น --max-model-len สูงเกินกว่า VRAM ที่มี

Route สำคัญที่ควรรู้จัก

/health : readiness/liveness probe
/metrics : Prometheus scrape (มี TTFT, TPOT, queue size, KV cache usage)
/v1/models : ตรวจว่า served_model_name ถูกต้อง
/v1/chat/completions : OpenAI-compatible endpoint หลัก
/v1/messages : Anthropic-compatible endpoint

✨ ตอนนี้เราได้ Local LLM Server ที่พร้อมใช้งานเรียบร้อยแล้วครับ! 👏👏

ขั้นตอนที่ 5 : Provision Chat Interface (Open WebUI)

เพื่อให้ทดสอบและใช้งานโมเดลได้เห็นภาพชัดเจนยิ่งขึ้น ผมจะ Deploy Web Chat Platform อย่าง Open WebUI มาทำหน้าที่เป็น Client สำหรับเรียกใช้งาน OpenAI-compatible API ที่รันอยู่บน vLLM ครับ

เรามาเริ่ม Deploy Open WebUI กันเลย

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: open-webui
  namespace: local-llm
  labels:
    app: open-webui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: open-webui
  template:
    metadata:
      labels:
        app: open-webui
    spec:
      containers:
        - name: open-webui
          image: ghcr.io/open-webui/open-webui:v0.9.2
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 500m
              memory: 500Mi
            limits:
              cpu: "1"
              memory: 1Gi
          env:
            - name: OPENAI_API_BASE_URLS
              value: "http://vllm-llama31-8b:8000/v1"
            - name: OPENAI_API_KEY
              value: "dummy"        # lab only
            - name: WEBUI_AUTH
              value: "False"        # lab only
            - name: ENABLE_OLLAMA_API
              value: "False"
            - name: ENABLE_EVALUATION_ARENA_MODELS
              value: "False"
            - name: RAG_EMBEDDING_ENGINE
              value: ""
          volumeMounts:
            - name: webui-volume
              mountPath: /app/backend/data
      volumes:
        - name: webui-volume
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: open-webui
  namespace: local-llm
  labels:
    app: open-webui
spec:
  type: ClusterIP
  selector:
    app: open-webui
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
EOF

# Output:
# deployment.apps/open-webui created
# service/open-webui created

📌 สรุปรายละเอียดคอนฟิกสำคัญ

OPENAI_API_BASE_URLS: "http://vllm-llama31-8b:8000/v1": ชี้ endpoint ไปยัง vLLM Service ภายใน EKS Cluster
OPENAI_API_KEY: "dummy": เนื่องจากใน vLLM Deployment ของเราไม่ได้ตั้งค่าใส่ API Key ไว้ จึงใส่ค่าอะไรก็ได้เพื่อให้ Open WebUI ส่ง Request ผ่านได้
WEBUI_AUTH: "False": ปิดระบบ Login/Register เพื่อให้เข้าใช้งานหน้าเว็บแชทได้ทันทีโดย authentication (เหมาะสำหรับทดสอบใน Lab เท่านั้น)
ENABLE_OLLAMA_API: "False": ปิดฟีเจอร์การเชื่อมต่อ Ollama เนื่องจากเราใช้ vLLM เป็น Inference Engine หลักเพียงตัวเดียว

จากนั้นลองตรวจสอบสถานะการรันของ Open WebUI Pod ด้วยคำสั่ง:
kubectl get pod -l app=open-webui -n local-llm -w

เมื่อ Pod แสดงสถานะ Ready 1/1 แปลว่าตัว Application ทำงานเรียบร้อยแล้วครับ!

🌐 สร้าง Ingress (AWS ALB) เพื่อเปิดให้เข้าใช้งานจากภายนอก

เนื่องจากตอนนี้ Stack ทั้งหมดของเราทำงานอยู่ภายใน VPC ของ EKS Cluster เราจึงจำเป็นต้องสร้าง Ingress เพื่อสั่งให้ EKS (AWS ALB Controller) ทำการ Provision Application Load Balancer (ALB) แบบ Public ให้อัตโนมัติครับ

รันคำสั่งด้านล่างนี้บน CloudShell เพื่อสร้างทั้ง IngressClassParams, IngressClass และ Ingress:

# 1. สร้าง IngressClassParams และ IngressClass สำหรับ ALB
cat <<EOF | kubectl apply -f -
apiVersion: eks.amazonaws.com/v1        
kind: IngressClassParams
metadata:
  name: alb
spec:
  scheme: internet-facing
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: alb
  annotations:
    ingressclass.kubernetes.io/is-default-class: "true"
spec:
  controller: eks.amazonaws.com/alb     
  parameters:
    apiGroup: eks.amazonaws.com
    kind: IngressClassParams
    name: alb
EOF


# 2. สร้าง Ingress Resource เพื่อ Provision Public ALB
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: open-webui
  namespace: local-llm
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing   
    alb.ingress.kubernetes.io/target-type: ip           
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}]'
    alb.ingress.kubernetes.io/healthcheck-path: /health
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=300
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: open-webui
                port:
                  number: 80
EOF

หลังจากสร้าง Ingress เรียบร้อยแล้ว ให้รอสักครู่ (ประมาณ 1–2 นาที) แล้วรันคำสั่งตรวจสอบสถานะของ Ingress เพื่อเอา Public DNS URL ของ ALB:

kubectl get ingress/open-webui -n local-llm

ในช่อง ADDRESS จะเห็น URL ของ AWS ALB ขึ้นมา (เช่น k8s-localllm-openwebu-xxx.us-east-1.elb.amazonaws.com) ซึ่งเราจะใช้ URL นี้ในการเข้าใช้งาน Chat Platform ผ่าน Web Browser ในขั้นตอนถัดไปครับ

⚠️ คำเตือนเรื่องความปลอดภัย (Security Alert):
ในบทความนี้เราสร้าง Public ALB แบบให้เข้าถึงผ่านอินเทอร์เน็ตได้โดยไม่ได้จำกัด Source IP Address เพื่อความสะดวกในการทดสอบ Lab สำหรับใครนำไปประยุกต์ใช้ในองค์กรหรือ Production ควรกำหนด Security Group หรือใช้ WAF/Inbound CIDR IP Restriction เพิ่มเติม เพื่อความปลอดภัยครับ

ขั้นตอนที่ 6: ทดสอบใช้งานจริงผ่าน Web Browser

คัดลอก ALB URL Address ที่ได้จากขั้นตอนก่อนหน้า นำมาเปิดบน Web Browser ได้เลยครับ

เมื่อหน้าเว็บ Open WebUI โหลดขึ้นมา สังเกตที่ด้านบนของช่องแชทจะเห็นชื่อโมเดล llama31-8b แสดงอยู่อย่างถูกต้อง (ซึ่งเป็นชื่อเดียวกับที่เรากำหนดผ่าน --served-model-name ใน vLLM)

ลองพิมพ์คำถามหรือเริ่มส่ง Prompt ทดสอบได้เลย!

จะเห็นว่าตัวโมเดลตอบกลับได้อย่างรวดเร็วผ่าน vLLM Engine ที่รันอยู่บน GPU L4 บน Amazon EKS ครับ

ขั้นตอนที่ 7 : Cleanup / Uninstall Resource

เมื่อทดสอบเสร็จเรียบร้อยแล้ว อย่าลืมลบ Resource ทั้งหมดที่สร้างขึ้นด้วยนะครับ ไม่งั้น Cost พุ่งแน่นอน

คำสั่งในการ Cleanup Resource ทั้งหมด


# 1. ลบ Deployments ทั้งหมด
kubectl delete deployment/open-webui -n local-llm
kubectl delete deployment/vllm-llama31-8b -n local-llm

# 2. ลบ Services ทั้งหมด
kubectl delete service/open-webui -n local-llm
kubectl delete service/vllm-llama31-8b -n local-llm

# 3. ลบ Ingress (เพื่อสั่งลบ AWS ALB)
kubectl delete ingress/open-webui -n local-llm

# 4. ลบ Kubernetes Secrets 
kubectl delete secret hf-secret -n local-llm

# 5. Karpenter GPU NodePool
kubectl delete nodepool/gpu

# 6. ลบ EKS Cluster ทั้งหมดผ่าน eksctl
eksctl delete cluster llm-eks-lab --region us-east-1

💳 ประมาณการค่าใช้จ่าย (Cost Estimates) สำหรับ Lab นี้:

EKS Cluster Control Plane (Auto Mode): $0.1 / ชั่วโมง
EC2 System Node (1 Instance): $0.1075 / ชั่วโมง
EC2 General-Purpose Node (1 Instance): $0.2150 / ชั่วโมง
EC2 GPU Node g6.2xlarge (1 Instance): $1.0539 / ชั่วโมง
AWS Application Load Balancer: $0.0405 / ชั่วโมง
และมีค่าใช้จ่ายแฝงอื่นๆ อีกเช่น NAT Gateway , EBS

รวมค่าใช้จ่ายทั้งหมดโดยประมาณ: ~$1.6 / ชั่วโมง หรือ $1,600 ต่อเดือน

💡 Tip: ค่าใช้จ่ายส่วนที่มากที่สุดจะตกอยู่กับ GPU Node หากมีแผนการใช้งานอย่างจริงจังบน Production เราสามารถซื้อแผน Reserved Instance หรือ Saving Plan เพื่อลดค่าใช้จ่ายลงได้ 30-35% ครับ

🎯 สรุปท้ายบทความ

เป็นอย่างไรบ้างครับสำหรับ EP.1 Serving LLM บน EKS Platform ด้วย vLLM

เพียงไม่กี่ขั้นตอน เราสามารถสร้างโครงสร้างพื้นฐานระดับ Production บน Amazon EKS ตั้งแต่การใช้ EKS Auto Mode + Karpenter ในการจัดการ GPU Node, การรัน vLLM เป็น Inference Engine ไปจนถึงการเปิด OpenAI-compatible API และต่อหน้าจอ Chat ด้วย Open WebUI ได้สำเร็จ

สำหรับซีรีส์นี้ ใน EP ถัดไปเราจะมาเจาะลึกในหัวข้อเหล่านี้กันต่อครับ:

🛠️ Best Practices: Serving LLM on EKS
💻 LLM on CPU EKS: ทางเลือกราคาประหยัดสำหรับ Small-Scale Model
📊 LLM Observability: ติดตามประสิทธิภาพ TTFT, TPOT และ GPU Metrics
📈 LLM Multi-Node & Dynamic Scale: การทำ Auto-scaling ตามปริมาณ Request
📦 Quantization (FP8/AWQ): บีบอัดโมเดลเพื่อประหยัด VRAM และเพิ่ม Throughput

ฝากกด Like หรือพิมพ์ Comment พูดคุยติชมกันได้เลยนะครับ แล้วพบกันใหม่ใน EP ถัดไปครับ! 👋✨

Building a Multi-Region Failover System with Amazon EKS (Step-By-Step) [Thai language]

Mongkol Thongkraikaew — Wed, 05 Nov 2025 05:03:23 +0000

มาลองสร้างระบบ Failover แบบ Multi-Region กับ Amazon EKS (แบบ Step-by-step)

Mongkol Thongkraikaew ・ Nov 5

#eks #aws #failover #devops

มาลองสร้างระบบ Failover แบบ Multi-Region กับ Amazon EKS (แบบ Step-by-step)

Mongkol Thongkraikaew — Wed, 05 Nov 2025 05:01:33 +0000

มีใครได้ลองคิดหรือเตรียมตัวเผื่อไว้หรือยังหาก Region ที่เราใช้งานอยู่ ล่มไปในช่วงเวลาที่มีผู้ใช้งานระบบเราอยู่จำนวนมาก เราจะทำอย่างไร?

ช่วงนี้หลายคนน่าจะได้เห็นข่าวหรือเจอเหตุการณ์ AWS ในบาง Region เกิดปัญหาจนระบบต่าง ๆ ใช้งานไม่ได้ ซึ่งเป็นอีกหนึ่ง Reminder ว่าระบบที่เราทำงานอยู่จะมองข้ามเรื่อง Availability หรือการเตรียมพร้อมรับมือกับปัญหาลักษณะแบบนี้ไม่ได้เลย

ในบทความนี้ ผมจะพามาลองตั้งค่าระบบ Failover แบบ Multi-Region กับ Amazon EKS แบบ Step-by-step ให้เห็นกันชัด ๆ ว่าทำอย่างไร เหมาะสำหรับเอาไปปรับใช้กับระบบงานที่ทุกคนใช้กันอยู่ได้ เพื่อเพิ่ม resiliency ให้กับระบบของเรามากขึ้น

เครื่องมือที่จำเป็นสำหรับ workshop นี้

AWS Account
Route 53 (Public Hosted Zone)
AWS CloudShell
CLI ที่ต้องใช้: aws, envsubst, eksctl, kubectl, kubectx, kubens

เมื่อพร้อมแล้ว มาลองลงมือสร้างระบบไปพร้อม ๆ กันได้เลยครับ ทุกคนสามารถรันคำสั่งตามขั้นตอนที่ผมโชว์ไว้ได้ทันที

ขั้นตอนที่ 1 : ติดตั้งและตั้งค่า EKS Cluster

1.1 เปิด CloudShell ขึ้นมาก่อน
***ในบทความนี้ ผมจะรันทุกคำสั่งจาก CloudShell ที่ Region: Singapore เท่านั้น เนื่องจากตอนนี้ CloudShell ยังไม่มีให้บริการที่ Region: Thailand

1.2 ตั้งค่าพื้นฐานและติดตั้งเครื่องมือที่ต้องใช้งาน

export ACCOUNT_ID=$(aws sts get-caller-identity --output text --query Account)
export Region1=ap-southeast-7
export Region2=ap-southeast-1
export Region1ClusterName=eks-cluster-th
export Region2ClusterName=eks-cluster-sg
export ALBName=web-alb

# เปลี่ยนตาม domain ของแต่ละคน
export apphostname=web-demo.cloudation101.net
export HostedZoneName=cloudation101.net
export HostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name $HostedZoneName --query 'HostedZones[0].Id' --output text |  cut -d'/' -f3)

# Install envsubst cli 
sudo yum install gettext -y 

# Install eksctl
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo install -m 0755 /tmp/eksctl /usr/local/bin && rm /tmp/eksctl

# Install kubectx, kubens cli
sudo git clone https://github.com/ahmetb/kubectx /opt/kubectx
sudo ln -s /opt/kubectx/kubectx /usr/local/bin/kubectx
sudo ln -s /opt/kubectx/kubens /usr/local/bin/kubens

1.3 สร้าง EKS Cluster ในทั้ง 2 Region
ดำเนินการสร้าง EKS Cluster ใน Region หลักและ Region สำรอง เตรียมพร้อมสำหรับการทำ Multi-Region

# Create EKS cluster auto mode in Region: Thailand
eksctl create cluster --name=$Region1ClusterName --enable-auto-mode --region=$Region1

# Create EKS cluster auto mode in Region: Singapore
eksctl create cluster --name=$Region2ClusterName --enable-auto-mode --region=$Region2

# Validate cluster status (Status: Active)
aws eks describe-cluster \--name $Region1ClusterName \--region $Region1 \--output json \--query 'cluster.status'

aws eks describe-cluster \--name $Region2ClusterName \--region $Region2 \--output json \--query 'cluster.status'

# รอประมาณ 15 นาทีในการสร้างแต่ละ cluster

เมื่อ EKS Cluster สร้างแล้ว เราจะพบว่ามี EKS Cluster ถูกสร้างขึ้นในแต่ละ Region

Region: Thailand

Region: Sigapore

1.4 ทดสอบเชื่อมต่อกับ EKS Cluster ด้วย kubectl

kubectx $(kubectx | grep "eks-cluster-th")
kubectl get node

kubectx $(kubectx | grep "eks-cluster-sg")
kubectl get node

ตัวอย่างผลลัพธ์การทดสอบเรียก EKS API

ขั้นตอนที่ 2 : Deploy Web Application

2.1 สร้าง IngressClass alb

# Config ingressclassconfiguration for Thailand
kubectx $(kubectx | grep "eks-cluster-th")
curl -s https://raw.githubusercontent.com/aws-samples/multi-region-ingress/refs/heads/main/ingressclassconfiguration.yaml | kubectl apply -f -
kubectl get ingressclass,ingressclassparams

# Config ingressclassconfiguration for Singapore
kubectx $(kubectx | grep "eks-cluster-sg")
curl -s https://raw.githubusercontent.com/aws-samples/multi-region-ingress/refs/heads/main/ingressclassconfiguration.yaml | kubectl apply -f -
kubectl get ingressclass,ingressclassparams

2.2 สร้าง ServiceAccount, Clusterrole, Service และ Deploy Web App Demo
Deploy Web App @ Region: Thailand

# Switch EKS cluster
kubectx $(kubectx | grep "eks-cluster-th")

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: webapp-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: webapp-clusterrole
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: webapp-clusterrolebinding
subjects:
  - kind: ServiceAccount
    name: webapp-sa
    namespace: default
roleRef:
  kind: ClusterRole
  name: webapp-clusterrole
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      serviceAccountName: webapp-sa
      containers:
      - image: dumlutimuralp/demoapp
        name: webapp
        env:
        - name: APP_NAME
          value: "WebApp_Demo_TH"
        - name: BG_COLOR
          value: "green" 
        - name: HEALTH
          value: "webapphealth"  
        - name: MY_NODENAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
---
apiVersion: v1
kind: Service
metadata:
  name: webappservice
spec:
  selector:
    app: webapp
  ports:
    - protocol: TCP
      port: 80
EOF

Deploy Web App @ Region: Singapore

# Switch EKS cluster
kubectx $(kubectx | grep "eks-cluster-sg")

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: webapp-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: webapp-clusterrole
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: webapp-clusterrolebinding
subjects:
  - kind: ServiceAccount
    name: webapp-sa
    namespace: default
roleRef:
  kind: ClusterRole
  name: webapp-clusterrole
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      serviceAccountName: webapp-sa
      containers:
      - image: dumlutimuralp/demoapp
        name: webapp
        env:
        - name: APP_NAME
          value: "WebApp_Demo_SG"
        - name: BG_COLOR
          value: "red" 
        - name: HEALTH
          value: "webapphealth"  
        - name: MY_NODENAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
---
apiVersion: v1
kind: Service
metadata:
  name: webappservice
spec:
  selector:
    app: webapp
  ports:
    - protocol: TCP
      port: 80
EOF

2.3 สร้าง Ingress สำหรับ Web App ทั้ง Thailand และ Singapore Region

# Switch EKS cluster to Thailand
kubectx $(kubectx | grep "eks-cluster-th")

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress 
  annotations:
    alb.ingress.kubernetes.io/load-balancer-name: $ALBName
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ingressClassName: alb 
  rules:
  - host: $apphostname
    http:
      paths:
      - path: / 
        pathType: Prefix
        backend:
          service:
            name: webappservice 
            port:
               number: 80 
  - http:
      paths:
      - path: /webapphealth
        pathType: Prefix
        backend:
          service:
            name: webappservice
            port:
               number: 80 
EOF

# Switch EKS cluster to Singapore
kubectx $(kubectx | grep "eks-cluster-sg")

cat <<EOF | envsubst | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress 
  annotations:
    alb.ingress.kubernetes.io/load-balancer-name: $ALBName
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ingressClassName: alb 
  rules:
  - host: $apphostname
    http:
      paths:
      - path: / 
        pathType: Prefix
        backend:
          service:
            name: webappservice 
            port:
               number: 80 
  - http:
      paths:
      - path: /webapphealth
        pathType: Prefix
        backend:
          service:
            name: webappservice
            port:
               number: 80 
EOF

2.4 ตรวจสอบ Resource ที่ถูกสร้างในทั้ง 2 Region ขั้นตอนนี้ เราควรจะเห็น resource อย่างเช่น Deployment และ Ingress ถูกสร้างขึ้นครบถ้วนทั้ง 2 Region

kubectx $(kubectx | grep "eks-cluster-th")
kubectl get all,ingress

kubectx $(kubectx | grep "eks-cluster-sg")
kubectl get all,ingress

ตัวอย่างผลลัพธ์ Kubernetes resource

ทดสอบเข้าถึง website ทั้งสอง region ด้วย ALB domain
Region: Thailand (สีเขียว)

Region: Singapore (สีแดง)

ขั้นตอนที่ 3 : ตั้งค่า Route 53 Health Check และ Record

3.1 ตั้งค่า Health Check เพื่อคอยตรวจสอบสถานะ web application ในทั้ง 2 Region ว่ายังทำงานปกติหรือไม่

# Find ALB Domain
export Region1ALB=$(aws elbv2 describe-load-balancers --region $Region1 --query "LoadBalancers[?contains(LoadBalancerName, '$ALBName')].DNSName | [0]" --output text)
export Region2ALB=$(aws elbv2 describe-load-balancers --region $Region2 --query "LoadBalancers[?contains(LoadBalancerName, '$ALBName')].DNSName | [0]" --output text)

# Create Route 53 health check for Thailand region
aws route53 create-health-check --caller-reference "RegionTH-WebApp-$(date +%s)" \
--health-check-config "{\"Port\":80,\"Type\":\"HTTP\",\"ResourcePath\":\"/webapphealth\",\"FullyQualifiedDomainName\":\"$Region1ALB\",\"RequestInterval\":10,\"FailureThreshold\":2,\"MeasureLatency\":true,\"Inverted\":false,\"Disabled\":false,\"EnableSNI\":false}"

# Create Route 53 health check for Singapore region
aws route53 create-health-check --caller-reference "RegionSG-WebApp-$(date +%s)" \
--health-check-config "{\"Port\":80,\"Type\":\"HTTP\",\"ResourcePath\":\"/webapphealth\",\"FullyQualifiedDomainName\":\"$Region2ALB\",\"RequestInterval\":10,\"FailureThreshold\":2,\"MeasureLatency\":true,\"Inverted\":false,\"Disabled\":false,\"EnableSNI\":false}"

ตัวอย่างผลลัพธ์การสร้าง Route 53 Health Check

3.2 สร้าง Route 53 Alias Record ซึ่งเราจะสร้าง 2 Alias record สำหรับ domain: web-demo.cloudation101.net ไปยัง ALB ของทั้ง 2 region และผมจะทำการ associate แต่ละ record ด้วย healthcheck ที่ถูกสร้างขึ้นก่อนหน้านี้

# Find Health Check ID
export HealthCheckRegion1AppId=$(aws route53 list-health-checks \
  --query "HealthChecks[?HealthCheckConfig.FullyQualifiedDomainName=='$Region1ALB' && HealthCheckConfig.ResourcePath=='/webapphealth'] | [0].Id" \
  --output text)

export HealthCheckRegion2AppId=$(aws route53 list-health-checks \
  --query "HealthChecks[?HealthCheckConfig.FullyQualifiedDomainName=='$Region2ALB' && HealthCheckConfig.ResourcePath=='/webapphealth'] | [0].Id" \
  --output text)

# Find Hosted Zone ID of your domain
export Region1ALBHostedZoneId=$(aws elbv2 describe-load-balancers --region $Region1 --query "LoadBalancers[?DNSName=='$Region1ALB'].CanonicalHostedZoneId" --output text)
export Region2ALBHostedZoneId=$(aws elbv2 describe-load-balancers --region $Region2 --query "LoadBalancers[?DNSName=='$Region2ALB'].CanonicalHostedZoneId" --output text)

# Create the alias record for ALB's Thailand
aws route53 change-resource-record-sets --hosted-zone-id $HostedZoneId \
  --change-batch "{\"Changes\":[{\"Action\":\"CREATE\",\"ResourceRecordSet\":{\"Name\":\"$apphostname\",\"Type\":\"A\",\"SetIdentifier\":\"Region1-Primary\",\"Weight\":100,\"HealthCheckId\":\"$HealthCheckRegion1AppId\",\"AliasTarget\":{\"HostedZoneId\":\"$Region1ALBHostedZoneId\",\"DNSName\":\"$Region1ALB\",\"EvaluateTargetHealth\":false}}}]}"

# Create the alias record for ALB's Singapore
aws route53 change-resource-record-sets --hosted-zone-id $HostedZoneId \
  --change-batch "{\"Changes\":[{\"Action\":\"CREATE\",\"ResourceRecordSet\":{\"Name\":\"$apphostname\",\"Type\":\"A\",\"SetIdentifier\":\"Region2-Secondary\",\"Weight\":0,\"HealthCheckId\":\"$HealthCheckRegion2AppId\",\"AliasTarget\":{\"HostedZoneId\":\"$Region2ALBHostedZoneId\",\"DNSName\":\"$Region2ALB\",\"EvaluateTargetHealth\":false}}}]}"

หมายเหตุ:
ผมเลือกใช้ Routing Policy แบบ Weighted เพื่อกำหนดให้ Route 53 ตอบ ALB IP จาก Region: Thailand เป็นลำดับแรกเสมอ ตราบใดที่ Health Check ของ web app ในทั้ง 2 region ยัง healthty ทุกตัว

ตรวจสอบว่า DNS Record ถูกสร้างใน Hosted Zone ตามที่ต้องการแล้วหรือยัง

aws route53 list-resource-record-sets --hosted-zone-id $HostedZoneId --query "ResourceRecordSets[?Name=='$apphostname.']"

ตัวอย่างผลลัพธ์

หากทำการสร้าง Route 53 record เรียบร้อยแล้ว เราสามารถทดสอบเข้าใช้งาน website ผ่าน URL ที่เรากำหนดได้เลย (ตัวอย่าง http://web-demo.cloudation101.net)

ขั้นตอนที่ 4 : Test application failure

ในขั้นตอนนี้ เราจะจำลองสถานการณ์ที่ web application ใน Region: Thailand มีปัญหา

4.1 Scale down web application ในฝั่ง Thailand region

kubectx $(kubectx | grep "eks-cluster-th")
kubectl scale deployment webapp --replicas=0

หลังจากที่เราทำการ scale down (ลดจำนวน pod) ของ web application ใน Region: Thailand แล้ว จะเห็นได้ว่า Health Check ของ Route 53 สำหรับฝั่งนี้จะเปลี่ยนสถานะเป็น Unhealthy ทันที

เมื่อเราทดสอบเข้าเว็บไซต์ผ่าน URL เดิมอีกครั้ง ระบบ Route 53 จะเปลี่ยนเส้นทางการเข้าถึงไปยัง web application ในฝั่ง Singapore region ให้โดยอัตโนมัติ

หมายเหตุ:
ความเร็วในการเปลี่ยนเส้นทาง (redirect) ผู้ใช้ไปยัง Singapore region จะขึ้นอยู่กับหลายปัจจัย เช่น เงื่อนไขของ Health Check ที่ตั้งไว้, ค่า DNS TTL ของฝั่ง client, รวมถึงการตั้งค่า ALB และค่า HTTP Keepalive ของ ALB ด้วย

ขั้นตอนที่ 5 : Clean up Environment

5.1 Delete Route53 Alias Record

aws route53 change-resource-record-sets --hosted-zone-id $HostedZoneId \
  --change-batch "{\"Changes\":[{\"Action\":\"DELETE\",\"ResourceRecordSet\":{\"Name\":\"$apphostname\",\"Type\":\"A\",\"SetIdentifier\":\"Region1-Primary\",\"Weight\":100,\"HealthCheckId\":\"$HealthCheckRegion1AppId\",\"AliasTarget\":{\"HostedZoneId\":\"$Region1ALBHostedZoneId\",\"DNSName\":\"$Region1ALB\",\"EvaluateTargetHealth\":false}}}]}"

aws route53 change-resource-record-sets --hosted-zone-id $HostedZoneId \
  --change-batch "{\"Changes\":[{\"Action\":\"DELETE\",\"ResourceRecordSet\":{\"Name\":\"$apphostname\",\"Type\":\"A\",\"SetIdentifier\":\"Region2-Secondary\",\"Weight\":0,\"HealthCheckId\":\"$HealthCheckRegion2AppId\",\"AliasTarget\":{\"HostedZoneId\":\"$Region2ALBHostedZoneId\",\"DNSName\":\"$Region2ALB\",\"EvaluateTargetHealth\":false}}}]}"

5.2 Delete Route53 Health Check

aws route53 delete-health-check --health-check-id $HealthCheckRegion1AppId
aws route53 delete-health-check --health-check-id $HealthCheckRegion2AppId

5.3 Delete EKS Cluster

eksctl delete cluster --name=$Region1ClusterName --region=$Region1
eksctl delete cluster --name=$Region2ClusterName --region=$Region2

Lesson learned จาก Workshop

Granular failover effect: หากผูกหลายๆ service กับ ALB ตัวเดียวกัน, Route 53 จะไม่ทำการ failover ไปอีก region ทั้งหมด ถึงแม้ว่าจะมีแค่บาง service unhealthty (เนื่องจากมีการกำหนด Evaluate Target Health : No ใน alias records)
Active-active Routing: หากต้องการให้ระบบทำงานแบบ Active-active failover ให้กำหนด routing policy ให้เหมือนกันในทั้งสอง alias record
Health Check แบบ HTTPS: ถ้าตั้งค่า health check endpoint เป็น HTTPS, Route 53 health checker จะไม่ทำการ validate SSL/TLS Certificate แต่อย่างใด
Monitoring Private IP: Route 53 health checker ไม่รองรับการตรวจสอบ endpoint ที่เป็น private IP หากต้องการ monitor private IP แนะนำให้ใช้งาน CloudWatch alarms หรือ AWS Lambda
ค่าใช้จ่าย Health Check: ควรระมัดระวังการสร้าง AWS Route 53 Health Check ในปริมาณมาก เนื่องจากอาจเกิดค่าใช้จ่ายที่สูงได้

Ref: https://aws.amazon.com/route53/pricing/

What can be improved?

แม้ในบทความนี้จะพูดถึงการทำ Multi-Region Failover สำหรับ workload ที่รันบน EKS เป็นหลัก แต่ในความเป็นจริงเราก็คงไม่ใช้แค่ Kubernetes อย่างเดียวแน่นอน ส่วนใหญ่มักจะมี service อื่น ๆ ที่ต้องเกี่ยวข้องด้วย เช่น RDS, MSK, S3, ไปจนถึง storage อย่าง EBS ด้วย ซึ่งแต่ละ service ก็จะมีเทคนิคหรือ practice ในการเตรียมพร้อมรับมือกรณี Region ล่มที่แตกต่างกันออกไป

Amazon RDS
ถ้าใช้ RDS MySQL, PostgreSQL หรือ Aurora สามารถตั้งค่า “Read Replica” ข้าม Region ได้เลย หรือข้ามไปใช้ Aurora Global Database (ยังไม่รองรับที่ Thailand Region) เลยก็ได้ ขึ้นอยู่ RTO, RPO ที่เราต้องการ

Amazon MSK (Kafka)
สำหรับ MSK ยังไม่มี fully managed multi-region replication เหมือน RDS Aurora ดังนั้นจึงจำเป็นต้องใช้เครื่องมือช่วยอย่าง MSK Replicator หรือ Open source อย่าง MirrorMaker2 ในการ replicate ข้อมูลระหว่าง 2 region

Amazon S3
S3 รองรับการทำ “Cross-Region Replication” (CRR) อยู่แล้ว สามารถตั้ง policy ให้ bucket สำคัญ replicate ข้อมูลข้าม Region ได้อัตโนมัติ

Amazon EBS
EBS ไม่สามารถ attach ข้าม Region ได้โดยตรง วิธีป้องกันที่ดีที่สุดคือ สร้าง snapshot แล้ว replicate snapshot ไปยัง Region ปลายทาง

ส่วน Practices อื่นๆ ผมอยากแนะนำให้ลองอ่าน series Creating a Multi-Region Application with AWS Services series เพื่อเป็นแนวทาง

สรุป

หวังว่าบทความนี้จะช่วยให้ทุกคนเห็นภาพและเข้าใจแนวคิดการออกแบบระบบ Failover แบบ Multi-Region สำหรับ EKS ได้ชัดเจนขึ้นนะครับ ไม่ว่าจะวางแผนสำหรับโปรเจกต์ขนาดใหญ่ หรือเริ่มต้นยกระดับมาตรฐานของระบบที่ดูแลอยู่ แนวทางนี้สามารถนำไปประยุกต์ใช้ได้ในหลากหลายรูปแบบ และผมเชื่อว่าการออกแบบให้ระบบรองรับการ failover ได้ จะช่วยให้เราจัดการกับสถานการณ์ไม่คาดคิดได้ดีขึ้น

สุดท้ายแล้ว การเลือกว่าจะออกแบบระบบ failover ของเราให้ละเอียดหรือทำ Multi-Region สำหรับทุก service หรือไม่ อาจไม่มีสูตรสำเร็จตายตัว สิ่งสำคัญคือต้องประเมินทั้งต้นทุนที่ต้องลงทุนเพิ่มเติม (ไม่ว่าจะเป็นค่า infrastructure หรือค่าใช้จ่ายในการดูแล) เทียบกับเป้าหมาย RTO/RPO ที่องค์กรรับได้ รวมถึงผลกระทบต่อธุรกิจหากเกิดเหตุระบบล่มขึ้นมา ซึ่งบางทีเราอาจต้องเลือกแค่ service ที่ critical จริง ๆ หรือข้อมูลที่สำคัญเท่านั้นให้รองรับ Multi-Region ก็พอ ในขณะที่ service อื่น ๆ ที่ business impact ไม่มากอาจไม่ต้องลงทุนสูงขนาดนั้น และอย่าลืมเรื่องการวางแผน ทดลอง และทดสอบ Disaster Recovery (DR) ข้าม region อย่างสม่ำเสมอ เพื่อให้มั่นใจว่าระบบที่ออกแบบมานั้นสามารถใช้รับมือเหตุการณ์ฉุกเฉินได้จริง ไม่ใช่เพิ่งมาพบปัญหาในวันที่เกิดเหตุแล้ว

ถ้าใครมีคำถามหรืออยากแลกเปลี่ยนประสบการณ์ในการทำ Multi-Region Failover บน EKS สามารถคอมเมนต์พูดคุยกันได้เลยครับ ยินดีแชร์และตอบทุกเคสเหมือนเดิม ขอให้ทุกคนมี Infrastructure ที่พร้อมกับทุกสถานการณ์ครับ

Original Workshop: https://aws.amazon.com/blogs/containers/implementing-granular-failover-in-multi-region-amazon-eks/

12 เครื่องมือ Debug Kubernetes เจ๋งๆ ที่ควรต้องมีติดมือไว้

Mongkol Thongkraikaew — Sun, 30 Mar 2025 17:56:51 +0000

การ Debug Kubernetes อาจเป็นงานยากสำหรับใครหลายๆคน อาจใช้เวลานานในการจะหาสาเหตุของบางปัญหา แต่ถ้าเรามีเครื่องมือดี ๆ อยู่ในมือ มันก็จะช่วยให้เราทำงานกับ Kubernetes ได้ง่ายขึ้น วันนี้ผมจะมาแชร์เครื่องมือที่นิยมที่จะมาช่วยทั้งการแก้ปัญหา, ตรวจสอบประสิทธิภาพ และตรวจจับข้อบกพร่องต่าง ๆ ของ Kubernetes มาลองดูกันครับ

1. kubectl debug
CLI ที่ช่วยให้เราสามารถสร้าง ephemeral container เข้าไปยัง Pod ที่กำลังทำงานอยู่ หรือสร้าง Pod จำลองที่ต้องการโดยเปลี่ยน attribute บางอย่างเช่น entrypoint, image version
ยกตัวอย่างสถานการณ์ที่เราอยากนำเครื่องมือ network troubleshooting เช่น ping, traceroute, nc, tcpdump ไปช่วย investigate ปัญหา network ของ Pod application กับปลายทาง ก็สามารถรันคำสั่ง:

kubectl debug app-Pod -it —image=nicolaka/netshoot

Document

2. kubectl top
CLI สำหรับดูการใช้งาน resource (CPU/Memory) ของแต่ละ Pod หรือแต่ละ Node (ต้องมี Metrics Server ทำงานอยู่บน cluster ที่เราต้องการตรวจสอบด้วย)
ตัวอย่าง:

kubectl top node

kubectl top pod

Document

3. Ktop
Kubectl plugin สำหรับดูการใช้งาน resource เช่นเดียวกับ kubectl top แต่จะสรุปข้อมูล insight บางอย่างเพิ่มเติมและปรับวิธีการแสดงผลให้ดูง่ายขึ้น

ตัวอย่าง:
kubectl ktop --namespace cloudation101

Github

4. Kube-capacity
Kubectl plugin ที่รวมผลลัพท์ระหว่าง kubectl top และ kubectl describe เพื่อให้เราเห็น request, limit รวมถึง utilization ของ resource ต่างๆ บน Kubernetes cluster ผ่านแสดงผลในหน้าเดียว

ตัวอย่าง:
kubectl resource-capacity --util

Github

5. Netshoot
Docker image และ Kubectl plugin สำหรับ troubleshoot ปัญหาที่เกี่ยวกับ container networking เช่น latency, routing, DNS resolving, firewall, ARPs

ยกตัวอย่างสถานการณ์ที่ใช้บ่อยๆ:

การดู latency หรือทดสอบ networking performance ระหว่าง container/host ( iperf )
การ analysis network packet ( tcpdump )
การ scanning port (nmap)
monitor container metric (CPU, memory, network, I/O) แบบ real-time (ctop)

Github

6. Kubetab
Kubectl plugin สำหรับสร้าง proxy ที่ Kubernetes service เพื่อ intercept หรือ tab request ที่จะถูก forward ไปยัง Pod เหมือนเวลาเราใช้ BurpSuite หรือ Zap ในการ tab request ระหว่าง browser และ server
หลักการทำงานคือจะทำการรัน proxy container (เริ่มต้นใช้ MITMProxy)ในรูปแบบของ sidecar และคอย intercept request ก่อนส่งต่อไปยัง application container

ยกตัวอย่างสถานการณ์ที่ใช้บ่อยๆ:

Security testing : capture และ modify HTTP request ก่อนที่จะลองส่งไปยัง Pod
Developer debugging : ใช้สำหรับตรวจสอบดู connection request ที่มีปัญหาในระหว่างการ request ไปยัง service

ตัวอย่าง:
kubectl tap on app-service -p443 --https --browser

Document

7. Kubeshark
CLI สำหรับ capture real-time traffic ทั้ง API Call และข้อมูลที่รับส่งกันใน Kubernetes cluster (เหมือน TCPDump หรือ Wireshark สำหรับ Kubernetes) จุดเด่นคือ มี UI Console ให้กดดูได้อย่างสะดวก

ตัวอย่าง:
kubeshark tap --set headless=true

Github

8. Kubectl-trace
Kubectl plugin ที่ทำให้เราส่ง bpftrace script เข้าไปรันบน node เพื่อ probe ข้อมูลจาก Linux kernel โดยตรงทั้ง Userspace (uprobe) และ kernel space (kprobe) ไม่จำเป็นต้องติดตั้งอะไรเพิ่มเติม โดยจะ run Pod "trace-runner" บน node ที่ต้องการ และรัน bpftrace เพื่อ compile script เป็น eBPF byte-code จากนั้นติดตั้งลงไปใน Linux kernel เพื่อ probe ข้อมูลตามที่เราต้องการ

ยกตัวอย่าง use case:

Trace ปัญหา OOM killed
ดูการทำงานของ CPU Scheduler เพื่อตรวจสอบการ throttle CPU
ตรวจสอบหาการ deadlocks ของ running process
ตรวจสอบหาทำงานของ disk ว่าเกิดจากไฟล์ไหน process ใดที่ช้า

Github

9. Inspektor-gadget
Kubectl plugin สำหรับ probe ข้อมูลต่างๆ Linux kernel ด้วยความสามารถของ eBPF เช่นเดียวกับ “Kubectl-trace” แต่ที่แตกต่างจาก Kubectl-trace คือ Inspektor-gadget จะ pack bpf script ต่างๆมาให้แล้ว ไม่จำเป็นต้องมาเข้าใจ มาเขียน script ทำให้สามารถเรียกใช้งานแบบง่ายๆผ่าน plugin ได้เลย

ตัวอย่าง:

kubectl gadget run trace_exec:latest
kubectl gadget run trace_open:latest -n default -c myapp

Document

10. kubectl tree
Kubectl plugin สำหรับแสดง dependency หรือความสัมพันธ์ระหว่าง resource ต่างๆ เช่น ตรวจสอบว่าภายใต้ deployment มี replicaset และ Pod ใดบ้าง รวมถึงสถานะของแต่ละ Pod ภายใต้ deployment นั้นๆด้วย

ตัวอย่าง:
kubectl tree deployment nginx

Github

11. kubectl spy
CLI สำหรับดูการเปลี่ยนแปลงของ resource ต่างๆบน Kubernetes แบบ real-time

ยกตัวอย่างสถานการณ์ที่ใช้บ่อยๆ:

ตรวจสอบสถานะการ rollout deployment
ตรวจสอบการเปลี่ยนแปลง Pod status
ตรวจสอบการเปลี่ยนแปลง IP Endpoint ของ service

Github

12. K8sGPT
CLI สำหรับสแกนข้อมูลและวิเคราะห์ปัญหาต่างๆบน Kubernetes cluster ร่วมกับ AI Model พร้อมแนะนำวิธีการแก้ไขแต่ละปัญหา โดยเริ่มต้นใช้ “OpenAI” สำหรับการวิเคราะห์ข้อมูล แต่เราสามารถเปลี่ยนเป็น model อื่นๆได้ เช่น ollama , bedrock, Gemini, Azure OpenAI หรือจะเป็น local model ของเราเองก็ได้เช่นกัน

Github

สุดท้ายแล้วเครื่องมือเหล่านี้เป็นแค่ตัวช่วยให้เราจัดการ Kubernetes ได้สะดวกมากขึ้นนะครับ ซึ่งสิ่งสำคัญที่สุดคือเราต้องเข้าใจการทำงานของ Kubernetes ก่อน แล้วเลือกใช้เครื่องมือให้เหมาะกับสถานการณ์ ถึงจะถือว่าเป็นการจัดการ Kubernetes ได้อย่างมีประสิทธิภาพ

จัดการ Kubernetes Resources ด้วย kro (Kube Resource Orchestrator)

Mongkol Thongkraikaew — Sat, 16 Nov 2024 16:48:11 +0000

kro (Kube Resource Orchestrator) เป็น Open source จาก awslabs ที่มาช่วยให้การจัดการ Kubernetes Resources ทำได้สะดวกมากขึ้น

💡อธิบายให้เข้าใจง่ายๆเลยนะครับ :

เมื่อเราจะ Provision หรือรัน Application ใดๆ ใน Kubernetes แน่นอนว่าเราจำเป็นต้องสร้าง Resource ต่างๆ เช่น Deployment, ServiceAccount, Service, Ingress, PV, PVC ใช่ไหมครับ ซึ่ง Resource เหล่านี้อาจจะต้องสร้างซ้ำๆ ในทุก Application ที่รันบนคลัสเตอร์ และสำหรับมือใหม่อาจจะมีความสับสนว่าเราควรสร้าง Resource อะไรก่อนดี ความยุ่งยากนี้แหละครับที่ kro จะเข้ามาช่วยเรา
ResourceGroup (RG) เป็น key ของ kro ครับ จริงๆแล้วมันคือ Custom Resource Definitions (CRDs) สำหรับกำหนดกลุ่มของ Resource ที่เราต้องการ เช่น หากเราต้องการให้ Application ที่จะรันบนคลัสเตอร์มี Deployment, ServiceAccount, Service และ Ingress รูปแบบไหน เราก็สามารถกำหนดลงไปใน RG ได้เลย
หลังจากที่เราสร้าง RG เสร็จแล้ว เราจะได้ API และ Kind API ใหม่ของเราเอง ในตัวอย่างนี้เราจะได้ Kind ที่ชื่อว่า “ApplicationStack”
สำหรับการใช้งานนั้น End User หรือ Developer (Dev Team A, Team B) ก็เพียงแค่เรียกใช้งาน “ApplicationStack” ที่ได้ถูกกำหนดไว้แล้ว โดยไม่จำเป็นต้องรู้รายละเอียดทั้งหมดของ Kubernetes Resources หลังจาก Developer ได้สร้าง ApplicationStack ของตัวเอง, kro ก็จะทำการสร้าง Deployment, ServiceAccount, Service และ Ingress ให้ตามที่ได้กำหนดไว้ใน RG

💡ฟีเจอร์และประโยชน์ของ kro:

ลดความซับซ้อนในการจัดการ Kubernetes Resources
สนับสนุนการทำงานตาม Platform Engineering Practice, ทำให้ทีม Platform สามารถควบคุม standard, compliant, security best practices ได้ง่ายขึ้น
สามารถตรวจสอบสถานะของ Resources ทั้งหมดได้ผ่าน ResourceGroup ได้
รองรับ Resources ที่เป็น Native ของ Kubernetes และ Custom Resource Definitions (CRDs) ที่ติดตั้งอยู่บนคลัสเตอร์
และอื่นๆ

จากการทดสอบที่ผมได้ลองเล่นดู เราสามารถนำ kro ไปต่อยอดได้หลายอย่างครับ เช่น:
Ex.1: ทำให้การทำงานของ Platform Engineering ง่ายขึ้น โดยที่หน้าที่ของทีม Platform คือการกำหนดมาตรฐานของ ResourceGroup ออกมา และให้ผู้ใช้สามารถ Self-Service ในการ Provision สิ่งที่ต้องการได้ด้วยตัวเอง นอกจากนี้ทีม Platform อาจจะเสริมด้วยการ control permission โดยจะอนุญาตให้ user interact กับ ResourceGroup ได้เท่านั้น จะไม่อนุญาตให้ user สร้าง Deployment หรือ Ingress ได้ตรงๆ เป็นต้น
🔗Link

Ex.2: ช่วยในการ Provision Kubernetes Resources พร้อมกับ Cloud Resources ได้ง่ายขึ้น ในตัวอย่างนี้ Pod หรือ Application จำเป็นต้องใช้งาน RDS และต้องนำ IP ของ RDS ไปใช้งานใน Application ด้วย เราสามารถทำสิ่งเหล่านี้ได้เพียงไฟล์ YAML ไฟล์เดียว

🔗Link

Ex.3: ทีม SRE อาจสร้าง ResourceGroup สำหรับ Observability Tools เช่น Logging Stack, Monitoring Stack, และ Tracing Stack หากต้องการสร้าง Stack ใหม่ ก็ไม่จำเป็นต้องประกอบร่าง Kubernetes Resources ใหม่ทั้งหมด

Ps. This project is in active development and not yet intended for production use
Official Doc
GitHub