Spot, ARM, Confidential Nodes, Reservations và Node Labeling Strategy

Vì sao chủ đề này quan trọng

Phần lớn đội kỹ thuật tối ưu node theo một chiều duy nhất: hoặc rẻ nhất, hoặc mạnh nhất, hoặc “an toàn nhất”. Production thật thì phải tối ưu đa mục tiêu: SLO, cost, security, capacity certainty, và tốc độ rollback. Chương này tập trung vào cách chọn đúng profile node pool theo workload tier.

Tài liệu chính thức của GKE cung cấp đầy đủ các cơ chế cần thiết: Spot VMs, ARM node pools, Confidential GKE Nodes, reservation affinity và labeling/scheduling primitives (Spot VMs, Arm workloads, Confidential GKE Nodes, Consuming reservations).

Spot Nodes trong GKE: lợi ích và mặt trái

Mô hình hoạt động

Spot VMs cho phép dùng công suất rẻ hơn nhưng có thể bị thu hồi khi Compute Engine cần lại tài nguyên. Trong GKE, khi node Spot bị preempt, bạn có khoảng cảnh báo ngắn (thường 30 giây) để shutdown workload an toàn tùy cấu hình cluster/version (Spot VMs termination behavior).

Khi nào nên dùng Spot

Phù hợp:

• Batch jobs, async workers, queue consumers có idempotency tốt.
• Stateless APIs có autoscaling nhanh và retry an toàn.
• ML preprocessing không yêu cầu hoàn thành tức thì.

Không phù hợp:

• Thành phần quorum thấp, stateful khó recover nhanh.
• Workload yêu cầu latency ổn định tuyệt đối.
• Dịch vụ không có backpressure/retry đúng nghĩa.

Preemption burst là failure mode phải thiết kế trước

Rủi ro lớn nhất không phải một node bị thu hồi, mà là nhiều node Spot cùng bị thu hồi trong peak traffic. Nếu bạn không có phân tầng pool (on-demand + Spot), SLO sẽ tụt nhanh.

Pattern khuyến nghị:

• Luôn có base capacity trên node không-Spot.
• Spot chỉ đảm nhận phần burst hoặc workload low-priority.
• Áp dụng priority classes + disruption policy để workload cốt lõi không bị đẩy ra.

Node termination grace period và shutdown behavior

Kubernetes hỗ trợ graceful node shutdown qua kubelet và cấu hình shutdown grace period (Node shutdowns). Trên GKE, cơ chế này cần được nhìn như một “khoảng ngân sách thời gian” để:

1. Stop nhận request mới.
2. Flush in-flight state.
3. Commit checkpoint/tombstone cần thiết.

Nếu pod cần 45 giây để flush nhưng cluster chỉ cho hiệu lực 30 giây trước khi VM tắt, bạn sẽ có mất dữ liệu logic dù storage vẫn bền vững.

ARM-based nodes (Tau T2A): không chỉ là giảm giá

Tương thích workload

GKE hỗ trợ chạy ARM workloads và cho phép trộn node ARM/x86 trong cùng cluster, nhưng yêu cầu image đa kiến trúc hoặc image ARM riêng, cộng với scheduling rõ ràng qua labels/affinity (Arm workloads on GKE, Create Arm node pools).

Điểm mấu chốt: vấn đề thường không nằm ở app chính, mà ở hệ sinh thái phụ trợ:

• Sidecar agent chưa có ARM build.
• Plugin observability thiếu binary ARM.
• Native extension (JNI, C/C++) chỉ build x86.

Đặc tính hiệu năng

T2A thường có profile hiệu năng/chi phí tốt cho workload scale ngang, stateless, nhiều instance. Tuy nhiên bạn cần benchmark theo workload thật, không suy luận từ core count. Với dịch vụ nhạy độ trễ hoặc phụ thuộc SIMD/x86 extension, kết quả có thể ngược kỳ vọng.

Confidential Nodes: bảo mật dữ liệu in-use

Confidential GKE Nodes dựa trên Compute Engine Confidential VM (AMD SEV/SEV-SNP) để mã hóa bộ nhớ khi workload đang chạy, giúp giảm rủi ro đọc trộm từ lớp hạ tầng vật lý/privileged path (Confidential GKE Nodes).

