Kubernetes HPA VPA Cost Optimization ลดค่าใช้จ่าย — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

ในยุคที่การประมวลผลแบบคลาวด์กลายเป็นกระดูกสันหลังของธุรกิจดิจิทัล ค่าใช้จ่ายสำหรับทรัพยากรเหล่านี้ก็พุ่งสูงขึ้นเป็นเงาตามตัว การจัดการคอนเทนเนอร์ด้วย Kubernetes นั้นยอดเยี่ยมในด้านความยืดหยุ่น แต่ก็อาจนำไปสู่การจัดสรรทรัพยากรที่ไม่มีประสิทธิภาพ (Over-provisioning) หรือแม้แต่ทรัพยากรไม่พอ (Under-provisioning) ซึ่งส่งผลต่อทั้งประสิทธิภาพและค่าใช้จ่ายโดยตรง เครื่องมืออัตโนมัติอย่าง Horizontal Pod Autoscaler (HPA) และ Vertical Pod Autoscaler (VPA) คืออาวุธลับที่ DevOps Engineer และทีมคลาวด์ต้องรู้จักใช้ให้เป็น เพื่อสร้างสมดุลระหว่าง Performance, Availability และที่สำคัญที่สุดคือ Cost

คู่มือฉบับสมบูรณ์สำหรับปี 2026 นี้จะพาคุณเจาะลึกกลไกของ HPA และ VPA กลยุทธ์การใช้งานร่วมกัน เทคนิคขั้นสูงสำหรับการปรับแต่ง และกรณีศึกษาจริงจากระบบ Production เพื่อให้คุณลดค่าใช้จ่ายคลาวด์ลงได้อย่างมีนัยสำคัญ โดยไม่กระทบต่อความเสถียรของระบบ

ทำความเข้าใจพื้นฐาน: HPA และ VPA คืออะไร และสำคัญต่อ Cost Optimization อย่างไร?

ก่อนจะลงลึกถึงการปรับแต่ง เราต้องทำความเข้าใจบทบาทและกลไกของเครื่องมือทั้งสองอย่างชัดเจน การจัดสรรทรัพยากรใน Kubernetes นั้นมีสองแนวทางหลัก: “แนวนอน” (เพิ่ม/ลดจำนวน Instance) และ “แนวตั้ง” (เพิ่ม/ลดขนาดของ Instance เดียว) ซึ่งสอดคล้องกับ HPA และ VPA โดยตรง

Horizontal Pod Autoscaler (HPA): การขยายตัวในแนวนอน

HPA ทำงานโดยการเพิ่มหรือลดจำนวน Pod Replica ของ Deployment, StatefulSet หรือวัตถุอื่นๆ ตามเมตริกที่กำหนด (เช่น CPU Utilization, Memory Utilization, หรือเมตริกที่กำหนดเอง) หลักการคือการกระจายโหลดไปยัง Pod จำนวนมากขึ้นเมื่อระบบรับภาระหนัก และลดจำนวน Pod ลงเมื่อโหลดน้อย เพื่อประหยัดทรัพยากร

• กลไก: HPA จะสอบถาม Metrics Server (หรือ Custom Metrics API) เป็นระยะๆ เพื่อดูค่าปัจจุบัน จากนั้นคำนวณตามสูตร: desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
• เหมาะกับ: Workload แบบ Stateless, Microservices, API Endpoints, Web Servers ที่สามารถกระจายโหลดได้ง่าย
• ผลต่อค่าใช้จ่าย: ช่วยลดค่าใช้จ่ายในช่วง Off-peak โดยลดจำนวน Pod ลงได้อย่างรวดเร็ว แต่ต้องคำนึงถึงค่าใช้จ่ายจากการรัน Pod หลายตัวในเวลา Peak ด้วย

Vertical Pod Autoscaler (VPA): การขยายตัวในแนวตั้ง

