Create StatefulSet in K8s

Problems encountered:

The Pod created by Deployment is stateless. After hanging on the Volume, if the Pod hangs, the Replication Controller will run another one to ensure availability, but because it is stateless, the relationship between the Pod and the previous Volume when it hangs It has been disconnected, and the newly created Pod cannot find the previous Pod. But for users, they are unaware that the underlying Pod is hung, but when the Pod is hung, the previously mounted disk can no longer be used.

solution

The StatefulSet launched with K8s v1.5 can retain the state of the Pod.

Reference blog

Because the Kubernetes 1.5 version has not been released for a long time, the domestic information is quite small. Except for some StatefulSet information on big blogs such as tonybai, it can only be searched on the Internet. By searching for the creation method of StatefulSet on google, I finally found an English blog, the link is as follows. For this emerging framework, you still have to go to google more.

https://thenewstack.io/deploy-highly-available-wordpress-instance-statefulset-kubernetes-1-5/

How to create

Things that need to be prepared before creating a StatefulSet, it is worth noting that the order of creation is very critical. The order of creation is as follows:

1、Volume
2、Persistent Volume
3、Persistent Volume Claim
4、Service
5、StatefulSet

Volume can have many types, such as nfs, glusterfs, etc., we use ceph RBD here to create.

Create Volume

sudo rbd create {volume_name} --size 1024 -m {ceph-monitor-ip} -k /etc/ceph/ceph.client.admin.keyring
//禁止掉一些rdb的feature，否则挂载会失败
rbd feature disable volume101 exclusive-lock, object-map, fast-diff, deep-flatten

Create PersistentVolume

Create pv.yaml with the following content:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: {pv_name}
  labels:
    {label_key}:{label_value}
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  rbd:
    monitors:
      - {ceph-monitor-ip}
    pool: rbd
    image: {volume_name}
    user: admin
    secretRef:
      name: ceph-secret
    fsType: ext4
    readOnly: false
  persistentVolumeReclaimPolicy: Recycle

use

kubectl create -f pv.yaml

to create the PV.

Create PersistentVolumeClaim

This step is very, very critical, because if the name of the created PVC does not correspond to the name in the StatefulSet, then the Pod in the StatefulSet must not be created successfully. I was stuck in this step for a day, but I can see the above After a foreign blog, I discovered the naming rules in PVC and StatefulSet. Next, let's talk about the places that need to be paid attention to.

Create pvc.yaml as follows:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: db-mysql-0
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

We have created a PVC called db-mysql-0 here. Isn't this name strange, and the name of PV is not mentioned in this yaml, so how are PV and PVC bound? It is matched by the key:value key-value pair under the labels label. We specified the key-value pair of the label when creating the PV, and the label can be specified through the selector in the PVC.

Then go back to the name definition of this PVC: db-mysql-0 , why is it called such a seemingly regular name, here we need to look at the yaml in the next section to create a StatefulSet, first we see that the name of the StatefulSet is mysql , the number of replicas is set to 2, the name of volumeMounts and volumeClaimTemplates must be the same, which is db , so the name of the first Pod created by StatefulSet should be mysql-0 , and the name of the second one should be mysql-1 . Here, the binding relationship between the Pod and PVC in the StatefulSet is matched by name, namely:

PVC_name === volumeClaimTemplates_name + "-" + pod_name

So this question is a bit interesting, we have to create the PVC first, but the name of the PVC is actually determined by the StatefulSet. I really don't know what the K8S designers think...and the example of creating a StatefulSet in the official documentation is directly given to a yaml file, and does not tell what to create first and then what to create.

Create Service and StatefulSet

In the previous step, we have created a PVC named db-mysql-0 . Next, we will create a service and statefulset. The name of the service can be chosen at will, but the name of the statefulset has been fixed, it is mysql , and the statefulset volumeClaimTemplates_name must be db , and volumeMounts_name must also be db . Only in this way, the pods in the statefulset can be named to match the PVC, otherwise the creation will fail.

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: mysql-service
  labels:
    app: mysql
spec:
  ports:
  - port: 80
    name: my-port
  clusterIP: None
  selector:
    app: mysql
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql-service"
  replicas: 2
  template:
    metadata:
      labels:
        app: mysql
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: mysqlpod
        image: mysql:latest
        ports:
        - containerPort: 80
          name: my-port
        volumeMounts:
        - name: db
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: db
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

Run the following commands:

kubectl create -f statefulset.yaml

You can create a statefulset.

http://www.cnblogs.com/puyangsky/p/6677308.html