Giải Quyết Bài Toán Stateful Applications trên Kubernetes: Biến “Khó” Thành “Dễ”

Nam Hoài
05/06/2025
10:15
kubernetes, Mindset, Stateful Applications

Thực tình mà nói, khi Kubernetes mới ra đời, nó được thiết kế chủ yếu để “ôm” những ứng dụng không trạng thái (Stateless Applications) như mấy cái API Gateway, Web Server đơn giản. Mấy ứng dụng này cứ “đẻ” ra là chạy, “chết” đi là thôi, không cần lưu trữ gì cục bộ cả. Ngon ơ luôn :V

Nhưng rồi các bác biết đấy, chẳng có hệ thống nào mà không cần đến database, message queue, hay mấy cái cache như Redis cả. Mà mấy thằng này thì lại là Stateful Applications chính hiệu: chúng cần lưu trữ dữ liệu, cần định danh ổn định, cần mạng lưới ổn định,… Đưa mấy thằng này lên Kubernetes cứ như “đi trên dây” vậy, dễ “ngã chổng vó” lắm nếu không hiểu rõ.

Hôm nay, tôi sẽ đi sâu vào cái “bài toán khó” này, xem cách Kubernetes hỗ trợ Stateful Applications ra sao, và những công cụ, chiêu trò nào sẽ giúp anh em mình “biến khó thành dễ” nhé.

1. Tại Sao Stateful Applications Lại Là Một “Cơn Ác Mộng” Trên Kubernetes?

Trước khi đi vào cách giải quyết, mình phải hiểu tại sao nó lại khó đã. Có mấy lý do chính sau đây, mà tôi tin là nhiều bác cũng đã từng nếm trải:

Tính định danh ổn định (Stable Identity): Một Pod trong Kubernetes, khi nó “chết” và được khởi tạo lại, nó sẽ có một cái tên mới, một địa chỉ IP mới. Nhưng với database chẳng hạn, nó cần một định danh ổn định để các client biết đường mà kết nối lại, hoặc để các replica trong cụm biết nhau.
Lưu trữ bền vững (Persistent Storage): Dữ liệu của Stateful Applications phải sống sót qua các lần Pod bị khởi động lại, bị xóa. Nếu Pod chết mà dữ liệu cũng “bay màu” thì coi như “toang”.
Mạng lưới ổn định (Stable Network Identity): Tương tự như định danh, các replica của một database cần có cách ổn định để giao tiếp với nhau, ví dụ như mysql-0.mysql-service, mysql-1.mysql-service.
Thứ tự khởi tạo và tắt (Ordered Deployment and Scaling): Với các ứng dụng cụm (clustered applications) như Kafka hay Cassandra, thứ tự khởi tạo các Node và thứ tự tắt chúng đi cực kỳ quan trọng để đảm bảo tính toàn vẹn dữ liệu và hoạt động bình thường của cụm. Kubernetes truyền thống không quan tâm đến thứ tự này.
Quản lý cấu hình và Secrets (Configuration and Secrets Management): Các ứng dụng stateful thường có cấu hình phức tạp, cần quản lý tốt các secret (mật khẩu database, khóa API…).

2. “Cứu Tinh” Của Stateful Applications Trên Kubernetes: StatefulSets và Persistent Volumes

May mắn thay, Kubernetes không “bỏ rơi” anh em mình đâu. Nó đã cung cấp những “cứu tinh” để giải quyết mấy vấn đề trên, đó chính là StatefulSets và cơ chế Persistent Volumes.

2.1. Persistent Volumes (PV) và Persistent Volume Claims (PVC): “Ổ Đĩa” Bền Vững Cho Ứng Dụng

Hãy nghĩ đơn giản thế này:

Persistent Volume (PV): Giống như một cái ổ cứng vật lý hoặc một cái “ổ đĩa ảo” mà anh em mình mua từ nhà cung cấp Cloud (ví dụ: EBS của AWS, Persistent Disk của GCP, Azure Disk). Nó là tài nguyên lưu trữ thực sự có sẵn trong cụm Kubernetes. PV này không gắn với bất kỳ Pod nào cụ thể, nó tồn tại độc lập.
Persistent Volume Claim (PVC): Giống như một cái “yêu cầu thuê” ổ đĩa của Pod. Một Pod không trực tiếp “gắn” vào PV mà nó “yêu cầu” một PVC, rồi Kubernetes sẽ tìm một PV phù hợp để “cấp phát” cho cái PVC đó.

