Statefulset (II)

The Kubernetes project introduces a set of API objects called Persistent Volume Claim (PVC) and Persistent Volume (PV)

Define a PVC and declare the attributes of the desired Volume

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pv-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

In the applied Pod, declare to use this PVC:

apiVersion: v1
kind: Pod
metadata:
  name: pv-pod
spec:
  containers:
    - name: pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pv-storage
  volumes:
    - name: pv-storage
      persistentVolumeClaim:
        claimName: pv-claim

In the Volume definition of Pod, you only need to declare that its type is persistentVolumeClaim, and then specify the name of PVC. You don't have to care about the definition of Volume itself at all.

Declare PVC in StatefulSet

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

StatefulSet adds an additional volumeClaimTemplates field. All pods managed by this StatefulSet will declare a corresponding PVC; The definition of PVC comes from the template field of volumeClaimTemplates. At the same time, the name of the PVC will be assigned a number exactly consistent with the Pod.

After the automatically created PVC is successfully Bound to the PV, it will enter the Bound state, which means that the Pod can mount and use the PV.

The premise of binding PVC and PV is that the operation and maintenance personnel have created qualified PV in the system; Alternatively, your Kubernetes cluster runs on the public cloud, so Kubernetes will automatically create PVS matching PVC for you through Dynamic Provisioning.

kubectl get pvc

NAME          STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
www-web01-0   Pending                                                     12s

PVC is named by "< PVC name > - < statefulset name > - < number >" and is in Bound state. (pend is because PV is not established)

summary

The controller of StatefulSet directly manages Pod. This is because different Pod instances in stateful set are not exactly the same as those in ReplicaSet, but slightly different. For example, the hostname and name of each Pod are different and carry numbers. The StatefulSet distinguishes these instances by adding a predetermined number to the Pod name.

Kubernetes generates DNS records with the same number in the DNS server for these numbered pods through Headless Service. As long as StatefulSet can ensure that the numbers in the names of these pods remain unchanged, the Service is similar to web-0 nginx. default. svc. cluster. DNS records such as local will not change, and the IP address of the Pod resolved by this record will be automatically updated with the deletion and re creation of the backend Pod. Of course, this is the capability of the Service mechanism itself, and StatefulSet does not need to worry about it.

StatefulSet also assigns and creates a PVC with the same number for each Pod. In this way, Kubernetes can bind the corresponding PV to this PVC through the Persistent Volume mechanism, so as to ensure that each Pod has an independent Volume.