StatefulSet, PersistentVolume/Claim là gì, và bạn chạy workload stateful trên Kubernetes ra sao?

Question

IT Interview Practice · Accepted Answer

Workload stateful (cơ sở dữ liệu, hàng đợi, kho phân cụm) cần **danh tính ổn định** và **lưu trữ bền vững** — những thứ Deployment không cung cấp. Một **StatefulSet** cho các Pod tên ổn định và vòng đời có thứ tự; **PersistentVolume (PV)** và **PersistentVolumeClaim (PVC)** cho chúng lưu trữ sống lâu hơn Pod.

## Vì sao Deployment chưa đủ

```text
Pod của Deployment CÓ THỂ THAY THẾ LẪN NHAU: tên ngẫu nhiên (web-7f9-abc), thứ tự bất kỳ,
không chia sẻ gì theo từng Pod. Điều đó hoàn hảo cho app stateless — nhưng một replica DB cần:
  → một DANH TÍNH mạng ỔN ĐỊNH (để các peer tìm thấy nhau: db-0, db-1, db-2)
  → ĐĨA bền vững RIÊNG sống sót qua restart/dời lịch
  → khởi động/scale CÓ THỨ TỰ, có kiểm soát (dựng db-0 trước db-1)
StatefulSet cung cấp chính xác những điều này.
```

## Các đảm bảo của StatefulSet

```text
TÊN ổn định      → pod-0, pod-1, pod-2 (theo thứ tự, không ngẫu nhiên)
DNS ổn định      → db-0.db.default.svc... qua một headless Service
LƯU TRỮ ổn định  → mỗi Pod có PVC RIÊNG (db-0 giữ đĩa của nó qua các lần restart)
Thao tác có thứ tự → tạo/scale lên theo thứ tự 0,1,2…; chấm dứt theo thứ tự ngược
```

## Lưu trữ bền vững: PV, PVC, StorageClass

```text
StorageClass → mẫu "cấp phát bằng cách nào" (ví dụ AWS gp3, fast-ssd)
PVC          → một YÊU CẦU lưu trữ ("Tôi cần 20Gi, ReadWriteOnce")   ← phía app
PV           → volume ĐÃ cấp phát thật sự gắn với PVC                 ← phía cluster
Cấp phát động: một PVC tham chiếu StorageClass sẽ tự tạo một PV khớp.

App → PVC → (StorageClass cấp phát) → PV → đĩa thật (EBS, PD, Ceph, NFS…)
```

## Một StatefulSet với lưu trữ theo từng Pod

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # headless Service cho DNS ổn định
  replicas: 3
  selector:
    matchLabels: { app: db }
  template:
    metadata:
      labels: { app: db }
    spec:
      containers:
        - name: db
          image: postgres:16
          ports: [{ containerPort: 5432 }]
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:      # mỗi Pod nhận PVC/PV RIÊNG từ mẫu này
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Headless Service cho DNS ổn định theo từng Pod (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## Access mode & các lưu ý

```text
ReadWriteOnce (RWO)  → mount đọc-ghi bởi MỘT node (đa số block storage: EBS/PD)
ReadOnlyMany (ROX)   → chỉ đọc bởi nhiều node
ReadWriteMany (RWX)  → đọc-ghi bởi nhiều node (cần NFS/CephFS/EFS)
⚠ Xóa một StatefulSet mặc định KHÔNG xóa PVC của nó (dữ liệu được giữ lại).
⚠ Reclaim policy (Retain/Delete) quyết định điều gì xảy ra với PV khi PVC bị gỡ.
⚠ Kubernetes cho danh tính+lưu trữ, nhưng clustering/replication cấp ứng dụng là VIỆC CỦA BẠN
  (thường qua một Operator, ví dụ cho Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (ổn định, có thứ tự)
```

## Tại sao điều này quan trọng

Chạy workload stateful đúng cách là một trong những phần khó hơn của Kubernetes, nên hiểu StatefulSet và lưu trữ bền vững là kiến thức cấp senior với hệ quả production thật sự. Điểm cốt lõi là *vì sao* Deployment chưa đủ: Pod của nó có thể thay thế lẫn nhau (tên ngẫu nhiên, thứ tự bất kỳ, không có trạng thái theo từng Pod), điều lý tưởng cho dịch vụ stateless nhưng sai cho cơ sở dữ liệu và kho phân cụm vốn cần **danh tính ổn định** (để các peer tìm thấy `db-0`, `db-1`, `db-2` qua DNS), **đĩa bền vững riêng** sống sót qua restart và dời lịch, cùng khởi động và scale **có thứ tự, có kiểm soát**. Một **StatefulSet** cung cấp chính xác các đảm bảo này, và nó ghép với các tầng trừu tượng lưu trữ: **PersistentVolumeClaim** là yêu cầu lưu trữ phía ứng dụng, **PersistentVolume** là volume được cấp phát thật, và **StorageClass** cho phép cấp phát động — với `volumeClaimTemplates` cho mỗi Pod PVC/PV riêng. Các lưu ý là nơi kỹ sư senior chứng tỏ giá trị: **access mode** (RWO so với RWX và backend nào hỗ trợ), việc xóa một StatefulSet mặc định **giữ lại PVC**, **reclaim policy** chi phối số phận của PV, và — quan trọng nhất — rằng Kubernetes cung cấp danh tính và lưu trữ nhưng **replication và clustering cấp ứng dụng vẫn là trách nhiệm của bạn**, thường giao cho một Operator. Vì độ bền dữ liệu và hành vi stateful đúng đắn không khoan nhượng (sai sót nghĩa là mất dữ liệu hoặc split-brain), thành thạo StatefulSet, PV/PVC và các lưu ý của chúng là điều nền tảng để chạy cơ sở dữ liệu và các hệ thống stateful khác một cách đáng tin cậy trên Kubernetes.

Vì sao Deployment chưa đủ

Các đảm bảo của StatefulSet

Lưu trữ bền vững: PV, PVC, StorageClass

Một StatefulSet với lưu trữ theo từng Pod

Access mode & các lưu ý

Tại sao điều này quan trọng

Câu hỏi liên quan