Trade-off:

• Tăng mức bảo mật cho dữ liệu in-use.
• Có thể có overhead hiệu năng tùy loại workload, đặc biệt workload memory-bound.

Quyết định đúng thường theo phân loại dữ liệu:

• Dữ liệu nhạy cảm cao (PII, tài chính): ưu tiên confidential pool.
• Workload hiệu năng cực nhạy: benchmark trước, có thể tách pool không-confidential cho đường xử lý không nhạy cảm.

Reservations: capacity certainty cho ngày xấu nhất

Trong sự cố vùng/đợt nâng cấp lớn, vấn đề hay gặp là autoscaler muốn thêm node nhưng zone không còn capacity loại máy cần thiết. Compute Engine reservations giúp bạn “đặt chỗ” tài nguyên trước; GKE node pools có thể cấu hình reservation affinity để tiêu thụ reservation phù hợp (Consuming reserved zonal resources).

Đây là công cụ quan trọng cho:

• Workload có SLA chặt.
• GPU/high-memory nodes khó mua tức thời.
• Kịch bản blue-green cần nhân đôi công suất tạm thời.

Lưu ý: reservation giải bài toán capacity guarantee, không tự động giải bài toán chi phí tổng thể. Bạn cần kết hợp committed use discount và kế hoạch nhu cầu theo mùa.

Node labeling strategy cho scheduling có kiểm soát

Kubernetes và GKE cung cấp nhiều label mặc định hữu ích như:

• kubernetes.io/arch
• kubernetes.io/os
• cloud.google.com/gke-nodepool

Dùng nhãn nhất quán giúp bạn routing workload theo kiến trúc, pool, môi trường, compliance domain (Assign Pods to Nodes).

Chiến lược nhãn thực chiến

• Nhãn “đặc tính hạ tầng”: arch=arm64|amd64, capacity=spot|ondemand, security=confidential|standard.
• Nhãn “mục tiêu workload”: tier=critical|batch.
• Tránh dùng nhãn quá chi tiết theo service để không gây nổ số lượng selector khó quản trị.

Anti-pattern: dùng label như IAM hoặc policy engine. Label chỉ nên phục vụ scheduling/topology, không thay vai trò của RBAC/Org Policy.

Production architecture patterns

Pattern 1: Three-pool baseline

• Pool A (on-demand, x86, standard): chạy core services.
• Pool B (Spot): chạy burst workers.
• Pool C (confidential hoặc ARM): workload chuyên biệt.

Lợi ích: tách rủi ro vận hành và tối ưu theo từng loại việc.

Pattern 2: Dual-arch migration

Khi chuyển một platform từ x86 sang ARM:

1. Build multi-arch image.
2. Canary workload trên ARM pool.
3. Theo dõi error rate + latency + cost.
4. Mở rộng dần tỷ lệ traffic.

Không migrate “big bang” vì chuỗi phụ thuộc binary khó đoán trước.

Pattern 3: Reservation-backed critical pools

Với node pool chạy dịch vụ doanh thu chính:

• Dành reservation theo zone.
• Duy trì floor capacity không phụ thuộc Spot.
• Kết hợp autoscaler để mở rộng thêm phần không-critical.

Real-world scenarios

Scenario 1: Spot tiết kiệm 45% chi phí nhưng mất SLO giờ cao điểm

Nguyên nhân:

• 80% traffic xử lý trên Spot.
• Preemption burst trùng giờ marketing campaign.

Cách sửa:

• Giảm tỷ lệ Spot ở service trực tiếp với người dùng.
• Giữ Spot cho tầng async/background.
• Bổ sung circuit breaker và queue decoupling.

Scenario 2: ARM rollout fail vì sidecar telemetry

Nguyên nhân:

• App chính có multi-arch image.
• Sidecar observability chỉ có amd64.

Cách sửa:

• Kiểm kê dependency toàn pod, không chỉ container chính.
• Gate CI cho multi-arch artifact completeness.

Scenario 3: Confidential pool tăng bảo mật nhưng tăng latency giao dịch

Nguyên nhân:

• Workload memory-intensive.
• Chưa benchmark trước khi cắt traffic thật.

Cách sửa:

• Áp dụng workload partitioning: phần xử lý nhạy cảm chạy confidential, phần còn lại chạy standard.

Common mistakes / anti-patterns

1. Đẩy toàn bộ workload lên Spot để tối ưu chi phí ngắn hạn
2. Migrate ARM mà không audit toàn bộ sidecar/agent/toolchain
3. Bật Confidential Nodes theo phong trào compliance, không benchmark
4. Không dùng reservation cho pool critical rồi bất ngờ thiếu capacity khi sự cố
5. Lạm dụng nodeSelector cứng thay vì affinity có ưu tiên, làm scheduler kém linh hoạt

GCP-native implementation guidance

Tạo Spot node pool

gcloud container node-pools create spot-pool \
  --cluster=<cluster-name> \
  --region=<region> \
  --spot \
  --node-labels=capacity=spot

Tạo ARM node pool

gcloud container node-pools create arm-pool \
  --cluster=<cluster-name> \
  --region=<region> \
  --machine-type=t2a-standard-4 \
  --node-labels=arch=arm64

Tạo confidential node pool

gcloud container node-pools create confidential-pool \
  --cluster=<cluster-name> \
  --region=<region> \
  --confidential-node-type=sev \
  --node-labels=security=confidential

Ví dụ scheduling theo labels

apiVersion: apps/v1
kind: Deployment
metadata:
  name: worker-spot
spec:
  replicas: 3
  selector:
    matchLabels:
      app: worker-spot
  template:
    metadata:
      labels:
        app: worker-spot
    spec:
      nodeSelector:
        capacity: spot
      containers:
        - name: app
          image: gcr.io/example/worker:latest

Kết nối Well-Architected

• Cost optimization + Reliability: Spot chỉ nên chiếm phần công suất có thể mất; không đánh đổi SLO cốt lõi lấy chi phí ngắn hạn (Well-Architected).
• Security: Confidential Nodes là lớp bảo vệ mạnh cho dữ liệu in-use, nhưng phải cân bằng với hiệu năng và khả năng vận hành (Confidential GKE Nodes).

References

• Spot VMs in GKE
• Termination and graceful shutdown of Spot VMs
• Node shutdowns (Kubernetes)
• Arm workloads on GKE
• Create Standard clusters and node pools with Arm nodes
• Confidential GKE Nodes
• Consume reserved zonal resources
• Assign Pods to Nodes

Phụ lục chuyên sâu: chiến lược phân tầng node pools theo mục tiêu business

Mô hình “cost floor + burst ceiling” với Spot

Một kiến trúc thường hiệu quả cho dịch vụ có tải biến động:

• Cost floor: công suất nền chạy trên on-demand/reserved nodes để giữ SLO tối thiểu.
• Burst ceiling: công suất tăng thêm chạy trên Spot.

Khi Spot bị thu hồi hàng loạt, hệ thống vẫn còn cost floor để giữ chức năng cốt lõi. Đây là cách dùng Spot an toàn hơn thay vì đặt cược toàn bộ lên tài nguyên có thể mất.

Thiết kế priority classes đi cùng Spot

Spot chỉ an toàn khi có phân lớp ưu tiên workload rõ ràng:

• Class cao: API xử lý giao dịch, auth, payment.
• Class trung bình: các dịch vụ hỗ trợ có thể degraded ngắn hạn.
• Class thấp: batch và precompute.

Khi bị áp lực tài nguyên, scheduler và eviction policy có cơ sở để giữ lại dịch vụ quan trọng trước.

ARM adoption playbook

Giai đoạn 1: kiểm kê tương thích

• Audit tất cả images trong pod (main + sidecar + init containers).
• Kiểm tra thư viện native, agent bảo mật, exporter metrics.
• Kiểm tra CI/CD có build multi-arch không.

Giai đoạn 2: canary có đo lường

• Chuyển 5–10% workload sang ARM pool.
• Đo p95 latency, CPU throttling, error rate, chi phí/throughput.
• Theo dõi ít nhất một chu kỳ tải đỉnh.

Giai đoạn 3: mở rộng có kiểm soát

• Mở theo từng namespace/team.
• Duy trì khả năng quay lại x86 nhanh nếu có lỗi ẩn.

