Chương 11: GKE Storage — PV/PVC, StorageClasses & CSI Drivers

Vì sao chương này quyết định sự sống còn của dữ liệu

Storage là tầng duy nhất trong toàn bộ stack GKE mà một sai lầm cấu hình không chỉ gây outage — nó gây mất dữ liệu vĩnh viễn. Một Pod chết thì scheduler tạo lại Pod khác; một node hỏng thì Cluster Autoscaler thay node mới; nhưng một reclaimPolicy: Delete đặt sai chỗ, một Local SSD coi nhầm là persistent, hay một Regional PD failover không cấu hình đúng — và dữ liệu biến mất không lấy lại được. Đây là lý do storage là chương đòi hỏi sự chính xác cao nhất: bạn không "rollback" được một disk đã bị xóa.

Ba kiểu thất bại storage phổ biến nhất ở quy mô production, và cả ba đều bắt nguồn từ hiểu sai mô hình:

Mất dữ liệu âm thầm vì nhầm ephemeral với persistent. Đội ngũ dùng emptyDir hoặc Local SSD cho dữ liệu cần bền vững, vì "nó nhanh và đang chạy ổn". Rồi một lần node auto-repair, node upgrade, hoặc Spot preemption xảy ra — và toàn bộ dữ liệu trên node đó bốc hơi. Local SSD không survive qua node recreation, đây là tài liệu hóa rõ ràng (GKE storage overview). Đây là failure mode tốn kém nhất vì nó không báo lỗi lúc cấu hình; nó chỉ phát nổ vào đúng lúc tệ nhất.
Pod stuck Pending vì volume không bind được. PVC yêu cầu một StorageClass với volumeBindingMode: Immediate, disk được tạo ở zone A, nhưng scheduler lại muốn đặt Pod ở zone B vì lý do affinity/capacity — và Pod không bao giờ chạy được vì zonal PD không thể attach cross-zone. Hiểu sai tương tác giữa volume binding mode và scheduler là nguyên nhân hàng đầu của Pod stateful kẹt Pending.
Bottleneck I/O không nhìn thấy được. Database chạy chậm, latency p99 tăng, nhưng CPU và memory đều thấp. Nguyên nhân thật là disk: chọn pd-standard (HDD) cho workload random-IOPS, hoặc dung lượng PD quá nhỏ nên IOPS bị giới hạn theo công thức scale-theo-GiB. Trên GCP, IOPS và throughput của Persistent Disk gắn với dung lượng và loại disk — một sự thật mà người đến từ on-prem (nơi IOPS gắn với phần cứng RAID) thường bỏ qua.

Điểm mấu chốt mà chương này nhấn mạnh xuyên suốt: storage trên GKE là một chuỗi abstraction xếp tầng, và mỗi tầng có một failure domain và một performance ceiling riêng. Phía trên là abstraction Kubernetes thuần (Volume, PersistentVolume, PersistentVolumeClaim, StorageClass). Ở giữa là CSI driver — cầu nối dịch yêu cầu Kubernetes thành lời gọi GCP API. Phía dưới là tài nguyên GCP thật (Persistent Disk, Hyperdisk, Filestore instance, GCS bucket) với các đặc tính vật lý, giới hạn attach, mô hình replication, và bảng giá riêng. Hiểu đúng storage nghĩa là biết một yêu cầu PVC 100Gi đi qua những tầng nào, tầng nào quyết định độ bền, tầng nào quyết định hiệu năng, và tầng nào quyết định hóa đơn.

Điều kiện tiên quyết

Chương 6 (Node Lifecycle & Pool Management): vòng đời node quyết định vòng đời của storage gắn với node. Khi nào node bị recreate (auto-repair, upgrade, Spot preemption) là khi nào ephemeral storage mất, và là khi nào một PD cần detach khỏi node cũ rồi reattach vào node mới. Boot disk, Local SSD provisioning đã đề cập ở Chương 6 là nền cho chương này.
Chương 8 (GKE Scheduler): storage và scheduling khóa chặt vào nhau qua plugin VolumeBinding. Một zonal disk ràng buộc Pod vào một zone; WaitForFirstConsumer đảo ngược thứ tự để scheduler quyết định trước rồi disk mới được tạo đúng zone. Phải hiểu Filter/Score, topology, nodeAffinity để hiểu volume binding.
Kubernetes storage concepts: Volume, PV, PVC, StorageClass, access modes là vốn nền. Chương này không dạy lại định nghĩa cơ bản — nó đi sâu vào cơ chế và hệ quả production của chúng trên GKE.
Mô hình Persistent Disk / Hyperdisk của Compute Engine: vì CSI driver chỉ là lớp dịch, mọi giới hạn của PD/Hyperdisk ở tầng Compute Engine (per-VM attach limit, IOPS theo dung lượng, machine series support) đều áp lên GKE.

