Cloud Storage FUSE — Object Storage Với File Semantics

Vì sao mount object storage như filesystem là một abstraction nguy hiểm-nhưng-hữu-ích

Cloud Storage là object store: kho key-value của object bất biến, truy cập qua HTTP API (GET, PUT, DELETE theo object key). Nó không phải filesystem — không có thư mục thật, không có inode, không có random write, không có file locking. Cloud Storage FUSE dùng cơ chế FUSE (Filesystem in Userspace) để giả lập một filesystem POSIX trên GCS, cho phép ứng dụng dùng open/read/write/close thay vì gọi API (Cloud Storage FUSE CSI driver).

Đây là một leaky abstraction — nó trông như filesystem nhưng hành xử như object store, và sự khác biệt rò rỉ ra ở đúng những chỗ gây đau: rename thư mục đắt khủng khiếp, append phải rewrite cả object, random write trong file lớn là phản pattern. Hiểu GCS FUSE đúng nghĩa là biết khi nào abstraction này khớp (đọc dữ liệu bất biến, portability) và khi nào nó phản chủ (workload ghi ngẫu nhiên, nhiều thao tác metadata). Dùng đúng, nó là cách tuyệt vời để workload truy cập petabyte dữ liệu với chi phí object storage; dùng sai, nó là nguồn latency và chi phí API khó hiểu.

CSI driver gcsfuse.csi.storage.gke.io được quản lý bởi GKE, tự deploy trên Standard và Autopilot từ GKE 1.24+ (Cloud Storage FUSE CSI driver).

Kiến trúc sidecar: `gke-gcsfuse-sidecar`

Khác mọi CSI driver khác (chạy ở tầng node/controller), Cloud Storage FUSE hoạt động qua một sidecar container tự inject vào Pod. Khi Pod yêu cầu một volume GCS FUSE, CSI driver tự thêm container gke-gcsfuse-sidecar vào Pod; sidecar này chạy tiến trình gcsfuse, mount bucket, và phục vụ filesystem cho các container chính (Cloud Storage FUSE CSI driver).

Vì sao kiến trúc sidecar quan trọng:

Không cần privileged. FUSE truyền thống cần quyền cao để mount. Bằng cách chạy gcsfuse trong sidecar do GKE quản lý (dùng native sidecar — init container với restartPolicy: Always), driver tránh phải cấp privileged cho container ứng dụng — một lợi thế bảo mật lớn (Cloud Storage FUSE CSI driver).
Vòng đời gắn với Pod. Sidecar sống cùng Pod; mount tồn tại suốt đời Pod. Điều này có hệ quả với Job/batch: trước khi có native sidecar, sidecar gcsfuse không tự kết thúc làm Job "treo" không complete; native sidecar (init container restartable) giải quyết bằng cách kết thúc đúng thứ tự khi container chính xong.
Tài nguyên sidecar tính vào Pod. Sidecar tiêu CPU/memory (đặc biệt khi bật cache lớn) — phải cấp resource cho nó qua annotation, nếu không cache bị giới hạn hoặc Pod bị OOM. Đây là điểm tuning quan trọng (phần sau).

Yêu cầu Workload Identity và quyền truy cập

Cloud Storage FUSE bắt buộc Workload Identity Federation for GKE và GKE metadata server (Cloud Storage FUSE CSI driver). Pod truy cập bucket bằng danh tính của Kubernetes ServiceAccount được map tới một IAM principal có quyền trên bucket (Chương 13) — không dùng key dài hạn. Đây là mô hình đúng: quyền truy cập GCS được kiểm soát qua IAM, audit được, xoay vòng tự động.

Thêm một ràng buộc cho workload read-write: cần uniform bucket-level access trên bucket khi dùng Workload Identity (Cloud Storage FUSE CSI driver) — nghĩa là IAM-only, không dùng ACL per-object. Đây là best practice bảo mật GCS nói chung, nên thường không phải ràng buộc bất tiện.

yaml

apiVersion: v1
kind: Pod
metadata:
  name: training-job
  annotations:
    gke-gcsfuse/volumes: "true"                       # bật injection sidecar
    gke-gcsfuse/cpu-limit: "2"                          # cấp resource cho sidecar
    gke-gcsfuse/memory-limit: "8Gi"
    gke-gcsfuse/ephemeral-storage-limit: "100Gi"       # cho file cache
spec:
  serviceAccountName: ml-sa                            # map Workload Identity
  containers:
  - name: trainer
    image: my-trainer
    volumeMounts:
    - name: dataset
      mountPath: /data
      readOnly: true
  volumes:
  - name: dataset
    csi:
      driver: gcsfuse.csi.storage.gke.io
      readOnly: true
      volumeAttributes:
        bucketName: my-training-data
        mountOptions: "implicit-dirs"
        fileCacheCapacity: "100Gi"

