Persistent Storage: PV, PVC, and StorageClass

Trong Kubernetes, container được thiết kế để "sinh ra và chết đi" (ephemeral). Nhưng dữ liệu của doanh nghiệp (Database, Assets) thì cần phải "bất tử". Module này sẽ giải quyết bài toán lưu trữ dữ liệu bền vững (Persistent Storage).

1. The Ephemeral Trap (Cái bẫy phù du)

Hãy khắc cốt ghi tâm câu thần chú này:

"Data inside a container dies with the container."

Nếu bạn chạy một MySQL Container và không cấu hình Volume, mọi dữ liệu user đăng ký sẽ được lưu trong lớp writable layer của container. 💀 Kịch bản thảm họa: Pod bị crash -> Kubernetes restart Pod mới (từ image gốc) -> Toàn bộ dữ liệu user BIẾN MẤT vĩnh viễn.

👉 Để tránh thảm họa này, chúng ta cần lưu dữ liệu ra ngoài vòng đời của Pod.

2. The Trio Architecture (Bộ ba quyền lực)

Kubernetes tách biệt việc "Yêu cầu lưu trữ" (Dev) và "Cung cấp lưu trữ" (Ops/Automated) thông qua một lớp tri-tượng (abstraction layer) cực kỳ thông minh.

Hãy tưởng tượng việc xin cấp ổ cứng giống như đi mua hàng:

Kubernetes Concept	Analogy (Phép ẩn dụ)	Vai trò
StorageClass (SC)	🏭 The Factory / Menu	Nơi định nghĩa "loại hàng" (SSD Gold, HDD Silver) và "nhà máy sản xuất" (AWS EBS, Google Disk).
PersistentVolumeClaim (PVC)	🎫 The Order Form / Ticket	Tờ phiếu yêu cầu của Developer: "Cho tôi 10GB loại Gold".
PersistentVolume (PV)	📦 The Delivered Package	Ổ cứng vật lý thực tế đã được đóng gói và giao đến cluster.

Luồng hoạt động:

1. Dev tạo một tờ phiếu (PVC) xin 10GB.
2. K8s cầm tờ phiếu đó, nhìn xem cần loại hàng nào (StorageClass).
3. K8s gọi xuống hạ tầng (Cloud/On-prem) để tạo ổ cứng thật (PV) và gắn vào PVC.
4. Pod sử dụng PVC như một cái USB để lưu dữ liệu.

3. Dynamic Provisioning (The Magic)

Ngày xưa (Static Provisioning), Admin phải tự tay tạo từng cái PV (tạo ổ cứng trên AWS, lấy ID, viết file YAML PV). Rất cực khổ! 😫

Ngày nay (Dynamic Provisioning), mọi thứ là tự động:

1. Admin chỉ cần tạo StorageClass (The Factory) một lần duy nhất.
2. Developer tạo PVC (The Ticket).
3. StorageClass tự động gọi API của Cloud Provider (AWS/GCP/Azure) để tạo ổ cứng thật -> Tự tạo PV -> Tự Binding.

Ví dụ PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard # 👉 Chọn "Menu" ở đây

4. Access Modes (Chế độ truy cập)

Khi "gắn" ổ cứng vào Node, chúng ta có các quy tắc vật lý khác nhau:

🧱 ReadWriteOnce (RWO) - Block Storage

• Đặc tính: Chỉ MỘT Node được phép mount tại một thời điểm.
• Lý do: Giống như ổ cứng SATA/SSD vật lý, bạn không thể cắm 1 sợi dây SATA vào 2 máy tính cùng lúc.
• Use Case: Database (MySQL, Postgres), Single-instance App.
• Backend: AWS EBS, Azure Disk, GCE Disk.

🌐 ReadWriteMany (RWX) - File Storage

• Đặc tính: NHIỀU Node có thể mount và ghi cùng lúc.
• Lý do: Giao thức chia sẻ qua mạng (Network File System).
• Use Case: Web Assets (nhiều web server cùng đọc/ghi ảnh), Shared Logs.
• Backend: NFS, AWS EFS, Azure Files.

WARNING

Đừng cố gắng mount AWS EBS (RWO) cho Deployment có 2 Replica chạy trên 2 Node khác nhau. Pod thứ 2 sẽ bị lỗi Multi-Attach Error vì ổ cứng đã bị Node 1 chiếm dụng!

---

Next Step: Module 6: Security Essentials