Mức độ sâu

5/5 — Chương đi tới mức công thức scale IOPS/throughput theo dung lượng của từng loại PD, cơ chế attach/detach và per-node disk limit, mô hình replication đồng bộ hai-zone của Regional PD và Hyperdisk Balanced HA, kiến trúc sidecar gke-gcsfuse-sidecar của Cloud Storage FUSE và các tham số cache, mô hình erasure-coding 2+1 và "mean time to data loss hai tháng" của Parallelstore, cơ chế force-attach của Stateful HA Operator với timeout afterNodeUnreachable, và sự khác biệt giữa block-device CSI và NFS CSI ở tầng kernel. Mọi tuyên bố kỹ thuật đối chiếu trực tiếp tài liệu Kubernetes và Google Cloud.

Cấu trúc chapter

1. Volume Types & Storage Taxonomy — Bản Đồ Toàn Cảnh

Phân loại toàn bộ thế giới storage của GKE để chọn đúng công cụ.

Kubernetes volume types: emptyDir, configMap, secret, projected, downwardAPI, hostPath, PVC — cái nào ephemeral, cái nào persistent
Phân loại storage GCP theo bản chất vật lý: Block (PD, Hyperdisk), File (Filestore, Parallelstore, Managed Lustre), Object (Cloud Storage FUSE)
Access modes: ReadWriteOnce (RWO), ReadOnlyMany (ROX), ReadWriteMany (RWX), ReadWriteOncePod (RWOP) — ngữ nghĩa "node" vs "pod" và vì sao hiểu sai gây data corruption
Khung quyết định: ma trận chọn storage theo access pattern, độ bền, latency, throughput, chi phí

2. PV/PVC Lifecycle & Dynamic Provisioning

Vòng đời đầy đủ của một volume và cơ chế tự động cấp phát.

Vòng đời PV/PVC: provisioning → binding → mounting → releasing → reclaiming
reclaimPolicy: Delete vs Retain — đâu là nơi mất dữ liệu xảy ra
Dynamic provisioning end-to-end: PVC → StorageClass → CSI driver → GCP API → PV
Static provisioning: khi nào và vì sao vẫn cần
Volume binding modes: Immediate vs WaitForFirstConsumer — vì sao WaitForFirstConsumer là mặc định đúng cho zonal disk
allowedTopologies, tương tác với scheduler, các StorageClass mặc định của GKE (standard-rwo, premium-rwo)

3. Persistent Disk CSI — Block Storage Nền Tảng

CSI driver block storage phổ biến nhất và toàn bộ cơ chế của nó.

PD types: pd-standard, pd-balanced, pd-ssd, pd-extreme — IOPS/throughput scale theo dung lượng, trade-offs
Attach/detach mechanics, per-node disk attach limit, hệ quả lên bin-packing
Giới hạn ReadWriteMany: vì sao block device không thể RWX an toàn, ROX multi-reader
Regional PD: replication đồng bộ hai-zone, failover, chi phí gấp đôi
Volume snapshots, cloning, online expansion
Stateful HA Operator: force-attach PD khi node hỏng, timeout afterNodeUnreachable

4. Hyperdisk — Block Storage Thế Hệ Mới

Tách rời hiệu năng khỏi dung lượng và mô hình Storage Pools.

Vì sao Hyperdisk khác PD về bản chất: provision IOPS/throughput độc lập với dung lượng
Năm loại: hyperdisk-balanced, hyperdisk-extreme, hyperdisk-throughput, hyperdisk-ml, hyperdisk-balanced-ha — profile hiệu năng và use case
Per-VM performance limit: tổng IOPS/throughput của mọi disk attach bị giới hạn theo machine type
Hyperdisk ML: multi-attach ROX cho hàng nghìn node, tăng tốc đọc song song model weight
Hyperdisk Storage Pools: thin provisioning, chia sẻ dung lượng và hiệu năng giữa nhiều disk
VolumeAttributesClass: đổi hiệu năng động không cần tạo lại disk