Performance tuning: cache là tất cả

Hiệu năng GCS FUSE quyết định gần như hoàn toàn bởi cache. Không cache, mỗi lần đọc file là một GCS API call qua network — latency cao và tốn phí API (mỗi operation tính tiền). Với cache, đọc lặp lại trở thành đọc local — nhanh và miễn phí API. Ba tầng cache cần tune (Cloud Storage FUSE CSI driver):

File cache. Cache nội dung file đã đọc lên storage local — Local SSD, Persistent Disk, hoặc RAM disk. Đây là tuning có tác động lớn nhất cho workload đọc lặp (training nhiều epoch trên cùng dataset): epoch đầu tải từ GCS, các epoch sau đọc từ file cache local — nhanh gấp nhiều lần. Đặt file cache trên Local SSD (file 5) cho tốc độ NVMe mà dữ liệu gốc vẫn an toàn trên bucket. Dung lượng cache cấu hình qua fileCacheCapacity; phải đủ lớn để chứa working set, và phải cấp ephemeral-storage cho sidecar tương ứng.

Metadata/stat cache. Cache metadata file (kích thước, thời gian, tồn tại) — bật mặc định, giảm số API call lặp lại để stat file (Cloud Storage FUSE CSI driver). Quan trọng vì nhiều workload (đặc biệt framework ML) gọi stat rất nhiều lần khi liệt kê dataset. Tune TTL theo độ "tươi" cần thiết: TTL cao giảm API call nhưng có thể thấy metadata stale nếu bucket đổi từ ngoài.

Parallel downloads. Tải đa luồng một file lớn từ GCS — đặc biệt hữu ích cho nạp model weight >1GB, nơi tải tuần tự là bottleneck (Cloud Storage FUSE CSI driver). Bật parallel downloads rút ngắn thời gian cold-load model đáng kể cho inference khởi động.

Quy luật tuning: bắt đầu từ file cache trên Local SSD đủ lớn cho working set, bật metadata cache với TTL hợp lý, và parallel downloads nếu nạp file lớn. Cấp đủ resource cho sidecar (CPU/memory/ephemeral-storage) qua annotation — đây là lỗi tune phổ biến nhất: quên cấp ephemeral-storage cho sidecar nên file cache không hoạt động.

Ngữ nghĩa khác POSIX: những cái bẫy của leaky abstraction

GCS FUSE "có sự khác biệt về hiệu năng, availability, ủy quyền và ngữ nghĩa so với một POSIX filesystem" (Cloud Storage FUSE CSI driver). Các khác biệt quan trọng nhất:

Không có thư mục thật. GCS phẳng; "thư mục" là tiền tố trong tên object. mountOptions: implicit-dirs cho phép FUSE suy ra thư mục từ tiền tố, nhưng liệt kê thư mục lớn là tốn kém (phải list object). Tránh cấu trúc nhiều thư mục lồng sâu với liệt kê thường xuyên.
Rename cực đắt. Đổi tên file/thư mục trong filesystem thường là thao tác metadata tức thì; trên GCS nó là copy + delete object (rename thư mục = copy + delete mọi object dưới nó). Một thao tác mv thư mục lớn có thể mất rất lâu và tốn nhiều API call. Tránh pattern ghi-file-tạm-rồi-rename phổ biến trong nhiều app.
Append/random write phản pattern. Object GCS bất biến; sửa một byte giữa file lớn nghĩa là rewrite cả object. GCS FUSE không phù hợp cho workload ghi ngẫu nhiên (database, file log append liên tục). Nó hợp cho ghi tuần tự file mới và đọc.
Không snapshot/clone/expansion qua CSI. Khác PD/Filestore, GCS FUSE không hỗ trợ volume snapshot, cloning, hay expansion (Cloud Storage FUSE CSI driver) — vì "dung lượng" là cả bucket, không phải volume cố định. Backup/versioning làm ở tầng GCS (object versioning, lifecycle).
Không hỗ trợ GKE Sandbox, và trước GKE 1.33.3-gke.1226000 không hỗ trợ Pod hostNetwork (Cloud Storage FUSE CSI driver).

Tổng kết: GCS FUSE là công cụ tuyệt vời cho đọc dữ liệu bất biến và ghi tuần tự file mới; là công cụ tệ cho workload giả định filesystem POSIX đầy đủ với random write, rename, locking. Khớp đúng use case là tất cả.

Use case đúng

Dữ liệu training AI/ML read-heavy. Mount dataset TB-scale từ bucket, file cache trên Local SSD cho đọc lặp qua epoch. Đây là use case chủ đạo và GCS FUSE tỏa sáng ở đây (Cloud Storage FUSE CSI driver).
Nạp model weight bất biến. Parallel downloads tải nhanh model lớn lúc khởi động inference.
Dữ liệu unstructured chia sẻ, portability. Nhiều Pod đọc cùng dataset từ bucket (ROX/RWX semantics qua FUSE) mà không cần copy.
Ghi output/artifact tuần tự. Job ghi kết quả (file mới) ra bucket — tuần tự, không rename, không random write.