Mục tiêu không phải “ARM bằng mọi giá”, mà là chọn đúng workload để có hiệu quả chi phí/hiệu năng thật sự.

Confidential Nodes và mô hình dữ liệu nhạy cảm

Nên xác định rõ data classification trước khi bật confidential:

• Cấp 1: dữ liệu nhạy cảm rất cao, yêu cầu bảo vệ in-use mạnh.
• Cấp 2: dữ liệu nội bộ nhưng rủi ro thấp hơn.
• Cấp 3: dữ liệu công khai hoặc dễ tái tạo.

Không nhất thiết mọi workload đều cần confidential pool. Chạy toàn bộ trên confidential đôi khi tạo chi phí hiệu năng không cần thiết.

Reservation strategy cho ngày “capacity storm”

Capacity storm thường xảy ra khi nhiều yếu tố trùng nhau:

• Sự cố node cần thay thế.
• Nâng cấp định kỳ cần node surge.
• Traffic tăng bất ngờ cần autoscale.

Nếu không có reservation cho pool critical, bạn có thể thất bại ngay ở bước mua máy, dù kiến trúc Kubernetes hoàn toàn đúng. Reservation là công cụ bảo đảm “quyền được scale” trong kịch bản xấu nhất.

Label taxonomy và chuẩn đặt tên

Đề xuất taxonomy đơn giản, ổn định:

• infra.arch: amd64|arm64
• infra.capacity: ondemand|spot|reserved
• infra.security: standard|confidential
• workload.tier: critical|standard|batch

Ưu điểm:

• Dễ đọc trong nodeSelector/affinity.
• Hạn chế trùng lặp semantic.
• Dễ mở rộng khi có loại node mới.

Tránh “selector lock-in”

Nếu mọi deployment dùng nodeSelector cứng vào một pool cụ thể, bạn sẽ khó điều phối khi pool đó sự cố. Tốt hơn:

• Dùng affinity ưu tiên theo lớp hạ tầng.
• Chỉ dùng selector cứng cho workload thật sự bắt buộc.

Sự khác nhau giữa tối ưu chi phí và tối ưu tổng chi phí sở hữu

• Tối ưu chi phí trực tiếp: giảm tiền VM ngay tháng này.
• Tối ưu tổng chi phí sở hữu: tính thêm downtime risk, toil vận hành, chi phí incident.

Nhiều chiến lược Spot quá “aggressive” giúp giảm hóa đơn compute nhưng làm tăng số giờ trực incident, cuối cùng không rẻ hơn.

Kịch bản đa tenant trên cùng cluster

Nếu nhiều tenant dùng chung cluster:

• Tenant premium nên có floor capacity ổn định (on-demand/reserved).
• Tenant non-critical có thể ưu tiên Spot.
• Policy scheduling phải tách rõ để tenant này không “ăn” tài nguyên đảm bảo của tenant khác.

Guardrails vận hành bắt buộc

• Cảnh báo khi tỷ lệ pod critical chạy trên Spot vượt ngưỡng.
• Cảnh báo khi capacity reserved bị dùng lệch mục đích.
• Báo cáo định kỳ tương thích image theo kiến trúc (arm64/amd64).
• Drill định kỳ cho preemption burst.

Playbook xử lý preemption burst 30 giây

1. Kích hoạt chế độ giảm tải: tắt tác vụ nền không thiết yếu.
2. Ưu tiên traffic cho đường giao dịch quan trọng.
3. Scale nhanh pool on-demand nếu còn quota/capacity.
4. Theo dõi queue depth và retry storm.
5. Sau ổn định, cập nhật lại tỷ lệ Spot mục tiêu.

Các chỉ số cần quản trị cho chương này

• Tỷ lệ pod critical chạy trên on-demand/reserved.
• Tỷ lệ preemption của Spot theo giờ/ngày.
• Mức sử dụng reservation theo zone.
• Chênh lệch p95 latency giữa ARM và x86.
• Chênh lệch throughput/chi phí giữa pool profiles.

Bài học triển khai thực tế

• Không có “pool tốt nhất”, chỉ có pool phù hợp từng workload.
• Tách bài toán: cost, reliability, security, capacity certainty.
• Dùng labels và policy để biến lựa chọn kiến trúc thành hành vi scheduling nhất quán.