5. Local SSD & Ephemeral Storage — Tốc Độ Đổi Lấy Độ Bền

Storage nhanh nhất nhưng nguy hiểm nhất nếu hiểu sai.

Local SSD: physical NVMe gắn trực tiếp node, latency thấp nhất
emptyDir và ephemeral storage: gắn với vòng đời Pod
Quy luật vàng: dữ liệu Local SSD không survive node recreation (auto-repair/upgrade/preemption)
Provisioning: --ephemeral-storage-local-ssd, raw block local PV
Use case đúng: cache nóng, scratch space cho AI/ML, layer trước GCS — và các anti-pattern chết người

6. Filestore CSI — Shared NFS cho RWX

File storage được quản lý cho workload đa-reader-writer.

Khi nào cần Filestore: RWX thật sự, nhiều Pod ghi đồng thời
Service tiers: BASIC_HDD, BASIC_SSD, ZONAL, ENTERPRISE (Regional) — capacity, hiệu năng, HA
Filestore CSI: dynamic provisioning, VolumeAttributesClass cho scale hiệu năng động
Multishares for GKE: nhiều PVC nhỏ từ một instance, tối ưu chi phí
Volume snapshots → Filestore backups
NFS tradeoffs: latency, consistency, file locking ở tầng network filesystem

7. Cloud Storage FUSE — Object Storage Với File Semantics

Mount GCS bucket như filesystem, và những cái bẫy của nó.

Cơ chế FUSE: filesystem trong userspace, dịch file I/O thành GCS API
Kiến trúc sidecar: gke-gcsfuse-sidecar tự inject, không cần privileged
Yêu cầu Workload Identity, uniform bucket-level access
Performance tuning: file cache (Local SSD/PD/RAM), metadata/stat cache, parallel downloads cho model >1GB
Ngữ nghĩa khác POSIX: không phải filesystem thật, các thao tác đắt (rename, append), không snapshot/clone
Use case: dữ liệu training AI/ML read-heavy, dữ liệu bất biến, portability

8. Parallelstore & Managed Lustre — Filesystem Song Song cho AI/ML

Storage throughput cực cao cho training quy mô lớn.

Parallelstore: filesystem phân tán nền DAOS, Local SSD + erasure coding 2+1, sub-millisecond latency, tới 1 TB/s
Managed Lustre: Lustre được quản lý cho HPC/AI throughput cao, RWX bền vững
Mô hình "temporary storage" của Parallelstore: mean-time-to-data-loss ~2 tháng, không dùng làm nguồn dữ liệu duy nhất
CSI driver, access modes (RWX/ROX/RWO), tích hợp với GCS để nạp/đẩy dữ liệu
So sánh: Parallelstore vs Lustre vs Filestore vs GCS FUSE — chọn theo metadata IOPS, throughput, độ bền

9. StatefulSets, Volume Expansion & Backup for GKE

Vận hành stateful workload, mở rộng dung lượng và bảo vệ dữ liệu.

StatefulSet + storage: volumeClaimTemplates, Pod identity bền vững, PVC không bị xóa khi scale-down
Ordered update, mối quan hệ Pod-PVC-PV theo ordinal
Volume expansion: online resize (không downtime) vs cold resize, giới hạn chỉ tăng không giảm
Backup for GKE: backup cả config (Kubernetes manifest) lẫn volume (PD snapshot), BackupPlan/Backup/RestorePlan/Restore
Vì sao Backup for GKE khác PD snapshot thuần: nhất quán application-level, cross-project/region, không backup Filestore
Snapshot lifecycle, retention, chiến lược DR

Bản đồ tinh thần: ba tầng abstraction của storage

Trước khi đi vào từng file, hãy ghim mô hình ba tầng này. Nó là khung tham chiếu cho mọi quyết định debug và thiết kế trong chương.

Tầng	Thành phần	Vai trò	Ai quản lý
Kubernetes abstraction	Volume, PV, PVC, StorageClass, VolumeSnapshot	Khai báo nhu cầu, tách rời app khỏi storage cụ thể	Bạn (qua YAML)
CSI driver	`pd.csi.storage.gke.io`, `filestore.csi.storage.gke.io`, `gcsfuse.csi.storage.gke.io`, Parallelstore CSI	Dịch yêu cầu K8s thành GCP API, mount/unmount, attach/detach	GKE (managed add-on)
Tài nguyên GCP	Persistent Disk, Hyperdisk, Filestore instance, GCS bucket, Parallelstore instance	Lưu trữ vật lý, replication, hiệu năng, billing	Google (tài nguyên có SLA riêng)

