Max Pods, Flex Pod CIDR, Boot Disk, Local SSD và Capacity Design

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

Nhiều cluster “đủ CPU/RAM” nhưng vẫn không scale được vì hết Pod IP. Nhiều cluster khác có đủ IP nhưng pod startup chậm vì boot disk yếu khiến image pull thành nút cổ chai. Đây là kiểu lỗi capacity khó thấy trong dashboard tổng quan nhưng gây downtime đúng lúc traffic tăng.

GKE VPC-native dựa trên Alias IP và secondary ranges cho Pods/Services, vì vậy maxPodsPerNode, kích thước secondary ranges và chiến lược mở rộng CIDR là các quyết định kiến trúc ngay từ đầu (Flexible Pod CIDR, Network best practices).

Internal model: max pods per node và Alias IP

Cơ chế phân bổ Pod IP trên GKE VPC-native

Mỗi node được cấp một dải Pod CIDR con từ secondary range của subnet. maxPodsPerNode càng lớn thì dải cấp cho mỗi node càng phải rộng để còn headroom địa chỉ (Configure maximum Pods per node).

Điều này tạo trade-off:

• Tăng maxPodsPerNode giúp tăng mật độ pod/node.
• Nhưng tiêu hao Pod IP nhanh hơn ở cấp subnet/cluster.

Sai lầm phổ biến: chỉ nhìn “node count” mà quên rằng giới hạn thực có thể là IP address space, không phải compute.

Flexible / discontiguous Pod CIDR

Khi secondary range ban đầu không đủ, GKE hỗ trợ mở rộng bằng thêm Pod ranges mới (discontiguous multi-Pod CIDR) cho node pools mới (Add Pod IPv4 address ranges).

Đây là cứu cánh cho cluster đã vào production mà không muốn recreate toàn bộ. Tuy nhiên nó tăng độ phức tạp quản trị IPAM và troubleshooting mạng liên cluster/on-prem.

Capacity planning cho Pod IP: cách nghĩ thực chiến

Công thức thực dụng

Thay vì chỉ tính theo max node lý thuyết, hãy tính theo:

1. Node hiện tại + headroom autoscaling + headroom upgrade surge/blue-green.
2. maxPodsPerNode thực tế (bao gồm hệ thống).
3. Dự phòng tăng trưởng 6–12 tháng.

Nếu bỏ qua headroom upgrade, cluster có thể “đủ IP lúc bình thường” nhưng fail đúng lúc nâng cấp vì node surge không lấy được dải Pod CIDR.

Failure mode: IP exhaustion ngầm

Triệu chứng:

• Cluster autoscaler muốn thêm node nhưng node mới không ready.
• Pod Pending với thông điệp liên quan networking/IP allocation.
• Sự cố bùng lên cùng lúc rollout lớn hoặc scaling event.

Giải pháp:

• Giảm maxPodsPerNode cho pool mới (nếu phù hợp).
• Thêm secondary ranges và phân pool theo range mới.
• Rà soát lại subnet plan ở cấp môi trường.

Boot disk design: hiệu năng startup không được xem nhẹ

GKE cho phép tùy chỉnh boot disk type/size cho node pool (Custom node boot disk). Từ góc nhìn production:

• Disk nhỏ + loại chậm = image pull và unpack chậm.
• Nút cổ chai I/O làm tăng pod cold-start latency.
• Khi deploy hàng loạt, latency startup cộng dồn thành incident.

Compute Engine định nghĩa performance disk theo type/size; IOPS/throughput tăng theo dung lượng tới ngưỡng nhất định (Persistent Disk performance). Vì vậy chọn disk không thể tách khỏi ước tính tải I/O.

Snapshot behavior và vận hành

Boot disk snapshot hữu ích cho forensic hoặc template quản trị, nhưng không nên là cơ chế duy nhất cho backup dữ liệu ứng dụng. Dữ liệu nghiệp vụ cần đi qua Persistent Disk/managed storage có chiến lược backup riêng. Nếu bạn để state quan trọng ở ephemeral path trên node, snapshot boot disk không giúp nhiều cho RPO thực tế.