References bổ sung

• Compute Engine reservations overview
• GKE best practices
• Google Cloud Well-Architected Framework

FAQ thực chiến

Có thể chạy toàn bộ production trên Spot không?

Về kỹ thuật có thể trong một số bài toán rất đặc thù, nhưng với hầu hết hệ thống kinh doanh thì không nên. Cần có phần công suất nền ổn định để bảo vệ SLO khi Spot bị thu hồi.

ARM có luôn rẻ hơn x86 cho mọi workload?

Không. Chi phí trên mỗi vCPU có thể tốt hơn, nhưng hiệu quả thực phải đo theo thông lượng nghiệp vụ, độ trễ và mức tương thích hệ sinh thái. Có workload chạy ARM hiệu quả, có workload không.

Confidential Nodes có bắt buộc cho mọi dữ liệu nhạy cảm?

Nên dựa trên mô hình đe dọa và yêu cầu compliance cụ thể. Confidential Nodes là lớp bảo vệ mạnh cho dữ liệu in-use, nhưng vẫn cần kết hợp mã hóa at-rest/in-transit, IAM và giám sát truy cập.

Reservation có làm mất linh hoạt autoscaling?

Không nhất thiết. Nếu thiết kế đúng, reservation chỉ bảo đảm phần capacity tối thiểu, còn autoscaler vẫn có thể dùng capacity không-reserved cho phần burst.

Checklist quyết định profile node cho workload mới

1. Workload có cần độ sẵn sàng cao liên tục không?
2. Workload có chịu được mất node đột ngột không?
3. Có yêu cầu compliance về dữ liệu in-use không?
4. Có phụ thuộc binary chỉ hỗ trợ một kiến trúc CPU không?
5. Có nhu cầu capacity guarantee vào giờ cao điểm không?
6. Có thể đo lường hiệu quả chi phí theo business KPI không?

Nếu câu trả lời cho (1) là có và (2) là không, không nên đặt workload chính lên Spot. Nếu câu trả lời cho (3) là có, cần đánh giá confidential pool. Nếu câu trả lời cho (4) là có, tránh migrate ARM vội. Nếu câu trả lời cho (5) là có, cân nhắc reservations.

Khuyến nghị áp dụng theo từng nhóm workload

• Dịch vụ giao dịch cốt lõi: on-demand/reserved, có thể thêm confidential tùy dữ liệu.
• Dịch vụ xử lý nền: kết hợp Spot + queue + retry idempotent.
• Dịch vụ phân tích nội bộ: ARM hoặc Spot tùy độ nhạy về thời gian hoàn thành.

Mục tiêu là tối ưu danh mục node pool theo giá trị nghiệp vụ, không tối ưu từng service riêng lẻ một cách rời rạc.

Phụ lục tình huống chọn node profile theo ngành

E-commerce

• Frontend/API checkout: ưu tiên on-demand/reserved.
• Recommendation async jobs: có thể tận dụng Spot.
• Dữ liệu thanh toán: cân nhắc confidential cho thành phần xử lý nhạy cảm.

EdTech

• Tải biến động mạnh theo giờ học.
• Spot phù hợp cho video transcoding, batch analytics.
• ARM phù hợp cho dịch vụ stateless nếu stack tương thích tốt.

Internal platform

• Nền tảng chia sẻ cho nhiều đội cần chính sách rõ ràng.
• Reservation cho pool platform core để tránh thiếu capacity khi có sự cố diện rộng.
• Labels chuẩn hóa bắt buộc để tránh xung đột lịch chạy giữa các tenant nội bộ.

Ghi chú triển khai theo chu kỳ quý

Mỗi quý nên rà lại tỷ trọng từng loại node profile theo dữ liệu vận hành thực tế:

• Tỷ lệ lỗi do preemption Spot.
• Hiệu quả chi phí thực trên mỗi giao dịch/đơn vị công việc.
• Số incident liên quan tương thích kiến trúc ARM.
• Tác động hiệu năng tại confidential pools.

Nếu không có vòng đánh giá này, kiến trúc node profile sẽ nhanh chóng lệch khỏi nhu cầu business thực.