Hai quan sát quan trọng từ mô hình này:

CSI driver là lớp dịch, không phải lớp lưu trữ. Mọi giới hạn vật lý đều nằm ở tầng GCP bên dưới: per-VM attach limit là giới hạn của Compute Engine, không phải của Kubernetes; IOPS scale theo dung lượng là đặc tính của PD, không phải của CSI. Khi debug một vấn đề hiệu năng hay attach, phải truy xuống tầng GCP — kubectl describe pv chỉ cho bạn thấy abstraction, còn nguyên nhân gốc thường nằm ở Compute Engine.
Access mode được enforce ở tầng nào quyết định độ an toàn. ReadWriteOnce của một block device được enforce bởi cơ chế attach của Compute Engine (một disk chỉ attach read-write vào một VM). ReadWriteMany của Filestore được enforce bởi NFS server. Cùng một nhãn "RWX" nhưng cơ chế và đảm bảo hoàn toàn khác nhau giữa các loại storage — và nhầm lẫn điều này là nguồn gốc của data corruption.

Khung quyết định chọn storage (tóm tắt)

Đây là ma trận quyết định cốt lõi của chương. Mỗi dòng là một câu hỏi thiết kế thật, file tương ứng đào sâu.

Nhu cầu	Lựa chọn đúng	Vì sao	File
Database single-writer, cần IOPS ổn định	`pd-balanced` / `pd-ssd`, hoặc `hyperdisk-balanced`	RWO, IOPS đủ, chi phí hợp lý	3, 4
Database cần IOPS rất cao, tách hiệu năng khỏi dung lượng	`hyperdisk-extreme` / `hyperdisk-balanced`	Provision IOPS độc lập dung lượng	4
HA database survive zonal failure	Regional PD / `hyperdisk-balanced-ha` + Stateful HA	Replication đồng bộ hai-zone, force-attach	3
Nhiều Pod ghi cùng lúc vào shared filesystem	Filestore (RWX)	NFS server enforce concurrent write	6
Đọc song song dataset training từ hàng nghìn node	`hyperdisk-ml` (ROX) hoặc Parallelstore	Multi-attach read, throughput cực cao	4, 8
Training AI/ML throughput cực cao, metadata IOPS lớn	Parallelstore / Managed Lustre	Filesystem song song chuyên dụng	8
Mount dataset bất biến từ object storage	Cloud Storage FUSE	File semantics trên GCS, file cache	7
Cache nóng / scratch space, chấp nhận mất khi node chết	Local SSD / `emptyDir`	Latency thấp nhất, ephemeral	5
Cấu hình, secret inject vào Pod	`configMap`, `secret`, `projected`	Ephemeral, do API server cấp	1

Năm sai lầm xuyên suốt thường gặp ở cấp chương

Nhầm ephemeral với persistent. Dùng Local SSD hay emptyDir cho dữ liệu cần bền, rồi mất sạch khi node recreate. Quy luật: nếu mất dữ liệu là không chấp nhận được, bắt buộc dùng PD/Hyperdisk/Filestore — những thứ tồn tại độc lập với vòng đời node (file 5, 1).
Để reclaimPolicy mặc định mà không hiểu hệ quả. Dynamic provisioning tạo PV với reclaimPolicy: Delete — xóa PVC là xóa luôn disk và toàn bộ dữ liệu. Với dữ liệu quan trọng, dùng Retain hoặc StorageClass riêng, kèm Backup for GKE (file 2, 9).
Dùng Immediate binding cho zonal disk. Disk được tạo ở zone tùy ý trước khi scheduler quyết định, rồi Pod không đặt được vào zone đó → kẹt Pending vĩnh viễn. WaitForFirstConsumer là mặc định đúng để scheduler quyết định trước (file 2).
Bỏ qua quan hệ IOPS–dung lượng–machine type. Đặt PD quá nhỏ nên IOPS bị bóp; hoặc provision Hyperdisk IOPS cao nhưng machine type không đủ per-VM limit nên không bao giờ đạt được. Hiệu năng disk là bài toán ba biến: loại disk, dung lượng/IOPS provision, và machine type (file 3, 4).
Coi RWX là "bật một flag". Block device (PD/Hyperdisk) không RWX an toàn cho ghi đồng thời — filesystem không phải cluster-aware sẽ corrupt. RWX thật cần Filestore/Parallelstore/Lustre/GCS FUSE, mỗi loại có ngữ nghĩa nhất quán và hiệu năng khác nhau (file 1, 6, 7, 8).

