Forem: Mongkol Thongkraikaew

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

มาลองสร้างระบบ 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