VPA ทำงานโดยการปรับคำขอทรัพยากร (Requests) และขีดจำกัด (Limits) ของ CPU และ Memory สำหรับ Pod โดยอัตโนมัติ โดยอิงจากประวัติการใช้งาน VPA จะ “แนะนำ” หรือ “บังคับใช้” (ในโหมด Auto/Recreate) ขนาดทรัพยากรที่เหมาะสมที่สุดสำหรับ Pod นั้นๆ

• กลไก: VPA Recommender จะวิเคราะห์ประวัติการใช้ทรัพยากรของ Pod และคำนวณค่า Requests/Limits ที่เหมาะสม จากนั้น Updater จะสั่ง restart Pod (หากอยู่ในโหมด Auto) เพื่อใช้ค่าใหม่
• เหมาะกับ: Workload แบบ Stateful, Database (ที่ต้องใช้การปรับแต่งอย่างระมัดระวัง), Batch Jobs, หรือแอปพลิเคชันที่ขยายแบบ Horizontal ได้ยาก
• ผลต่อค่าใช้จ่าย: ช่วยลดการ Over-provisioning อย่างมหาศาล (เช่น Pod ที่ขอ CPU 2 cores แต่ใช้เฉลี่ยเพียง 0.3 cores) และป้องกันการ Under-provisioning ที่ทำให้แอปพลิเคชันล้มเหลว (OOMKilled)

การติดตั้งและกำหนดค่าเริ่มต้นสำหรับ HPA และ VPA

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

ขั้นตอนที่ 1: ติดตั้ง Metrics Server

HPA จำเป็นต้องมี Metrics Server เพื่อดึงข้อมูลการใช้ CPU/Memory ระดับ Pod

# ติดตั้ง Metrics Server ด้วย Helm (วิธีแนะนำ)
helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm upgrade --install metrics-server metrics-server/metrics-server --namespace kube-system

# หรือติดตั้งด้วย Manifest โดยตรง
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# ตรวจสอบการทำงาน
kubectl get apiservice v1beta1.metrics.k8s.io -o json | jq '.status'

ขั้นตอนที่ 2: สร้าง HPA พื้นฐาน (CPU-Based)

ตัวอย่างการสร้าง HPA ที่ scale ตามการใช้ CPU โดยมีเป้าหมายที่ 70% utilization

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior: # เพิ่มใน Kubernetes 1.18+ สำหรับควบคุมพฤติกรรมการ scale
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

ขั้นตอนที่ 3: ติดตั้งและกำหนดค่า VPA

การติดตั้ง VPA มีความซับซ้อนเล็กน้อย เนื่องจากประกอบด้วยหลาย components (Recommender, Updater, Admission Controller)

# โคลนรีโพซิทอรี VPA
git clone https://github.com/kubernetes/autoscaler.git
cd autoscaler/vertical-pod-autoscaler/

# ติดตั้ง VPA components ด้วยスクリプต์ที่ให้มา
./hack/vpa-up.sh

# หรือติดตั้งด้วย Helm
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install vpa fairwinds-stable/vpa --namespace vpa-system --create-namespace

# สร้าง VPA object สำหรับ Deployment ตัวอย่าง
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-app
  updatePolicy:
    updateMode: "Auto" # โหมด: "Off", "Initial", "Auto", "Recreate"
  resourcePolicy:
    containerPolicies:
    - containerName: "*"
      minAllowed:
        cpu: "100m"
        memory: "50Mi"
      maxAllowed:
        cpu: "2"
        memory: "2Gi"
      controlledResources: ["cpu", "memory"]

กลยุทธ์ขั้นสูง: การใช้ HPA และ VPA ร่วมกันเพื่อประสิทธิภาพสูงสุด