So sánh với các lựa chọn shared storage

Tiêu chí	Cloud Storage FUSE	Filestore (NFS)	Hyperdisk ML (ROX)
Bản chất	Object store giả lập FS	NFS filesystem thật	Block read-only multi-attach
Ghi đồng thời (RWX)	Có (hạn chế ngữ nghĩa)	Có (đầy đủ POSIX)	Không (read-only)
Random write	Phản pattern	Tốt	N/A
Đọc song song quy mô lớn	Tốt (cache)	Giới hạn throughput instance	Rất tốt
Dung lượng	Gần vô hạn (bucket)	Theo instance	Theo disk
Chi phí	Thấp (object)	Cao	Trung bình
Snapshot/clone	Không (versioning GCS)	Có	Có (snapshot)

Quy tắc: đọc dữ liệu bất biến quy mô lớn, chi phí thấp → GCS FUSE; nhiều writer POSIX thật → Filestore; đọc song song latency thấp nhất cho model → Hyperdisk ML.

Real-world scenario: pipeline training kết hợp ba storage

Một training pipeline điển hình minh họa GCS FUSE đúng chỗ:

Dataset gốc (50TB) trên Cloud Storage, mount vào training Pod qua GCS FUSE với file cache 200GB trên Local SSD và parallel downloads. Epoch đầu warm cache; epoch sau đọc local — throughput cao, chi phí API thấp.
Checkpoint trung gian ghi tuần tự (file mới mỗi step) ra một bucket khác qua GCS FUSE — không rename, không random write, khớp ngữ nghĩa.
Scratch/shuffle buffer trên emptyDir Local SSD (file 5) — không qua GCS FUSE vì cần random write tốc độ cao.

Mỗi loại I/O đi qua đúng storage hợp ngữ nghĩa của nó. Đặt random-write scratch lên GCS FUSE sẽ chậm khủng khiếp; đặt dataset 50TB lên PD sẽ đắt khủng khiếp. Khớp đúng abstraction với access pattern là bài học cốt lõi.

Common mistakes / anti-patterns

Dùng GCS FUSE cho workload random-write (database, log append). Mỗi sửa đổi rewrite cả object → cực chậm. Phòng tránh: GCS FUSE chỉ cho đọc + ghi tuần tự file mới; database dùng PD/Hyperdisk.
Quên cấp resource (ephemeral-storage/memory) cho sidecar. File cache không hoạt động hoặc Pod OOM. Hệ quả: hiệu năng tệ không lý giải, hoặc Pod crash. Phòng tránh: đặt gke-gcsfuse/*-limit annotation đủ cho cache.
Pattern ghi-tạm-rồi-rename trên GCS FUSE. Rename = copy + delete, cực đắt. Phòng tránh: ghi thẳng tên cuối; tránh rename thư mục.
Liệt kê thư mục lớn thường xuyên. Mỗi list là API call tốn kém. Phòng tránh: thiết kế cấu trúc phẳng hơn, dùng metadata cache, giảm tần suất list.
Tưởng có snapshot/backup tự động như PD. GCS FUSE không snapshot qua CSI. Phòng tránh: dùng object versioning + lifecycle ở tầng GCS cho bảo vệ dữ liệu.
Bỏ qua chi phí API ở scale. Nhiều operation không cache = hóa đơn GCS operations lớn. Phòng tránh: tune cache để giảm API call; monitor chi phí operations.

Official references

Cloud Storage FUSE CSI driver — cơ chế FUSE, sidecar, Workload Identity, cache, giới hạn.
Cloud Storage FUSE documentation — ngữ nghĩa filesystem, khác biệt POSIX.
Tune GCS FUSE performance — file cache, parallel downloads, metadata cache.
Workload Identity Federation for GKE — yêu cầu danh tính (Chương 13).
Cloud Storage uniform bucket-level access — yêu cầu cho read-write workload.

Cloud Storage FUSE — Object Storage Với File Semantics ​

Vì sao mount object storage như filesystem là một abstraction nguy hiểm-nhưng-hữu-ích ​

Kiến trúc sidecar: gke-gcsfuse-sidecar ​

Yêu cầu Workload Identity và quyền truy cập ​

Performance tuning: cache là tất cả ​

Ngữ nghĩa khác POSIX: những cái bẫy của leaky abstraction ​

Use case đúng ​

So sánh với các lựa chọn shared storage ​

Real-world scenario: pipeline training kết hợp ba storage ​

Common mistakes / anti-patterns ​

Official references ​