Tại sao lại phức tạp thế?

Cơ chế này giúp tách bạch việc quản lý tài nguyên lưu trữ (PV do Admin quản lý) và việc sử dụng tài nguyên lưu trữ (PVC do Developer yêu cầu). Nó đảm bảo rằng dữ liệu sẽ tồn tại ngay cả khi Pod bị xóa hoặc khởi động lại.

Cấu hình một PVC đơn giản:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-database-data
spec:
  accessModes:
    - ReadWriteOnce # Chỉ cho phép 1 Pod đọc/ghi tại một thời điểm
  resources:
    requests:
      storage: 10Gi # Yêu cầu 10 Gigabytes dung lượng
  storageClassName: standard # Sử dụng StorageClass tên là "standard" (sẽ nói thêm)

Các loại accessModes phổ biến:

ReadWriteOnce (RWO): Chỉ một Pod duy nhất trên một Node duy nhất có thể gắn (mount) PV này ở chế độ đọc/ghi. Phù hợp cho database đơn thể (single instance database).
ReadOnlyMany (ROX): Nhiều Pods có thể gắn PV này ở chế độ chỉ đọc. Hữu ích cho việc phân phối cấu hình hoặc dữ liệu tĩnh.
ReadWriteMany (RWX): Nhiều Pods có thể gắn PV này ở chế độ đọc/ghi. Chỉ một số ít loại lưu trữ (như NFS, GlusterFS) hỗ trợ.

2.2. StorageClass và Dynamic Provisioning: Tự Động “Cấp Phát” Ổ Đĩa

Thay vì phải tạo thủ công từng cái PV một, các bác có thể dùng StorageClass để Kubernetes tự động “cấp phát” PV khi một PVC được yêu cầu. Cái này gọi là Dynamic Provisioning.

StorageClass: Định nghĩa “loại” lưu trữ mà anh em muốn. Ví dụ, một StorageClass tên là standard có thể là SSD, còn premium có thể là SSD hiệu năng cao hơn, đắt tiền hơn. Mỗi StorageClass sẽ dùng một CSI driver (Container Storage Interface) cụ thể của nhà cung cấp cloud (hoặc on-premise) để tự động tạo ra PV.

Ví dụ một StorageClass trên AWS (nếu bác dùng EKS):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp2-ssd
provisioner: kubernetes.io/aws-ebs # Cái này là CSI driver của AWS EBS
parameters:
  type: gp2 # Loại ổ đĩa EBS
  fsType: ext4 # Định dạng filesystem
reclaimPolicy: Delete # Xóa PV khi PVC bị xóa
volumeBindingMode: Immediate # Cấp phát ngay khi PVC được tạo

Với cái này, khi một PVC yêu cầu storageClassName: gp2-ssd, Kubernetes sẽ tự động gọi AWS để tạo một volume EBS loại gp2 và “gắn” vào PVC đó. Tiện lợi hơn rất nhiều đúng không các bác?

2.3. StatefulSets: “Người Gác Cổng” Cho Ứng Dụng Có Trạng Thái

Đây chính là cái “bảo bối” quan trọng nhất của Kubernetes để quản lý Stateful Applications. StatefulSet giải quyết mấy vấn đề về định danh, mạng lưới, và thứ tự mà tôi nói ở trên.

Các tính năng “ăn tiền” của StatefulSets:

Định danh và tên Pod ổn định: Mỗi Pod trong StatefulSet sẽ có một tên duy nhất, có thứ tự (ví dụ: my-db-0, my-db-1, my-db-2). Kể cả khi Pod my-db-0 chết đi và được khởi tạo lại, nó vẫn sẽ là my-db-0 và “gắn” lại với cái PVC đã được cấp phát cho nó.
Mạng lưới ổn định: StatefulSets thường đi kèm với một Headless Service. Headless Service không có Load Balancer, mà nó tạo ra các bản ghi DNS riêng cho từng Pod (ví dụ: my-db-0.my-db-service.mynamespace.svc.cluster.local), giúp các Pods trong cùng StatefulSet hoặc các ứng dụng khác có thể giao tiếp với nhau bằng tên ổn định.
Khởi tạo và Scale theo thứ tự: Khi scale up, các Pods sẽ được tạo theo thứ tự tăng dần (từ -0 đến -N). Khi scale down, các Pods sẽ được xóa theo thứ tự giảm dần (từ -N về -0). Cái này cực kỳ quan trọng cho các cụm database.
PVC được tạo tự động cho mỗi Pod: Mỗi Pod trong StatefulSet sẽ có một PVC riêng biệt và được “cấp phát” một PV riêng. Dữ liệu của mỗi Pod là độc lập và bền vững.

Ví dụ một StatefulSet cho một ứng dụng database giả định:

apiVersion: v1
kind: Service # Đây là Headless Service cho StatefulSet
metadata:
  name: my-database-service
spec:
  ports:
  - port: 3306
    name: mysql
  clusterIP: None # Quan trọng: Khai báo là Headless Service
  selector:
    app: my-database
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-database
spec:
  selector:
    matchLabels:
      app: my-database
  serviceName: "my-database-service" # Phải trùng với tên Headless Service
  replicas: 3 # Chạy 3 bản sao database
  template:
    metadata:
      labels:
        app: my-database
    spec:
      containers:
      - name: mysql-container
        image: mysql:8.0 # Ví dụ dùng MySQL
        env: # Ví dụ các biến môi trường
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secrets
              key: root-password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: my-database-data-volume # Tên mount point bên trong container
          mountPath: /var/lib/mysql # Đường dẫn lưu trữ dữ liệu MySQL
  volumeClaimTemplates: # Đây là nơi định nghĩa PVCs tự động
  - metadata:
      name: my-database-data-volume # Phải trùng với tên volumeMounts ở trên
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: standard # Sử dụng StorageClass "standard"
      resources:
        requests:
          storage: 20Gi # Mỗi Pod sẽ có 20GB dung lượng

Phân tích ví dụ trên:

Chúng ta có một Headless Service (my-database-service) để đảm bảo các Pod có định danh mạng ổn định.
StatefulSet (my-database) với 3 replicas. Các Pod sẽ có tên my-database-0, my-database-1, my-database-2.
Mỗi Pod sẽ tự động được tạo một PVC riêng (ví dụ: my-database-data-volume-my-database-0, my-database-data-volume-my-database-1,…). Khi Pod bị xóa, PVC vẫn còn đó, và khi Pod khởi tạo lại (với cùng tên), nó sẽ “gắn” lại vào cái PVC cũ và dữ liệu không bị mất.

3. “Đòn Bẩy” Nâng Cao: Các Operator Cho Database Trên Kubernetes

Mặc dù StatefulSet đã rất mạnh rồi, nhưng việc quản lý một database phức tạp (ví dụ: cụm PostgreSQL với primary/replica, backup, restore, failover…) vẫn còn nhiều công đoạn thủ công. Đây chính là lúc các Operator “tỏa sáng”.

Operator là gì? Các bác cứ hình dung Operator như một “quản trị viên” tự động cho một ứng dụng cụ thể (ví dụ: database) trên Kubernetes. Nó hiểu biết sâu sắc về ứng dụng đó (cách deploy, scale, backup, restore, failover…). Nó sẽ tự động thực hiện các tác vụ phức tạp mà bình thường anh em mình phải làm bằng tay.
Lợi ích khi dùng Operator cho database:
- Tự động hóa triển khai: Deploy một cụm database chỉ với một vài dòng YAML.
- Tự động scale: Tăng/giảm số lượng replica của database.
- Tự động Backup/Restore: Lên lịch backup, phục hồi dữ liệu khi có sự cố.
- Tự động Failover: Tự động chuyển đổi sang Node dự phòng khi Node chính gặp vấn đề.
- Cập nhật phiên bản (Upgrades): Tự động cập nhật phiên bản database mà không gây gián đoạn.
Các Operator phổ biến:
- CrunchyData PostgreSQL Operator: Rất nổi tiếng và được tin dùng cho PostgreSQL.
- Percona MySQL Operator: Dành cho MySQL và Percona Server.
- KubeDB: Hỗ trợ nhiều loại database (PostgreSQL, MySQL, MongoDB, Redis, Elasticsearch…).
- Cassandra Operator (DataStax, KubeCassandra): Dành cho Apache Cassandra.
- Kafka Operator (Strimzi): Dành cho Apache Kafka.