Local SSD: hiệu năng cao, độ bền thấp

Local SSD trên GKE cho I/O rất cao và độ trễ thấp, phù hợp cache cục bộ, scratch space, hoặc pipeline dữ liệu tạm thời (Local SSD for GKE). Nhưng Local SSD là ephemeral: mất node là mất dữ liệu trên ổ local.

Khi nào nên dùng

• Caching tầng giữa có thể tái tạo.
• ETL/sort/intermediate data không cần giữ lâu.
• Workload AI/analytics cần throughput cao và chấp nhận recompute.

Khi nào không nên dùng

• Stateful primary data không có replication ngoài node.
• Workload yêu cầu durability mạnh nhưng không có tầng lưu trữ bền phía sau.

Production architecture patterns

Pattern 1: IP-aware node pool segmentation

• Pool A: max pods thấp cho services nặng tài nguyên.
• Pool B: max pods cao cho services nhẹ.
• Mỗi pool có Pod range tách biệt để quản trị tăng trưởng rõ ràng.

Kết quả: linh hoạt hơn khi mở rộng, giảm nguy cơ cạn IP đồng loạt.

Pattern 2: Boot disk profile theo loại workload

• Pool API latency-sensitive: pd-ssd hoặc profile I/O cao.
• Pool batch: pd-balanced với dung lượng đủ lớn.
• Không dùng một profile disk cho tất cả để “đỡ phải nghĩ”.

Pattern 3: Local SSD cho cache có replication ngoài

Thiết kế hai lớp:

• Lớp local SSD để tăng tốc.
• Lớp bền vững (Redis/Memorystore/PD/distributed store) để phục hồi.

Mục tiêu: mất node không làm mất dữ liệu nghiệp vụ quan trọng.

Real-world scenarios

Scenario A: Cluster scale fail dù còn nhiều node quota

Nguyên nhân:

• Secondary range nhỏ.
• maxPodsPerNode đặt cao từ đầu.

Kết quả:

• Autoscaler không mở rộng node được vì thiếu Pod CIDR.
• Pod Pending dây chuyền.

Sửa đúng:

• Bổ sung discontiguous Pod CIDR.
• Tạo pool mới dùng range mới.
• Điều chỉnh policy density theo workload.

Scenario B: Deploy giờ cao điểm gây timeout do image pull

Nguyên nhân:

• Node boot disk pd-standard dung lượng nhỏ.
• Nhiều image lớn pull đồng thời.

Kết quả:

• Pod startup vượt SLA readiness.
• HPA tiếp tục scale vì thấy pod chưa ready, làm áp lực tăng thêm.

Sửa đúng:

• Nâng disk type/size cho pool đó.
• Tối ưu image layers.
• Giới hạn rollout concurrency.

Scenario C: Dùng Local SSD cho state tạm tưởng “an toàn đủ dùng”

Nguyên nhân:

• Không có replication ngoài node.
• Auto-repair thay node làm mất dữ liệu.

Sửa đúng:

• Chỉ dùng Local SSD cho dữ liệu có thể tái tạo.
• Áp dụng checkpoint định kỳ ra storage bền.

Common mistakes / anti-patterns

1. Thiết kế CIDR theo hiện tại, không tính mở rộng và nâng cấp
2. Đẩy maxPodsPerNode lên cao chỉ để giảm chi phí node
3. Chọn boot disk rẻ nhất cho mọi pool bất kể profile I/O
4. Dùng Local SSD như persistent storage trá hình
5. Không kiểm thử sự kiện scale + rollout + repair cùng lúc

GCP-native implementation guidance

Tạo cluster với max pods/node tùy chỉnh

gcloud container clusters create <cluster-name> \
  --region=<region> \
  --enable-ip-alias \
  --default-max-pods-per-node=64

Thêm Pod range mới cho subnet/cluster

gcloud compute networks subnets update <subnet> \
  --region=<region> \
  --add-secondary-ranges=<new-pod-range>=10.40.0.0/14

Tạo node pool với boot disk tùy chỉnh

