Storage, PV, PVC và StateFullset

Phần 3: StateFulSet

1. StateFulSet là gì?

StateFulSet và Stateless

Các loại ứng dụng có thể chia làm 2 loại là stateful application và stateless application. Điểm khác nhau cơ bản là các ứng dụng stateless không lưu trạng thái xử lý trước đó, mọi request tới đều được xử lý như một yêu cầu mới hoàn toàn mới, không liên quan gì tới các xử lý trước đó. Triển khai ứng dụng stateless dưới dạng Deployment, do các yêu cầu xử lý độc lập nhau, có thể dễ dàng scale ứng dụng lên (tăng/giảm số lượng Pod) để xử lý request.

Các ứng dụng stateful thường thấy như các loại database (MySQL, Elasticsearch,…) là các ứng dụng cần duy trì trạng thái và dữ liệu qua nhiều phiên làm việc. Triển khai ứng dụng stateful dưới dạng StateFulSet, ví dụ như mysql, mongodb, elasticsearch đều được triển khai dưới dạng statefulset trên kubernetes

Deployment

• Các Pod của Deployment là hoàn toàn giống nhau (Identical) và có thể thay thể lẫn nhau và chức năng. Nghĩa là một Pod bị lỗi thì hoàn toàn có thể thay thế bằng một Pod mới để tiếp tục xử lý.
• Deployment trước tiên sẽ sinh ra các Replicaset, sau ReplicaSet sẽ tạo ra các Pod theo thứ tự ngẫu nhiên. Tên Pod cũng theo format tên của Replicset + mã hash random gán vào đuôi mỗi Pod

• Có thể tạo một Service để Load banlancing tới tất cả các Pod cho các request tới ứng dụng.
• Các Pod của Deployment cũng có thể bị xóa theo thứ tự bất kỳ, hoặc xóa đồng thời nhiều Pod (trong trường hợp scale down deployment)

StatefulSet

• Các Pod của Statefulset không thể được tạo hay xóa cùng lúc. Nó sẽ được tạo tuần tự.
• Các Pod của Statefulset không hoàn toàn giống nhau. Trên thực tế nó đều có các định dạng riêng. Có pod-0, pod-1,.. của statefulset.
• Các Pod được tạo với các mô tả giống nhau (specification) nhưng không thể thay thế lẫn nhau (not interchangeable)
• Khi một Pod bị lỗi nó sẽ được thay thế bằng một Pod mới cùng định danh (ví dụ pod-1 bị lỗi sẽ bị thay bằng Pod mới với tên vẫn là pod-1).

2. Triển khai Statefulset – Mariabd trên k8s

2.1 Chỉnh sửa cấu hình NFS Server ( Thực hiện trên nfs-server)

sudo vi /etc/exports
/data *(rw,sync,no_subtree_check,no_root_squash)
sudo exportfs -rav
sudo systemctl restart nfs-server

2.2 Cấu hình StatefulSet Mariadb trên rancher

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mariadb
  namespace: beobeo-ecommerce
spec:
  serviceName: mariadb-service
  replicas: 1
  selector:
    matchLabels:
      app: mariadb
  template:
    metadata:
      labels:
        app: mariadb
    spec:
      securityContext:
        fsGroup: 65534 
      containers:
      - name: mariadb
        image: mariadb:latest
        env:
        - name: MARIADB_ROOT_PASSWORD
          value: "beobeo@2025!"
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mariadb-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mariadb-storage
        persistentVolumeClaim:
          claimName: mariadb-storage

fsGroup: 65534 có nghĩa là nobody:nogroup (UID/GID 65534). Làm như vậy để mọi client kể cả khi UID không khớp vẫn đọc/ghi được. Chỉ áp dụng cho môi trường test/lab. Trong môi trường Production cần phải phân quyền chi tiết và rõ ràng hơn.

2.3 Cấu hình Service NodePort MariaDB để truy cập bên ngoài

apiVersion: v1
kind: Service
metadata:
  name: mariadb-service
  namespace: beobeo-ecommerce
spec:
  selector:
    app: mariadb
  type: NodePort
  ports:
    - port: 3306
      targetPort: 3306
      nodePort: 31306

2.4 Cấu hình service ClusterIP để truy cập nội bộ trong cụm k8s

apiVersion: v1
kind: Service
metadata:
  name: mariadb
  namespace: beobeo-ecommerce
spec:
  type: ClusterIP
  ports:
    - name: mysql
      port: 3306
      targetPort: 3306
  selector:
    app: mariadb

Như vậy name nội bộ kết nối tới mariadb là : ..svc.cluster.local
Trong trường hợp của tôi sẽ là mariadb.beobeo-ecommerce.svc.cluster.local
Vì name clusterIP là mariadb
Và Namespace là: beobeo-ecommerce

Từ pod Openlitespeed đã tạo thử kết nối vào database theo clusterip name: