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

Overview

RC, Deployment, and DaemonSet are all stateless services. The IP, name, start and stop order of the Pod they manage are all random. What is StatefulSet? As the name implies, stateful collections manage all stateful services, such as MySQL, MongoDB clusters, and so on.

StatefulSet is essentially a variant of Deployment, which has become the GA version in v1.9. In order to solve the problem of stateful service, the Pod it manages has a fixed Pod name, start and stop order. In StatefulSet, the Pod name is Network identity (hostname), and shared storage must be used.

In Deployment, the corresponding service is service, while the corresponding headless service,headless service in StatefulSet, that is, headless service, is different from service in that it does not have Cluster IP. Parsing its name will return the Endpoint list of all Pod corresponding to that Headless Service.

In addition, StatefulSet creates a DNS domain name for each copy of Pod controlled by StatefulSet on the basis of Headless Service. The format of this domain name is:

$(podname). (headless server name)

FQDN: $(podname). (headless server name). Namespace.svc.cluster.local

StatefulSet example

Let's take a look at some examples to demonstrate the features mentioned above to deepen our understanding.

ApiVersion: v1

Kind: Service

Metadata:

Name: nginx

Labels:

App: nginx

Spec:

Ports:

Port: 80

Name: web

ClusterIP: None

Selector:

App: nginx

ApiVersion: apps/v1

Kind: StatefulSet

Metadata:

Name: web

Spec:

Selector:

MatchLabels:

App: nginx # has to match .spec.template.metadata.labels

ServiceName: "nginx" # declares which Headless Service it belongs to.

Replicas: 3 # by default is 1

Template:

Metadata:

Labels:

App: nginx # has to match .spec.selector.matchLabels

Spec:

TerminationGracePeriodSeconds: 10

Containers:

Name: nginx

Image: k8s.gcr.io/nginx-slim:0.8

Ports:containerPort: 80

Name: web

VolumeMounts:name: www

MountPath: / usr/share/nginx/html

VolumeClaimTemplates: # can be thought of as a template for pvc metadata:

Name: www

Spec:

AccessModes: ["ReadWriteOnce"]

StorageClassName: "gluster-heketi" # storage class name, changed to one that already exists in the cluster

Resources:

Requests:

Storage: 1Gi

Through this configuration file, you can see the three components of StatefulSet:

Headless Service: named nginx, is used to define the Pod network identity (DNS domain).

StatefulSet: defines a specific application, named Nginx, with three copies of Pod and a domain name for each Pod.

VolumeClaimTemplates: storage volume application template, create PVC, specify pvc name size, pvc will be created automatically, and pvc must be supplied by storage class.

Why do you need headless service headless service?

When using Deployment, each Pod name is out of order and is a random string, so the Pod name is unordered, but it must be ordered in statefulset, each pod cannot be replaced at will, and the pod name remains the same after pod reconstruction. Pod IP is variable, so it is identified by the name of Pod. The pod name is an identifier that is unique to the pod and must be persistent, stable and valid. The headless service is used at this time, which can give each Pod a unique name.

Why do I need volumeClaimTemplate?

Persistent storage is used for stateful replica sets. For distributed systems, its most important feature is that the data is different, so each node cannot use the same storage volume, and each node has its own dedicated storage. However, if the storage volume defined in Pod template in Deployment is that all replica sets share one storage volume, the data is the same because it is based on template. Each Pod in statefulset needs its own proprietary storage volume, so the storage volume of statefulset can no longer be created with Pod template, so statefulSet uses volumeClaimTemplate, which is called volume application template, which generates a different pvc for each Pod and binds pv, thus realizing that each pod has dedicated storage. That's why you use volumeClaimTemplate.

Create:

$kubectl create-f nginx.yaml

Service "nginx" created

Statefulset "web" created

Take a look at these three Pod creation processes:

# the first one is to create a web-0

$kubectl get pod

Web-0 1/1 ContainerCreating 0 51s

# create a web-1 when you need web-0 running and ready

$kubectl get pod

Web-0 1/1 Running 0 51s

Web-1 0/1 ContainerCreating 0 42s

# create a web-2 when you need web-1 running and ready

$kubectl get pod

Web-0 1/1 Running 0 1m

Web-1 1/1 Running 0 45s

Web-2 1/1 ContainerCreating 0 36s

# the last three Pod are all running and ready

$kubectl get pod

NAME READY STATUS RESTARTS AGE

Web-0 1/1 Running 0 4m

Web-1 1/1 Running 0 3m

Web-2 1/1 Running 0 1m

PVC automatically created according to volumeClaimTemplates

$kubectl get pvc

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

Www-web-0 Bound pvc-ecf003f3-828d-11e8-8815-000c29774d39 2G RWO gluster-heketi 7m

Www-web-1 Bound pvc-0615e33e-828e-11e8-8815-000c29774d39 2G RWO gluster-heketi 6m

