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

Most people do not understand the knowledge points of this article "how to deploy stateful service applications through StatefulSet", so the editor summarizes the following contents, detailed contents, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to deploy stateful service applications through StatefulSet" article.

Summarize first and then explain in detail:

Have a fixed network identity, such as hostname, domain name, etc.

Support for persistent storage

Can be deployed and extended sequentially

Can be terminated and deleted sequentially

Rolling upgrades are also in a certain order.

The basic concepts of StatefulSet:

StatefulSet is primarily used to manage API objects for the workload of stateful applications. For example, Elastic Search cluster, MongoDB cluster, Kafka cluster, Reids cluster, Zookeeper cluster and so on.

Similar to Deployment, StatefulSet also manages Pod of basically the same container specification. The difference is that StatefulSet maintains a sticky logo for each Pod.

These Pod are created according to the same specification, but are not interchangeable, and each Pod has a persistent identifier that is also retained when rescheduled, generally in StatefulSetName-Number format.

For example, if you define a StatefulSet of Redis-Sentinel and specify three copies, you will create three copies named Redis-Sentinel-0, Redis-Sentinel-1, and Redis-Sentinel-2 in turn. The Service of StatefulSet's Pod generally uses Headless Service (headless service) for communication.

The format of Headless is generally:

StatefulSetName- {0..N-1} .serviceName.namespace.svc.cluster.local

The name of the statefulSetName:StatefulSet

{0... Nmur1}: the serial number after the name

The name of the serviceName:Headless Service

Namespace: the namespace where the service is located

Cluster.local:Cluster Daemon (Cluster Domain)

StatefulSet is used for applications that have one or more of the following requirements:

Requires a stable and unique network identifier

Need to persist data

Requires orderly and elegant deployment and expansion

Requires orderly automatic scrolling updates

If you don't need either, you should use Deployment deployment.

Example: define a StatefulSet resource

Create a StatefulSet of nginx as a demonstration: this yaml starts two copies, using a nginx image, and note that service must exist.

ApiVersion: v1kind: Servicemetadata: name: nginx labels: app: nginxspec: ports:-port: 80 name: web clusterIP: None selector: app: nginx---apiVersion: apps/v1kind: StatefulSetmetadata: name: webspec: serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginxspec: containers:-name: nginx image: nginx:1 .18.0 ports:-containerPort: 80 name: web

Create it using kubectl: you can see that both service and statefulset copies are created

[root@k8s-master01] # kubectl create-f nginx-sts.yaml service/nginx createdstatefulset.apps/web created

Check Pod: you can see that the name of the copy starts from 0 in sequence.

[root@k8s-master01 ~] # kubectl get podNAME READY STATUS RESTARTS AGEbusybox 1 7d18hweb-0 1 Running 17 (50m ago) 7d18hweb-0 1 Running 0 74sweb-1 1 Running 0 73s

Check service: you can see that nginx's service does not have CLUSTER-IP.

[root@k8s-master01 ~] # kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGEkubernetes ClusterIP 10.96.0.1 443/TCP 7d21hnginx ClusterIP None 80/TCP 2m43s

Expanded copy: you can see that unlike deployment, the newly generated Pod name sequence number is regular.

[root@k8s-master01 ~] # kubectl scale-- replicas=3 sts web statefulset.apps/web scaled [root@k8s-master01 ~] # kubectl get podNAME READY STATUS RESTARTS AGEbusybox 1 Running 17 (55m ago) 7d18hweb-0 1 Running 0 6m30sweb-1 1 Running 0 6m29sweb-2 0/1 ContainerCreating 0 28s

Test the access to see if you can communicate: you can see that the network is open, and the IP parses directly to 172.18.195.18, which is the IP of Pod without going through a layer of service agents.

[root@k8s-master01] # kubectl exec-ti busybox-- sh/ # nslookup web-0.nginxServer: 10.96.0.10Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName: web-0.nginxAddress 1: 172.18.195.18 web-0.nginx.default.svc.cluster.local/ # ping web-0.nginxPING web-0.nginx (172.18.195.18): 56 data bytes64 bytes from 172. 18.195.18: seq=0 ttl=62 time=1.020 ms64 bytes from 172.18.195.18: seq=1 ttl=62 time=0.860 ms [root@k8s-master01 ~] # kubectl get pod-o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESbusybox 1 Running 18 (28s ago) 7d18h 172.27.14.193 k8s-node02 web-0 1 Running 0 11m 172.18.195.18 k8s-master03 web-1 1max 1 Running 011m 172.25.92.78 k8s-master02 web-2 1 Running 0 5m9s 172.25.244.199 k8s-master01 StatefulSet capacity expansion and reduction StatefulSet expansion:

When the capacity is expanded, it will be created in sequence. For example, I have three web copies in the figure above, and I want to expand the capacity to five. Then the web-3 copy will be created first. If the web-3 copy is created successfully, the web-4; will not be created until the web-3 fails. If the web-3 fails, the subsequent tasks will wait until the web-3 is created successfully.

StatefulSet downsizing:

When reducing capacity, contrary to capacity expansion, it will be deleted from the last one and deleted in the order of web-4 and web-3.

StatefulSet update policy

Two update strategies are supported:

RollingUpdate: the default update policy is scrolling update, which starts with the last copy, and the next copy will not be made until it is successful. The update method is to delete and then create.

OnDelete: when changing the policy to this, we need to manually delete the replica to be updated before the replica update policy is triggered.

StatefulSet grayscale release

Simple grayscale publishing is carried out by using the Partition parameters in the update strategy.

Cascade deletion and non-cascade deletion of StatefulSet

Cascading deletion: delete StatefulSet while deleting Pod. Default is cascading deletion.

[root@k8s-master01 ~] # kubectl delete sts web

Non-cascaded deletion: the Pod will not be deleted when the StatefulSet is deleted. Note that if the Pod is deleted at this time, it will not be rebuilt.

[root@k8s-master01] # kubectl delete sts web-- the above cascade=false is about "how to deploy stateful service applications through StatefulSet". I believe you all have some understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about it, please follow the industry information channel.

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.