[Kubernetes Resources] StatefulSet Stateless Service Management Introduction to Practical Detailed Explanation

1. StatefulSet theoretical knowledge

Official Chinese Reference Documentation

1. StatefulSet Pod controller features

StatefulSet (abbreviated as sts) is also a Pod resource manager in the K8S cluster. Different from the deployment Pod controller, StatefulSet is used to manage stateless programs. The characteristics are as follows:

• Stable network identifier: Managed Pods have a stable network identifier. Can be accessed via network identifier.
• Orderly deployment and expansion: StatefulSet will deploy Pods one by one in the specified order, and each Pod has a unique serial number, which will not change throughout the life cycle. When expanding, Pods will also be added one by one in the specified order.
• Stable storage: Each Pod uses an independent persistent volume storage, such as NFS.
• Stateful services: StatefulSet is suitable for stateful services, such as databases, caches, etc. These services require stable network identifiers and persistent storage.

In short, StatefulSet provides a reliable, orderly, and stateful service deployment and expansion method, which is suitable for stateful services that require stable network identifiers and persistent storage.

2. What are stateful and stateless services?

Stateless services refer to services that do not require persistent storage and state, such as Web servers, API servers, and so on . These services can run on any node because they don't need to share data between different nodes, and they don't need fast recovery in case of node failure. Stateless services can be scaled horizontally to improve performance and availability.

Stateful services refer to services that require persistent storage and state maintenance, such as databases and caches . These services need to keep data synchronized between different nodes, and need to be able to recover quickly when a node fails.

3. The difference between Deployment and StatefulSet

Deployment and StatefulSet are two commonly used controllers in Kubernetes. Their main differences are as follows:

• Deployment is a controller for managing stateless applications, while StatefulSet is a controller for managing stateful applications.

• Deployment can create multiple Pod copies. There is no sequence relationship between these Pod copies, and they can be scheduled and replaced at will. The Pod copies created by StatefulSet have a fixed order, and each Pod copy has a unique identifier, which can ensure the data persistence and stability of stateful applications.

• Deployment can perform rolling updates, that is, to maintain the availability of applications during the update process. However, the update process of StatefulSet needs to be manually controlled. It is necessary to delete the old Pod copy and then create a new Pod copy. Therefore, there will be a certain amount of downtime during the update process.

• Deployment can use RollingUpdate strategy for rolling update, while StatefulSet can use OnDelete and RollingUpdate strategies for update.

In short, Deployment is suitable for managing stateless applications, while StatefulSet is suitable for managing stateful applications. If the application needs to ensure data persistence and stability, it is recommended to use StatefulSet.

2. Case: Practical demonstration of StatefulSet resources

1. Create a WEB site and verify the characteristics of StatefulSet

Step 1: Create sts-web-svcan SVC named , which needs to be associated with a service when creating a statefulset resource. The YAML is as follows:

cat sts-web-svc.yaml 
---
apiVersion: v1
kind: Service
metadata:
  name: sts-web-svc
spec:
  selector:
    app: web-nginx
  ports:
  - port: 80
    targetPort: 80
  clusterIP: None     # 设置无IP地址

Create svc resource:

kubectl apply -f sts-web-svc.yaml

View the created svc resource, as shown in the following figure, you can see that the created svc has not assigned an IP address:

kubectl get svc sts-web-svc

Step 2: Create a statefulset resource

cat sts-web.yaml 
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: sts-web
  namespace: default
spec:
  serviceName: sts-web-svc  # 关联SVC资源
  replicas: 2               # 副本数
  selector:
    matchLabels:            # 关联具有app=web-nginx标签的Pod
      app: web-nginx
  volumeClaimTemplates:        # 卷申请模板 
  - metadata:
      name: www                # 卷申请模板名称
    spec:
      accessModes: ["ReadWriteOnce"] # 访问模式
      storageClassName: nfs          # 指定供应商,前提是需要存在此供应商
      resources:
        requests:
          storage: 1Gi               # 存储大小1G
  template:
    metadata:
      labels:
        app: web-nginx
    spec:
      containers:
      - name: web-nginx
        image: nginx:1.18.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www             # 指定卷申请模板名称
          mountPath: /usr/share/nginx/html
        startupProbe:           # 启动探测
          tcpSocket:
            port: 80

Execute YAML:

kubectl apply -f sts-web.yaml

Step Three: Feature Testing

1. Pods have a unique serial number: as shown in the figure below, the Pod names are in order

kubectl get pods -l app=web-nginx -o wide

After deleting sts-web-0, the Pod name automatically created after the Pod will not change

kubectl delete pod sts-web-0

2. Pod independent persistent volume storage: view PVC, automatically generate two PVCs, isolated from each other

kubectl get pvc -l app=web-nginx
ls /data/nfs_pro|grep default-www-sts-web-*

3. Stable network identifier: we use busybox to run Pod, and nslookup to analyze

kubectl run busybox --image docker.io/library/busybox:1.28 --rm -it busybox -- sh

2. StatefulSet rolling update

Rolling updates spec.updateStrategyare defined using the field. Currently statefulset supports two update strategies as follows:

• RollingUpdate: rolling update
• OnDelete: It will not be updated automatically, it will be updated after manually deleting the Pod

The following demonstrates a rolling update:

Step 1: Create and execute statefulset resources

cat web-svc.yaml 
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80
  clusterIP: None

Create statefulset, use nginx:1.18 mirror

cat web.yaml 
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: default
spec:
  serviceName: web
  replicas: 5   
  selector:
    matchLabels:           
      app: web
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 0 # 最多不可用Pod,0表示2个Pod可用 
      partition: 2      # 只更新序号大于等于partition值的Pod
  volumeClaimTemplates:       
  - metadata:
      name: web               
    spec:
      accessModes: ["ReadWriteOnce"] 
      storageClassName: nfs          
      resources:
        requests:
          storage: 1Gi               
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.18.0    # 使用1.18.0版本镜像
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: web           
          mountPath: /usr/share/nginx/html

Execute the YAML file

kubectl apply -f web-svc.yaml
kubectl apply -f web.yaml

Step 2: Update using nginx:latestthe mirror

Re-YAML a bit:

kubectl apply -f web.yaml

Verification: Because of us, partition: 2all Pods will not be updated, only Pods with serial numbers greater than 2, including 2

3. Summary

• The Pod names managed by the statefulset are ordered, and the names of the automatically created Pods will not change after the specified Pod is deleted.
• The server name must be specified when the statefulset is created. If the server does not have an IP address, DNS analysis will be performed on the server to find the corresponding Pod domain name.
• The statefulset has a volumeclaimtemplate volume management template, and the created Pods all have independent volumes and do not affect each other.
• The Pod created by statefulset has an independent domain name. When we specify access to Pod resources, we can use the domain name to specify, the IP will change, but the domain name will not (domain name: Pod name svc name.svc namespace.svc.cluster.local )