พลังที่แท้จริงของการลดค่าใช้จ่ายอยู่ที่การทำให้ HPA และ VPA ทำงานร่วมกันอย่างประสานเสียง (Orchestration) อย่างไรก็ตาม การใช้ทั้งคู่พร้อมกันสำหรับ Pod เดียวกันต้องใช้ความระมัดระวังเป็นพิเศษ เนื่องจากอาจเกิดการแก่งแย่งทรัพยากร (Fight) ได้

แนวทาง Hybrid: VPA สำหรับ Requests, HPA สำหรับการ Scale

กลยุทธ์ที่ปลอดภัยและได้ผลดีที่สุดคือการให้ VPA ดูแลการตั้งค่า `requests` ให้เหมาะสมเสมอ (เพื่อการจัดสรร Node Resource ที่มีประสิทธิภาพ) ในขณะที่ให้ HPA ดูแลการเพิ่มลดจำนวน Pod ตามโหลดจริง

• ขั้นตอน:
  1. กำหนดค่า VPA ในโหมด `Initial` หรือ `Off` (เพื่อให้แค่ให้คำแนะนำ) สำหรับการตั้งค่า `requests` ที่เหมาะสม
  2. ใช้คำแนะนำจาก VPA ไปตั้งค่า `requests` และ `limits` ใน Deployment manifest ของคุณด้วยมือ หรือผ่าน CI/CD pipeline
  3. จากนั้นจึงสร้าง HPA ที่ใช้เมตริก (เช่น CPU, Memory, หรือ Custom Metrics) โดยอิงจาก `requests` ที่ปรับค่าเหมาะสมแล้วนี้
  4. ผลลัพธ์: HPA จะคำนวณการ scale ได้แม่นยำขึ้น เพราะ `requests` สะท้อนความต้องการจริงของ Pod

การใช้ Custom Metrics และ External Metrics กับ HPA

การ scale ตาม CPU/Memory เพียงอย่างเดียวอาจไม่พอสำหรับแอปพลิเคชันยุคใหม่ HPA รองรับการ scale ตามเมตริกที่กำหนดเอง เช่น จำนวนคำขอต่อวินาที (RPS), ความยาวคิวข้อความ, หรือเมตริกจากระบบภายนอก เช่น Cloud Pub/Sub queue depth

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 80
  - type: Pods # ตัวอย่าง Custom Metric (จาก Prometheus Adapter)
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100 # Scale เมื่อมีค่าเฉลี่ย 100 RPS ต่อ Pod
  - type: External # ตัวอย่าง External Metric (จาก AWS CloudWatch/GCP Stackdriver)
    external:
      metric:
        name: sqs_queue_length
        selector:
          matchLabels:
            queueName: my-orders
      target:
        type: AverageValue
        averageValue: 1000 # Scale เมื่อความยาวคิวถึง 1000 ข้อความ

การปรับแต่ง Behavior ของ HPA: Stabilization Window และ Scaling Policies

เพื่อป้องกันการ “กระพริบ” (Flapping) ของ Pod จำนวนซึ่งเพิ่มค่าใช้จ่ายและลดเสถียรภาพ การปรับ `behavior` ใน HPA (ตั้งแต่ Kubernetes 1.18) เป็นสิ่งจำเป็น

• scaleDown.stabilizationWindowSeconds: กำหนดเวลารอก่อนจะ scale down (เช่น 300 วินาที) เพื่อให้แน่ใจว่าการลดโหลดนั้นเกิดขึ้นจริง ไม่ใช่แค่ Spike ชั่วคราว
• policies: กำหนดอัตราการ scale ขึ้น/ลงสูงสุดในระยะเวลาที่กำหนด (เช่น scale down ได้ไม่เกิน 50% ของ replicas ในทุก 60 วินาที)

Best Practices และข้อควรระวังสำหรับการลดค่าใช้จ่ายใน Production

การนำเทคนิคเหล่านี้ไปใช้ในระบบจริง จำเป็นต้องมีกรอบการทำงานและข้อควรระวังเพื่อหลีกเลี่ยงปัญหาที่อาจทำให้ระบบล่มหรือค่าใช้จ่ายบานปลาย