Ví dụ (khái niệm) về cách dùng Operator:

Thay vì viết StatefulSet và PVC phức tạp, anh em chỉ cần khai báo một Custom Resource Definition (CRD) do Operator cung cấp:

apiVersion: postgresql.cnpg.io/v1 # API version của CrunchyData Postgres Operator
kind: Cluster # Đây là CRD mà Operator định nghĩa
metadata:
  name: my-pg-cluster
spec:
  instances: 3 # Muốn chạy 3 bản PostgreSQL
  storage:
    size: 50Gi # Mỗi instance có 50GB storage
  postgresql:
    version: "15" # Phiên bản PostgreSQL muốn dùng
  # ... và nhiều cấu hình khác cho backup, high availability, v.v.

Sau đó, cái Operator sẽ “đọc” cái YAML này và tự động tạo ra StatefulSet, PVCs, Services, và tất cả những gì cần thiết để chạy một cụm PostgreSQL 3 Node “hoành tráng” cho bác. “Nhàn tênh” đúng không?

4. Những “Chiêu Thức” Khác Để “Sống Sót” Với Stateful Applications

Ngoài StatefulSets và Operators, còn một số “chiêu” khác mà anh em mình nên biết:

Anti-Affinity: Đảm bảo các replica của ứng dụng stateful (ví dụ: các Node của cụm database) không nằm cùng trên một Node vật lý. Điều này giúp tăng tính sẵn sàng. Nếu một Node “chết”, không phải tất cả các replica đều “toi” theo.
Pod Disruption Budgets (PDBs): Cái này quan trọng lắm. PDBs đảm bảo rằng luôn có một số lượng tối thiểu các Pods của một ứng dụng chạy được trong quá trình bảo trì Node (ví dụ: nâng cấp Kubernetes, Node bị reboot). Nó giúp tránh việc mất quá nhiều replica cùng lúc khi có sự cố.
Backup và Disaster Recovery: Đây là cái không thể thiếu. Dù có dùng StatefulSets hay Operator, anh em vẫn phải có chiến lược backup dữ liệu ra ngoài cụm Kubernetes (ví dụ: S3, Google Cloud Storage). Khi có “biến”, mình còn có cái để restore. Các Operator thường có tính năng backup tích hợp, các bác nên tận dụng.
Giám sát và Cảnh báo (Monitoring & Alerting): Theo dõi chặt chẽ hiệu suất của database (CPU, Memory, IOPS, latency) và cảnh báo ngay lập tức khi có vấn đề. Prometheus và Grafana là cặp đôi hoàn hảo cho việc này.

Lời kết

Việc chạy Stateful Applications trên Kubernetes không còn là “điều không thể” nữa đâu các bác. Nó đã trở nên khả thi và thậm chí là hiệu quả hơn rất nhiều nhờ vào các công cụ như StatefulSets, Persistent Volumes, StorageClass và đặc biệt là sự ra đời của các Operator mạnh mẽ.

Tuy nhiên, nó đòi hỏi anh em mình phải hiểu sâu về cách thức hoạt động của Kubernetes và của chính ứng dụng stateful đó. Không thể cứ “quăng” database lên Kubernetes mà không suy nghĩ đâu nhé.

Hy vọng bài viết này đã giúp các bác có cái nhìn rõ ràng hơn và tự tin hơn khi “chinh phục” các ứng dụng có trạng thái trên Kubernetes. Nếu các bác có kinh nghiệm hay câu hỏi nào muốn chia sẻ, đừng ngần ngại để lại bình luận nhé. Anh em mình cùng học hỏi và “chiến đấu” tiếp 😀