Cross-reference với Google Cloud Architecture Framework

Reliability: chọn đúng độ bền và failure domain cho dữ liệu — Regional PD/Hyperdisk Balanced HA cho zonal resilience, Backup for GKE cho DR (Reliability pillar).
Cost optimization: right-size dung lượng và IOPS, dùng Hyperdisk Storage Pools để chia sẻ công suất, dùng tier Filestore phù hợp, dùng Local SSD/GCS thay vì PD đắt khi hợp lý (Cost optimization pillar).
Performance optimization: khớp profile I/O của workload với loại storage — random IOPS vs throughput tuần tự vs metadata IOPS, và hiểu performance ceiling của từng tầng (Performance pillar).

References chung của chapter

Bảng thuật ngữ then chốt của chương

Thuật ngữ	Ý nghĩa ngắn gọn
PV / PVC	PersistentVolume (tài nguyên thật) / PersistentVolumeClaim (yêu cầu của workload) (file 2)
StorageClass	Khuôn cấu hình để dynamic provisioning tạo PV (file 2)
CSI driver	Lớp dịch yêu cầu K8s thành GCP API (file 2, 3)
`reclaimPolicy`	`Delete`/`Retain` — số phận disk khi xóa PVC (file 2)
`volumeBindingMode`	`Immediate`/`WaitForFirstConsumer` — thời điểm tạo disk (file 2)
RWO / ROX / RWX / RWOP	Bốn access mode, ngữ nghĩa node vs pod (file 1)
Regional PD / Balanced HA	Block storage replication đồng bộ hai-zone (file 3, 4)
Hyperdisk	Block storage tách hiệu năng khỏi dung lượng (file 4)
Storage Pool	Chia sẻ dung lượng/hiệu năng giữa nhiều Hyperdisk (file 4)
Stateful HA Operator	Force-attach PD khi node hỏng (file 3)
`gke-gcsfuse-sidecar`	Sidecar container của Cloud Storage FUSE (file 7)
Multishares	Nhiều PVC nhỏ từ một Filestore instance (file 6)
Parallelstore	Filesystem song song nền DAOS cho AI/ML (file 8)
Backup for GKE	Backup config + volume, application-consistent (file 9)

Kết luận của chapter

Storage là nơi triết lý "cattle not pets" của Kubernetes va chạm với thực tế cứng đầu rằng dữ liệu là pet. Pod, node, IP — tất cả đều thay thế được; nhưng byte dữ liệu thì không. Mục tiêu của chương này là cho bạn một mô hình tinh thần chính xác về ba tầng abstraction và về failure domain của từng loại storage, để mỗi khi đặt một PVC, bạn biết chính xác: dữ liệu này sống ở đâu, survive được sự cố gì, đạt hiệu năng tối đa bao nhiêu, và tốn bao nhiêu.

Cách dùng chương hiệu quả nhất là biến mỗi file thành một chuẩn quyết định: chuẩn chọn loại storage theo access pattern và độ bền (file 1), chuẩn cấu hình lifecycle để không mất dữ liệu (file 2), chuẩn chọn và tune block storage (file 3, 4, 5), chuẩn cho shared filesystem và AI/ML (file 6, 7, 8), và chuẩn vận hành stateful kèm backup (file 9). Khi đó storage chuyển từ "thứ cấu hình một lần rồi cầu cho nó đừng hỏng" thành một hệ thống có thể suy luận về độ bền, hiệu năng và chi phí một cách kỷ luật.

Chương 11: GKE Storage — PV/PVC, StorageClasses & CSI Drivers ​

Vì sao chương này quyết định sự sống còn của dữ liệu ​

Điều kiện tiên quyết ​

Mức độ sâu ​

Cấu trúc chapter ​

Bản đồ tinh thần: ba tầng abstraction của storage ​

Khung quyết định chọn storage (tóm tắt) ​

Năm sai lầm xuyên suốt thường gặp ở cấp chương ​

Cross-reference với Google Cloud Architecture Framework ​

References chung của chapter ​

Bảng thuật ngữ then chốt của chương ​

Kết luận của chapter ​