Shulou(Shulou.com)06/02 Report--

This article mainly introduces how to use the stateful controller in docker, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let Xiaobian take you to understand.

In applications, it can be divided into stateful applications and stateless applications.

Stateless applications are more focused on groups, and any member can be replaced.

The application of statefulness is to focus on the individual.

Like nginx and myapp, which we managed with deployment controller, are stateless applications.

Such as mysql, redis,zookeeper and so on are stateful applications, and some of them can be divided into master and subordinate and sequence.

Statefulset controller can manage stateful applications, but it is also very troublesome to implement. The procedures managed by our operators need to be scripted and injected into statefulset before they can be used. Although some people on the Internet have done the script of stateful, it is still recommended that we should not easily migrate such stateful applications such as redis and mysql to K8s.

In K8s, statefulset mainly manages the application of special effects:

A), each Pod is stable and has a unique network identifier

B), stable and persistent storage device

C), require orderly and smooth deployment and expansion

D), require orderly and smooth termination and deletion

E), for orderly scrolling updates, the slave node should be updated first, and then the master node

Statefulset consists of three components:

A) headless service (headless service, i.e. no name)

B) statefulset controller

C) volumeClaimTemplate (storage volume request template, because each pod needs to have dedicated storage volumes and cannot share storage volumes)

[root@master] # kubectl explain sts # stateful abbreviation [root@master stateful] # cat stateful-demo.yaml apiVersion: v1kind: Servicemetadata: name: myapp-svc labels: myapp-svcspec: ports:-port: 80 name: web clusterIP: None selector: app: myapp-pod---apiVersion: apps/v1kind: StatefulSetmetadata: name: myappspec: serviceName: myapp-svc replicas: 2 selector: matchLabels: app: myapp-pod template: metadata: Labels: app: myapp-pod spec: containers:-name: myapp image: ikubernetes/myapp:v1 ports:-containerPort: 80 name: web volumeMounts:-name: myappdata mountPath: / usr/share/nginx/html volumeClaimTemplates: # Storage Volume request template You can define a volume for each pod You can automatically create a pvc for the namespace where pod resides. -metadata: name: myappdata spec: accessModes: ["ReadWriteOnce"] # storageClassName: "gluster-dynamic" resources: requests: storage: 5Gi # 2G pvc [root@master stateful] # kubectl apply-f stateful-demo.yaml service/myapp-svc unchangedstatefulset.apps/myapp created [root@master stateful] # kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGEmyapp-svc ClusterIP None 80/TCP 12m

See that myapp-svc is headless.

[root@master stateful] # kubectl get stsNAME DESIRED CURRENT AGEmyapp 2 2 6m [root@master stateful] # kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmyappdata-myapp-0 Bound pv002 2Gi RWO 3smyappdata-myapp-1 Bound pv003 1Gi RWO RWX 1s [root@master stateful] # kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEpv001 1Gi RWO RWX Retain Available 1dpv002 2Gi RWO Retain Bound default/myappdata-myapp-0 1dpv003 1Gi RWO RWX Retain Bound default/myappdata-myapp-1 1dpv004 1Gi RWO,RWX Retain Bound default/mypvc 1dpv005 1Gi RWO RWX Retain Available [root@master stateful] # kubectl get podsNAME READY STATUS RESTARTS AGEmyapp-0 1/1 Running 0 4mmyapp-1 1/1 Running 0 4m [root@master stateful] # kubectl Delete-f stateful-demo.yaml service "myapp-svc" deletedstatefulset.apps "myapp" deleted

The above deletion will cause pod and service to be deleted, but pvc will not be deleted, so it can still be restored.

[root@master stateful] # kubectl exec-it myapp-0-/ bin/sh/ # nslookup myapp-0.myapp-svc.default.svc.cluster.localnslookup: can't resolve'(null)': Name does not resolveName: myapp-0.myapp-svc.default.svc.cluster.localAddress 1: 10.244.1.110 myapp-0.myapp-svc.default.svc.cluster.local/ # nslookup myapp-1.myapp-svc.default. Svc.cluster.localnslookup: can't resolve'(null)': Name does not resolveName: myapp-1.myapp-svc.default.svc.cluster.localAddress 1: 10.244.2.97 myapp-1.myapp-svc.default.svc.cluster.local

Myapp-0.myapp-svc.default.svc.cluster.local

Format: pod_name.service_name.namespace.svc.cluster.local

The following extends the myapp pod to 5:

[root@master stateful] # kubectl scale sts myapp--replicas=5statefulset.apps/myapp scaled [root@master stateful] # kubectl get podsNAME READY STATUS RESTARTS AGEclient 0 17dmyapp-0 1 Error 0 17dmyapp-0 1 Running 0 37mmyapp -1 1 Running 0 37mmyapp-2 1 + 1 Running 0 46smyapp-3 1 + 1 + 1 Running 0 43smyapp-4 0 + 1 Pending 0 41s [root@master stateful] # kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEmyappdata-myapp-0 Bound pv002 2Gi RWO 52mmyappdata-myapp-1 Bound pv003 1Gi RWO RWX 52mmyappdata-myapp-2 Bound pv005 1Gi RWO,RWX 2mmyappdata-myapp-3 Bound pv001 1Gi RWO,RWX 2mmyappdata-myapp-4 Pending 2m

In addition, you can also use patch patches to expand and reduce capacity:

[root@master stateful] # kubectl patch sts myapp-p'{"spec": {"replicas": 2statefulset.apps/myapp patched

Next, let's introduce rolling updates.

[root@master stateful] # kubectl explain sts.spec.updateStrategy.rollingUpdate

Suppose there are 4 pod (pod0,pod1,pod2,pod3). If partition is set to 5, then pod updates greater than or equal to 5 will not be updated, and none of our four Pod will be updated; if partition is 4, then pod updates greater than or equal to 4, that is, pod3 updates, and other pod updates will not be updated; if partiton is 3, then pod updates greater than or equal to 3 will be updated, then pod2 and pod3 updates, and other pod will not be updated.

[root@master stateful] # kubectl patch sts myapp-p'{"spec": {"updateStrategy": {"rollingUpdate": {"partition": 4} 'statefulset.apps/myapp patched [root@master stateful] # kubectl describe sts myappUpdate Strategy: RollingUpdatePartition: 4

Next, upgrade myapp to v2.

[root@master stateful] # kubectl set image sts/myapp myapp=ikubernetes/myapp:v2statefulset.apps/myapp image updated [root@master ~] # kubectl get sts-o wideNAME DESIRED CURRENT AGE CONTAINERS IMAGESmyapp 2 21 h myapp ikubernetes/myapp:v2 [root@master ~] # kubectl get pods myapp-4-o yaml containerStatuses:-containerID: docker://898714f2e5bf4f642e2a908e7da67eebf6d3074c89bbd0d798d191a2061a3115 image: ikubernetes/myapp:v2

You can see that the template version used by pod myapp-4 is v2.

Thank you for reading this article carefully. I hope the article "how to use stateful Controller in docker" shared by the editor will be helpful to everyone. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.