1. เริ่มต้นด้วยการวิเคราะห์และตั้ง Baseline

ก่อนปรับแต่งใดๆ ให้ใช้เครื่องมือเช่น kubectl top pods/nodes, Prometheus + Grafana, หรือซอฟต์แวร์จัดการค่าใช้จ่ายคลาวด์ (เช่น GCP Cost Explorer, AWS Cost & Usage Report) เพื่อทำความเข้าใจรูปแบบการใช้งานทรัพยากรปัจจุบัน ระบุ Pod ที่มีปัญหา Over-provisioning มากที่สุด

2. กำหนด Resource Requests/Limits ให้เหมาะสมตั้งแต่แรก

VPA จะทำงานได้ดีที่สุดเมื่อมีข้อมูลประวัติการใช้งานที่เพียงพอ ระหว่างนั้น ให้ตั้งค่า `requests` และ `limits` อย่างมีเหตุผลโดยอิงจาก Load Testing หรือการรันใน Staging Environment

3. ใช้โหมดที่เหมาะสมของ VPA

• Off: แค่ให้คำแนะนำ (ปลอดภัยที่สุดสำหรับ Production)
• Initial: ปรับเฉพาะตอน Pod ถูกสร้างครั้งแรก
• Auto/Recreate: ปรับอัตโนมัติและ restart Pod (ใช้ด้วยความระมัดระวังสูง ควรมี Pod Disruption Budget และการทดสอบอย่างละเอียด)

4. แยก Workload ที่สำคัญและทดสอบการ Scale อย่างสม่ำเสมอ

Stateful workloads (เช่น databases) มักไม่เหมาะกับ VPA แบบ Auto เนื่องจากกระบวนการ restart อาจซับซ้อน จัดการกับ workload ประเภทนี้ด้วยมือหรือใช้โหมด Off เท่านั้น และควรทำ Chaos Engineering หรือ Load Testing เป็นระยะเพื่อตรวจสอบว่า HPA/VPA ทำงานได้ถูกต้องภายใต้สภาวะ压力

5. ตรวจสอบและตั้ง Alert อย่างใกล้ชิด

ตั้ง Alert สำหรับเหตุการณ์สำคัญ เช่น:

• HPA ไปติดขีดจำกัด `maxReplicas` แล้วแต่ระบบยังรับโหลดไม่ไหว
• VPA แนะนำให้เพิ่มทรัพยากรเกินค่าที่กำหนดไว้ (อาจเป็นสัญญาณของ Memory Leak)
• Pod ถูก OOMKilled บ่อยครั้ง
• ค่าใช้จ่ายคลาวด์เพิ่มขึ้นผิดปกติในระยะเวลาสั้น

กรณีศึกษาและตัวอย่างจริง (Real-World Use Cases)

กรณีศึกษา 1: บริการ E-Commerce ประหยัดค่าใช้จ่ายได้ 40% ในช่วง Low Season

ปัญหา: แพลตฟอร์ม E-Commerce แห่งหนึ่งมี Traffic สูงสุดในช่วง Flash Sale (20-50 เท่าของเวลาปกติ) แต่ในเวลากลางคืนและวันธรรมดา Traffic ต่ำมาก ทีม DevOps ตั้งค่า Deployment ไว้ตายตัวด้วย replicas คงที่จำนวนมาก ทำให้เสียค่าใช้จ่ายฟรีเกือบ 60% ของเวลาทั้งหมด

โซลูชัน:

1. ติดตั้ง HPA โดยใช้เมตริกผสมระหว่าง CPU Utilization (target 75%) และ Custom Metric จาก Prometheus คือ `http_requests_per_second` (target 150 RPS ต่อ Pod)
2. ตั้ง `minReplicas=3` สำหรับความพร้อมขั้นต่ำ, `maxReplicas=50` สำหรับช่วง Peak
3. ใช้ VPA ในโหมด `Off` เพื่อวิเคราะห์และปรับค่า `requests` ของ Pod จากที่เคยขอ CPU 1 core/1GiB ต่อ Pod มาเป็น 500m/512MiB ตามข้อมูลจริง
4. ปรับ `behavior.scaleDown` ให้ช้า (stabilization 10 นาที) เพื่อป้องกันการ scale ลงเร็วเกินไประหว่างที่มีผู้ใช้ใช้งานอยู่

ผลลัพธ์: ระบบสามารถลด replicas ลงเหลือ 3-5 Pod ในเวลากลางคืนโดยอัตโนมัติ และพุ่งขึ้นถึง 40+ Pod ได้ภายใน 3-5 นาทีเมื่อเริ่ม Flash Sale ค่าใช้จ่ายคลาวด์รายเดือนลดลงเฉลี่ย 40% โดยไม่มีผลกระทบต่อผู้ใช้

กรณีศึกษา 2: สตาร์ทอัพ SaaS ลดการ Over-provisioning ของ Batch Job ลง 70%

ปัญหา: บริการ SaaS ที่มี Batch Job สำหรับประมวลผลรายงานที่รันทุกชั่วโมง แต่ละ Job ขอทรัพยากรแบบคงที่สูงสุด (CPU 2 cores, Memory 4GiB) เพื่อรองรับกรณีที่แย่ที่สุด (worst-case) ซึ่งเกิดขึ้นเพียง 5% ของการรันทั้งหมด ที่เหลือใช้ทรัพยากรไม่ถึง 30%

โซลูชัน:

1. เปลี่ยนจากการรัน Job แบบกำหนดทรัพยากรตายตัว มาใช้ Kubernetes Job ร่วมกับ VPA ในโหมด `Auto`
2. ตั้ง `minAllowed` และ `maxAllowed` ที่เหมาะสมเพื่อควบคุมไม่ให้ VPA ขนาด Pod เกินขอบเขตที่ Node รองรับได้
3. เนื่องจากเป็น Job สั้น (รันไม่เกิน 15 นาที) การ restart Pod จาก VPA จึงไม่มีผลกระทบต่อ Availability

ผลลัพธ์: VPA ปรับขนาดทรัพยากรของ Job แต่ละครั้งให้เหมาะสมกับข้อมูลที่ประมวลผลจริง โดยเฉลี่ยแล้ว Job ใช้ CPU ~600m และ Memory ~1.2GiB เท่านั้น ลดการจองทรัพยากรที่ไม่ได้ใช้ลงได้ถึง 70% และยังช่วยให้หลาย Job สามารถรันพร้อมกันบน Node เดียวกันได้มากขึ้น ลดเวลาในการรอคิว (queue time) ลง

เทรนด์และเครื่องมือเสริมในปี 2026

การ Optimize ค่าใช้จ่ายบน Kubernetes ไม่หยุดอยู่แค่ HPA และ VPA ในปี 2026 เราเห็นการบูรณาการกับเครื่องมือและแนวทางที่ชาญฉลาดขึ้น

1. Kubernetes Event-driven Autoscaling (KEDA)

KEDA เป็น autoscaler ที่ออกแบบมาเพื่องาน event-driven โดยเฉพาะ มันสามารถ scale Pod ลงเหลือเป็น 0 (Zero-scale) ได้เมื่อไม่มี event เข้ามา ซึ่งประหยัดค่าใช้จ่ายได้มากกว่า HPA ทั่วไป (ที่ scale ลงได้แค่ถึง `minReplicas`) เหมาะอย่างยิ่งกับงานที่ประมวลผลจากคิว, Event Streams, หรือ Scheduled Tasks

2. FinOps และ Cloud Cost Management Platforms

