Shulou(Shulou.com)05/31 Report--

This article shows you how to analyze the Deployment, DaemonSet and StatefulSet of the pod controller in K8s. The content is concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Pod controller classification:

1 、 ReplicationController

2 、 ReplicaSet

3 、 Deployment

4 、 StatefulSet

5 、 DaemonSet

6 、 Job,Cronjob

7 、 HPA

Pod controller: generally consists of three parts

1. Tag selector

2. Expected number of copies (not required for DaemonSet controller)

3. Pod template

The deploy controller is built on top of the rs controller, and new features include:

1. Event and status view

2. Rollback

3. Version record

4. Pause and start

5. Support two automatic update schemes

Recreate delete and rebuild

RollingUpdate rollback upgrade (default)

Create deploy

$kubectl run-help

$kubectl run nginx-- image=nginx-- port=80-- replicas=2 # create directly with the command

$kubectl run nginx-image=nginx-port=80-dry-run-o yaml

ApiVersion: apps/v1kind: Deploymentmetadata: labels: run: nginx name: nginxspec: replicas: 1 selector: matchLabels: run: nginx template: metadata: labels: run: nginxspec: containers:-image: nginx name: nginx ports:-containerPort: 80

The deploy controller is automatically created when the rs controller is created, and both have the same tag selector

$kubectl get deploy

Nginx 1/1 1 1 7s

$kubectl get rs

How to modify the number of pod copies

1 、 kubectl edit deploy nginx

2. Kubectl scale deploy nginx-replicas=5

3. Modify yaml file

How to upgrade a pod image:

1. Modify yaml directly

2 、 kubectl edit deploy nginx

3. Kubectl set image deploy/nginx nginx=nginx:1.9-- record # upgrade and record to rollback. This method is recommended.

Rolling upgrade is the default policy for deployment pod upgrade. You can also change the default value.

You can view the default values with the command kubectl edit deploy nginx

Replicas: 3 selector: matchLabels: run: nginx minReadySeconds: 5 # cannot be seen by default. You need to manually add strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate

By default, when 6 pod replicas need to be upgraded: Kubernetes will terminate 1 instance (625% "1.5 instances, rounding down = 1), create 3 new instances (625%" 1.5 instances, round up = 2, and add 1 instance to make up for 1 terminated instance = 3 instances). At this time, a total of 8 copies will be run. Once the new pod is ready, it terminates two more instances from the old replica set to restore the deployment to the required number of replicas, and then repeats the process until the deployment is complete.

MinReadySeconds:Kubernetes will upgrade after waiting for the set time.

MaxSurge: the maximum number of POD that can be increased during the upgrade process than previously set

MaxUnavaible: the maximum number of POD that cannot provide service during the upgrade process

Rolling upgrade related commands

$kubectl set image deploy/nginx nginx=nginx:1.7.9-record

$kubectl set image deploy/nginx nginx=nginx-record

$kubectl rollout status deploy nginx # View upgrade status

$kubectl rollout pause deployment nginx # upgrade paused

$kubectl rollout resume deployment nginx # resume upgrade

$kubectl describe deploy nginx # View upgrade details

$kubectl rollout history deploy/nginx # View upgrade history

Deployment.extensions/nginx

REVISION CHANGE-CAUSE

4 kubectl set image deploy/nginx nginx=nginx:1.7.9-record=true

5 kubectl set image deploy/nginx nginx=nginx-record=true

$kubectl rollout history deployment nginx-revision=5

$kubectl rollout undo deployment/nginx-- to-revision=4 # rollback to the specified version

$kubectl rollout undo deployment nginx-deploy # rollback to the previous version

Explicitly specify rolling upgrade parameters

ApiVersion: apps/v1kind: Deploymentmetadata: labels: run: nginx name: nginxspec: replicas: 1 selector: matchLabels: run: nginx minReadySeconds: 5 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate template: metadata: labels: run: nginxspec: containers:-image: nginx name: nginx ports:-containerPort: 80