gcloud container node-pools create high-io-pool \
  --cluster=<cluster-name> \
  --region=<region> \
  --disk-type=pd-ssd \
  --disk-size=200

Tạo node pool với Local SSD

gcloud container node-pools create localssd-pool \
  --cluster=<cluster-name> \
  --region=<region> \
  --ephemeral-storage-local-ssd=count=2

Kết nối với Architecture Framework

• Reliability: capacity planning phải gồm cả tài nguyên “vô hình” như Pod IP, không chỉ CPU/RAM (Reliability).
• Performance optimization: tối ưu startup path bằng boot disk profile và image strategy phù hợp (Well-Architected framework).

References

• Configure maximum Pods per node
• Add Pod IPv4 address ranges (multi-Pod CIDR)
• GKE networking best practices
• Custom node boot disk
• Compute Engine disk performance
• About Local SSD for GKE
• Google Cloud Architecture Framework

Phụ lục chuyên sâu: mô hình năng lực node theo trục IP, I/O và thời gian khởi động

Vì sao phải tách ba trục năng lực

Khi nói “cluster đủ tài nguyên”, nhiều đội chỉ nhìn CPU và memory. Với GKE production, bạn cần thêm hai chiều nữa:

• IP capacity (số Pod IP khả dụng).
• I/O startup capacity (khả năng pull/unpack image trong thời gian ngắn).

Nếu thiếu một trong ba chiều, autoscaling vẫn có thể thất bại.

Trục 1: IP capacity

Đây là tài nguyên hữu hạn theo subnet/secondary ranges. Nên có dashboard riêng:

• Tỷ lệ sử dụng Pod secondary range.
• Số node tối đa còn có thể thêm theo cấu hình hiện tại.
• Dự báo thời điểm cạn IP theo tốc độ tăng trưởng.

Trục 2: I/O startup capacity

Năng lực này quyết định cluster phục hồi nhanh hay chậm sau sự cố node:

• Disk type/size.
• Tốc độ registry pull.
• Kích thước image.
• Số pod khởi động đồng thời.

Nút cổ chai I/O thường ẩn vì CPU/RAM nhìn vẫn “rảnh”.

Trục 3: Startup time budget

SLO của bạn thực tế có một ngân sách thời gian cho khôi phục:

• Node bootstrap time.
• Pod scheduling + image pull.
• App init + readiness.

Nếu tổng thời gian vượt ngân sách khi có disruption, người dùng sẽ thấy lỗi dù hệ thống cuối cùng “vẫn lên được”.

Quy trình capacity review theo quý

1. Rà soát dự báo tăng pod theo từng domain nghiệp vụ.
2. Đối chiếu với quỹ Pod CIDR còn lại.
3. Chạy bài test scale giả lập trong môi trường gần production.
4. Cập nhật maxPodsPerNode hoặc bổ sung Pod ranges nếu cần.
5. Đánh giá lại boot disk profile theo thực tế release cadence.

Thiết kế maxPodsPerNode theo profile dịch vụ

• Dịch vụ nặng CPU/memory: mật độ thấp, dễ cô lập lỗi.
• Dịch vụ nhẹ nhưng nhiều bản sao: mật độ cao có thể tối ưu chi phí.
• Dịch vụ latency-critical: ưu tiên headroom và startup ổn định hơn là mật độ cực đại.

Không dùng một giá trị maxPodsPerNode cho tất cả node pools.

Tác động của rollout strategy lên Pod CIDR

Surge hoặc blue-green đều tăng nhu cầu node tạm thời. Nếu không tính phần node tạm vào IP planning, upgrade có thể kẹt vì thiếu Pod IP ngay giữa chừng. Vì vậy capacity model phải gắn liền với chiến lược nâng cấp đã chọn ở chương trước.

Boot disk và incident “khởi động chậm dây chuyền”

Một failure mode phổ biến:

1. Một phần node bị thay.
2. Pod dồn lên node mới.
3. Image pull chậm do disk/registry bottleneck.
4. Readiness timeout tăng, autoscaler tăng thêm node.
5. Hệ thống rơi vào vòng lặp mở rộng nhưng không kịp phục hồi.