เครื่องมือเช่น Kubecost, OpenCost, หรือฟีเจอร์ใน Cloud Provider เอง (เช่น GCP’s Kubernetes Cost Optimization) จะให้ visibility ในระดับที่ลึกกว่า แสดงการ映射ระหว่างทรัพยากร Kubernetes กับบิลคลาวด์รายวัน แนะนำการปรับขนาด Node Pool, เลือก Instance Type ที่คุ้มค่า หรือแม้แต่การซื้อ Reserved Instances/Savings Plans โดยอิงจากข้อมูลการใช้จริงจากคลัสเตอร์

3. AI-Powered Recommendations

แพลตฟอร์มชั้นนำเริ่มใช้ Machine Learning เพื่อวิเคราะห์รูปแบบการใช้งานในอดีตและทำนายแนวโน้มในอนาคต จากนั้นให้คำแนะนำการตั้งค่า HPA/VPA ที่เหมาะสมที่สุด (เช่น ควรเปลี่ยนเมตริกไหน, ตั้ง target utilization เท่าไหร่, กำหนด min/max replicas อย่างไร) แทนที่การลองผิดลองลองด้วยมนุษย์

4. Serverless Containers (เช่น AWS Fargate, GCP Cloud Run)

ในบางกรณี การย้าย workload บางส่วนไปสู่ Serverless Containers ที่คิดค่าบริการตามวินาทีและตามการใช้งานจริง (request, vCPU-second) อาจคุ้มค่ากว่าการจัดการคลัสเตอร์ Kubernetes และการ autoscale ด้วยตัวเอง โดยเฉพาะสำหรับ workload ที่มีรูปแบบการใช้งานไม่แน่นอนและมีช่วงว่างยาวๆ

Summary

การลดค่าใช้จ่ายคลาวด์บน Kubernetes ด้วย HPA และ VPA ไม่ใช่แค่การเปิดใช้ฟีเจอร์แล้วหวังผล แต่เป็นศาสตร์และศิลป์ที่ต้องอาศัยความเข้าใจในธรรมชาติของแอปพลิเคชัน การวิเคราะห์ข้อมูลอย่างต่อเนื่อง และการปรับแต่งอย่างละเอียดอ่อน กลยุทธ์ที่ได้ผลที่สุดมักเป็นการใช้เครื่องมือทั้งสองร่วมกันแบบ Hybrid: ให้ VPA ช่วยหาขนาดทรัพยากรที่ “พอดีตัว” สำหรับ Pod ของคุณ และให้ HPA ดูแลการเพิ่มลดจำนวน Pod ตามความต้องการของธุรกิจที่เปลี่ยนแปลงไป พร้อมทั้งเสริมด้วย Custom/External Metrics เพื่อให้การ scale ตอบสนองได้ตรงจุดยิ่งขึ้น

ในปี 2026 ภูมิทัศน์ของการ optimize ยังคงพัฒนาอย่างไม่หยุดนิ่ง ด้วยการมาของเครื่องมืออย่าง KEDA แนวทาง FinOps และ AI Recommendations ซึ่งเปิดโอกาสให้ทีม DevOps และ Engineering สามารถควบคุมค่าใช้จ่ายได้แม่นยำและโปรactive มากขึ้นกว่าเดิม สิ่งสำคัญที่สุดคือการเริ่มต้น เก็บข้อมูล ตั้ง Baseline ค่อยๆ ทดลองปรับในสภาพแวดล้อมที่ไม่ใช่ Production ก่อน แล้วจึงนำไปใช้จริงพร้อมกับ Monitoring และ Alerting ที่เข้มงวด การลงทุนเวลาเพื่อเรียนรู้และปรับใช้เครื่องมือเหล่านี้ ไม่เพียงแต่จะลดค่าใช้จ่ายลงได้อย่างมหาศาล แต่ยังเป็นการสร้างวัฒนธรรมการทำงานที่เน้นประสิทธิภาพและความรับผิดชอบต่อทรัพยากร ซึ่งจะเป็นรากฐานที่แข็งแกร่งให้กับองค์กรในระยะยาว