Www-web-2 Bound pvc-43a97acf-828e-11e8-8815-000c29774d39 2G RWO gluster-heketi 4m

If there is no StorageClass mechanism for dynamically supplying PVC in the cluster, you can also manually create multiple PV and PVC in advance. The manually created PVC names must conform to the StatefulSet naming rules created later: (volumeClaimTemplates.name)-(pod_name)

The Statefulset name is web three copies of Pod: the web-0,web-1,web-2,volumeClaimTemplates name is: www, then the automatically created PVC name is www-web [0-2], creating a PVC for each Pod.

Summary of the rules:

The pattern for matching Pod name (network identity) is: $(statefulset name)-$(serial number), such as the example above: web-0,web-1,web-2.

StatefulSet creates a DNS domain name for each Pod copy. The format of this domain name is $(podname). (headless server name), which means that services communicate through the Pod domain name instead of Pod IP, because when the Node where the Pod is located fails, the Pod will be moved to other Node, and the Pod IP will change, but the Pod domain name will not change.

StatefulSet uses the Headless service to control the domain name of Pod. The FQDN for this domain name is $(service name). $(namespace) .svc.cluster.local, where "cluster.local" refers to the domain name of the cluster.

According to volumeClaimTemplates, create a pvc,pvc naming rule matching pattern for each Pod: (volumeClaimTemplates.name)-(pod_name), such as volumeMounts.name=www, Pod name=web- [0-2] above, so the created PVC is www-web-0, www-web-1, www-web-2.

Deleting Pod does not delete its pvc, and manually deleting pvc automatically frees pv.

An example of how Cluster Domain, headless service name, and StatefulSet name affect the DNS domain name of StatefulSet's Pod:

Cluster Domain Service (ns/name) StatefulSet (ns/name) StatefulSet Domain Pod DNS Pod Hostname

Cluster.local default/nginx default/web nginx.default.svc.cluster.local web- {0..N-1} .nginx.default.svc.cluster.local web- {0..N-1}

Cluster.local foo/nginx foo/web nginx.foo.svc.cluster.local web- {0..N-1} .nginx.foo.svc.cluster.local web- {0..N-1}

Kube.local foo/nginx foo/web nginx.foo.svc.kube.local web- {0..N-1} .nginx.foo.svc.kube.local web- {0..N-1}

Start and stop order of Statefulset:

Orderly deployment: when deploying StatefulSet, if there are multiple Pod replicas, they will be created sequentially (from 0 to NPod 1) and all previous Pod must be in Running and Ready state before the next Pod runs.

Sequential deletion: when Pod is deleted, the order in which they are terminated is from NMel 1 to 0.

Orderly extension: when an extension operation is performed on a Pod, the Pod in front of it must be in the Running and Ready state, just like the deployment.

Statefulset Pod Management Policy:

After v1.7, the uniqueness of its identity is ensured by allowing the Pod sorting policy to be modified and through the .spec.podManagementPolicy field.

OrderedReady: the default setting for the above start and stop order.

Parallel: tells the StatefulSet controller to start or terminate all Pod in parallel and not wait for the previous Pod to become Running and Ready or terminate completely before starting or terminating another Pod.

StatefulSet usage scenarios:

Stable persistent storage, that is, Pod can still access the same persistent data after rescheduling, which is based on PVC.

Stable network identifier, that is, its PodName and HostName remain unchanged after Pod rescheduling.

Orderly deployment, orderly expansion, based on init containers.

Orderly contraction.

Update policy

In Kubernetes 1.7 and later, the automatic scrolling update feature of Pod, labels, source request/limits, and annotations is allowed to be configured or disabled through the .spec.updateStrategy field.

OnDelete: setting to the OnDelete,StatefulSet controller through the .spec.updatecontaingy.type field does not automatically update the Pod in the StatefulSet. The user must manually delete the Pod to enable the controller to create a new Pod.

RollingUpdate: automatic scrolling update of Pod is achieved by setting the .spec.updatebutty.type field to RollingUpdate, which is the default policy if .spec.updateStrategy is not specified.

The StatefulSet controller deletes and recreates each Pod in the StatefulSet. It will update each Pod at a time in the order of Pod termination (from maximum ordinal to minimum ordinal). You must wait for this Pod before updating the next Pod Running and Ready.

Partitions: partition the RollingUpdate update policy by specifying .spec.updateswimgy.rollingUpdate.partition. If partitions are specified, all Pod with partitions greater than or equal to the ordinal number of partitions are updated when the .spec.template of StatefulSet is updated.

All Pod with ordinal numbers less than the partition will not be updated and will be recreated even if they are deleted. If the .spec.updateroomy.rollingUpdate.partition of StatefulSet is greater than its .spec.replicas, updates to its .spec.template will not be propagated to Pod. In most cases, partitions are not required.

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.