Giải pháp không chỉ là tăng node; phải xử lý gốc ở startup path.

Local SSD: chiến lược an toàn

Nếu dùng Local SSD cho dữ liệu tạm:

• Luôn có cơ chế tái tạo dữ liệu.
• Không gán trách nhiệm durability cho local path.
• Có cơ chế kiểm soát cache stampede sau khi mất node.

Nếu không, mỗi lần auto-repair có thể tạo “cold start storm”.

Mẫu phân loại dữ liệu theo độ bền

• Ephemeral fast data: đặt trên Local SSD.
• Durable operational data: đặt trên Persistent Disk/managed DB.
• Archival data: Cloud Storage hoặc tier lưu trữ phù hợp.

Phân lớp rõ giúp tránh lẫn vai trò giữa hiệu năng và bền vững.

Sai lầm thường gặp khi mở rộng subnet

• Mở rộng range nhưng không cập nhật tài liệu IPAM.
• Thêm range chồng lấn với kế hoạch hybrid/on-prem.
• Không chuẩn hóa naming ranges theo môi trường/cluster.

Kết quả: khi sự cố mạng xảy ra, việc truy vết cực kỳ chậm.

Khuyến nghị kiểm thử trước mùa cao điểm

• Test scale node + rollout đồng thời.
• Test preemption + autoscaling + image pull.
• Test mất node hàng loạt ở một zone.
• Đo recovery time thực tế và so sánh với SLO.

Kiểm thử phải mô phỏng hành vi tổng hợp, không chỉ từng thành phần riêng lẻ.

Dashboard tối thiểu cho chương này

• Pod IP utilization theo range.
• Node bootstrap time p50/p95.
• Pod startup latency p50/p95 theo node pool.
• Image pull error rate theo registry.
• Disk utilization/inode utilization theo node pool.

Quy tắc thiết kế phòng ngừa cạn IP

• Dự phòng đủ cho tăng trưởng + surge/blue-green + incident headroom.
• Tránh subnet quá nhỏ chỉ vì “hiện tại chưa cần nhiều”.
• Mỗi quyết định maxPodsPerNode phải đi kèm cập nhật capacity model.

Bài học thực chiến

• Cạn IP thường đến chậm nhưng bùng nổ nhanh khi cluster mở rộng.
• Nút cổ chai I/O thường chỉ lộ rõ trong sự cố khôi phục.
• Capacity planning là bài toán liên phòng ban: network, platform, app teams.

References bổ sung

• GKE network overview
• Storage options for GKE
• Compute Engine local SSD

FAQ thực chiến

Làm sao biết cluster sắp cạn Pod IP trước khi xảy ra incident?

Cần theo dõi liên tục mức sử dụng secondary range và dự báo theo tốc độ tăng node/pod. Khi mức sử dụng vượt ngưỡng an toàn nội bộ, phải có cảnh báo và kế hoạch mở rộng range trước.

Có nên tăng maxPodsPerNode để giảm số node và tiết kiệm chi phí?

Chỉ nên làm khi đã kiểm tra đầy đủ giới hạn IP, hiệu năng kubelet/runtime và profile ứng dụng. Mật độ quá cao có thể làm node trở thành điểm nghẽn lớn khi có sự cố.

Local SSD có thay thế được Persistent Disk không?

Không. Local SSD tối ưu hiệu năng tạm thời, không phải lớp lưu trữ bền vững mặc định. Dữ liệu nghiệp vụ quan trọng vẫn phải có replication hoặc storage bền bên ngoài node.

Vì sao pod startup chậm dù CPU node còn rảnh?

Thường do bottleneck I/O hoặc network pull path: disk chậm, image lớn, registry chậm, hoặc pull concurrency quá cao.

Checklist capacity drill cho môi trường production

Drill 1: Scale burst

• Tăng số replica diện rộng trong thời gian ngắn.
• Quan sát tốc độ tạo node/pod và tỷ lệ thành công.
• Kiểm tra có lỗi cấp phát Pod IP không.