DaemonSet is used to run a copy of the daemon as a background process in each Kubernetes node. To put it bluntly, a copy of Pod is deployed on each node. When the node joins the Kubernetes cluster, Pod is automatically scheduled to run on that node.

Each node has a ds pod, and the newly joined node will automatically generate a ds pod

Ds pod is not controlled by scheduling policy

Use the DaemonSe scene:

1. Cluster storage daemons, such as glusterd and ceph, should be deployed on each node to provide persistent storage

2. Node monitoring daemons, such as Prometheus monitoring cluster, can run a node-exporter process on each node to collect the information of monitoring nodes.

3. Log collection daemons, such as fluentd or logstash, run on each node to collect the container's logs

Example:

Kind: DaemonSetapiVersion: extensions/v1beta1metadata: name: nginx-ds labels: k8s-app: nginxspec: template: metadata: labels: k8s-app: nginxspec: containers:-image: nginx:1.7.9 name: nginx ports:-name: http containerPort: 80

Stateless service (Stateless Service): all pod only need to share one persistent storage, not one persistent storage per pod, and the result of multiple instances responding to the same request is exactly the same

Stateful service (Stateful Service): each pod requires an independent persistent storage. For this type of resource, we usually expose the service by creating a service of type Headless Service. Setting clusterIP to None is a headless service.

1. Stateful services generally use pvc templates and storage classes to automatically generate a pair of pv and pvc for each pod to achieve persistent storage.

2. You can also create the pv manually and pair it with the pvc automatically generated by the volumeClaimTemplates in the StatefulSet.

Manually create pv for StatefulSet

1. Create two pv

ApiVersion: v1kind: PersistentVolumemetadata: name: pv001 # the second one is pv002 labels: release: stablespec: capacity: storage: 1Gi accessModes:-ReadWriteOnce persistentVolumeReclaimPolicy: Recycle hostPath: path: / tmp/data

2. Create headless service first.

ApiVersion: v1kind: Servicemetadata: name: nginxspec: ports:-port: 80 name: web clusterIP: None selector: app: nginx role: stateful

3. Create StatefulSet pod and use pv

ApiVersion: apps/v1beta1kind: StatefulSetmetadata: name: webspec: serviceName: "nginx" # use the headless service replicas: 2 template: metadata: labels: app: nginx role: stateful spec: containers:-name: nginx image: cnych/nginx-slim:0.8 ports:-containerPort: 80 name: web volumeMounts: -name: www mountPath: / usr/share/nginx/html volumeClaimTemplates:-metadata: name: www spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 1Gi

VolumeClaimTemplates automatically generates pvc and pairing automatically according to its corresponding pv, and the number is determined by replicas: 2.

Automatically generate pv and pvc using pvc templates and storage classes

1. Create a storage class

ApiVersion: storage.k8s.io/v1kind: StorageClassmetadata: name: course-nfs-storageprovisioner: fuseim.pri/ifs

2. Create headless service first.

ApiVersion: v1kind: Servicemetadata: name: nfs-webspec: ports:-port: 80 name: web clusterIP: None selector: app: nginx role: stateful

3. Use storage classes to create StatefulSet pod

ApiVersion: apps/v1beta1kind: StatefulSetmetadata: name: nfs-webspec: serviceName: "nfs-web" # use the headless service replicas: 2 template: metadata: labels: app: nfs-webspec: terminationGracePeriodSeconds: 10 containers:-name: nginx image: nginx ports:-containerPort: 80 name: web volumeMounts: -name: www mountPath: / usr/share/nginx/html volumeClaimTemplates:-metadata: name: www annotations: volume.beta.kubernetes.io/storage-class: course-nfs-storage spec: accessModes: ["ReadWriteOnce"] # storageClassName: course-nfs-storage uses the storage class resources: requests: storage: 1Gi

Two pairs of pv and pvc are automatically generated

The above content is how to analyze the Deployment, DaemonSet and StatefulSet of the pod controller in K8s. Have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to 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.