Drill 2: Rolling restart quy mô lớn

• Khởi động lại đồng thời nhiều deployment trọng yếu.
• Quan sát image pull latency và disk pressure.
• Đo thời gian phục hồi về trạng thái ổn định.

Drill 3: Mất node theo cụm

• Giả lập mất nhiều node trong cùng zone.
• Quan sát autoscaler, scheduling và readiness.
• Xác minh Pod CIDR headroom có đủ cho kịch bản xấu.

Drill 4: Kết hợp scale + deploy

• Chạy rollout trong lúc autoscaler đang mở rộng.
• Theo dõi bottleneck registry/disk/network path.
• Đánh giá mức ảnh hưởng tới SLO ở traffic thật.

Giá trị của drill định kỳ

Không có drill, capacity planning chỉ là giả định. Có drill định kỳ, team sẽ phát hiện sớm giới hạn ẩn của hệ thống trước khi người dùng cuối nhìn thấy lỗi.

Phụ lục bài toán dự báo tăng trưởng

Để dự báo đúng, nên chia ba tốc độ tăng riêng:

• Tăng service count.
• Tăng replica trung bình mỗi service.
• Tăng tần suất rollout và cold start.

Tổng hợp ba tốc độ này sẽ cho dự báo gần thực tế hơn nhiều so với giả định tuyến tính theo số node.

Ngoài ra nên theo dõi tỷ lệ “pod churn” hàng ngày. Pod churn cao nghĩa là hệ thống thường xuyên khởi tạo lại pod, kéo theo áp lực image pull và I/O tăng đáng kể. Nếu không tính chỉ số này, kế hoạch boot disk thường bị thiếu.

Một cách thực dụng là xây “capacity envelope” gồm ba mức:

• Bình thường.
• Giờ cao điểm.
• Sự cố + nâng cấp đồng thời.

Mọi quyết định CIDR và disk profile nên chịu được ít nhất mức thứ hai, và có kế hoạch ứng phó cho mức thứ ba.

Ghi chú triển khai theo mùa cao điểm

Trước mùa cao điểm, nên khóa sớm các thay đổi lớn về maxPodsPerNode, Pod CIDR và disk profile để tránh biến động kép. Tập trung vào kiểm thử phục hồi và theo dõi headroom. Trong mùa cao điểm, ưu tiên ổn định hơn tối ưu nhỏ lẻ.

Sau mùa cao điểm, tổng kết lại các ngưỡng đã dùng, điều chỉnh capacity envelope và cập nhật kế hoạch mở rộng ranges cho chu kỳ tiếp theo. Cách làm này giúp tổ chức chủ động thay vì phản ứng muộn khi tài nguyên cạn.

Kết luận mở rộng cho năng lực capacity

Một cluster khỏe không phải cluster dùng hết tài nguyên, mà là cluster còn khoảng đệm đúng lúc cần. Đệm đó bao gồm đệm IP, đệm I/O và đệm thời gian khởi động. Khi ba loại đệm được theo dõi và cập nhật định kỳ, phần lớn sự cố mở rộng quy mô sẽ được phát hiện sớm và xử lý trước khi chạm người dùng.

Nhắc lại nguyên tắc then chốt

Thiết kế capacity phải đi trước sự cố, không đi sau sự cố. Mỗi thay đổi lớn về mật độ pod, chiến lược rollout hoặc hồ sơ image cần được phản ánh lại vào mô hình IP và I/O. Nếu quy trình này bị bỏ qua, hệ thống sẽ tích lũy rủi ro âm thầm và bùng nổ ở thời điểm mở rộng mạnh nhất.

Việc duy trì review capacity định kỳ sẽ giúp team luôn đi trước nhu cầu tăng trưởng thay vì chạy theo xử lý hậu quả.

Phần mở rộng này nhấn mạnh rằng mọi quyết định về disk, Pod CIDR và mật độ pod đều cần được kiểm chứng bằng dữ liệu vận hành thực, không nên dựa trên giả định tĩnh.