【云原生之K8s】 Pod控制器

---

---

一、Pod控制器及其功用

Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。

二、控制器的类型

ReplicaSet：代用户创建指定数量的Pod副本，确保Pod副本数量符合预期状态，并支持滚动式自动扩容和缩容功能

ReplicaSet只要三个组件组成：

• 用户期望的Pod副本数量
• 标签选择器，判断哪个Pod归自己管理
• 当现存的Pod数量不足，会根据Pod资源模板进行新建

帮助用户管理无状态的Pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment

Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，还提供声明式配置

DaemonSet：用于确保集群中的每个节点只运行特定的Pod副本，通常用于实现系统级后台服务
特性：服务是无状态的，服务必须是守护进程

StatefulSet：管理有状态应用

Job：只要完成就立即退出，不需要重启或重建

Cronjob：周期性任务控制，不需要持续后台运行

Pod与控制器之间的关系

• controllers：在集群上管理和运行容器的 pod 对象， pod 通过 label-selector 相关联。
• Pod 通过控制器实现应用的运维，如伸缩，升级等

1.Deployment

• 部署无状态应用
• 管理Pod和ReplicaSet
• 具有上线部署、副本设定、滚动升级、回滚等功能
• 提供声明式更新，例如只更新一个新的image
• 应用场景：web服务

vim nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx	
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

kubectl create -f nginx-deployment.yaml

kubectl get pods,deploy,rs
1
2
3

查看控制器

kubectl edit deployment nginx-deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2021-04-19T08:13:50Z"
  generation: 1
  labels:
    app: nginx					#Deployment资源的标签
  name: nginx-deployment
  namespace: default
  resourceVersion: "167208"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
  uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
  progressDeadlineSeconds: 600
  replicas: 3					#期望的pod数量，默认是1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%				#升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
      maxUnavailable: 25%		#升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
    type: RollingUpdate			#滚动升级
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx				#Pod副本关联的标签
    spec:
      containers:
      - image: nginx:1.15.4				#镜像名称
        imagePullPolicy: IfNotPresent	#镜像拉取策略
        name: nginx
        ports:
        - containerPort: 80				#容器暴露的监听端口
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always				#容器重启策略
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
......
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

查看历史版本

kubectl rollout history deployment nginx-deployment
1

2.StatefulSet

• 部署有状态应用
• 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
• 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
• 有序收缩，有序删除（即从N-1到0）

2.1 StatefulSet的组成

• Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
• volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
• StatefulSet：用于管控Pod资源。

为什么要有headless？
在deployment中，每一个pod是没有名称，是随机字符串，是无序的。而statefulset中是要求有序的，每一个pod的名称必须是固定的。当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。
为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

为什么要有volumeClainTemplate？
大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

2.2 常规service和无头服务区别

• service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
• Headless service :无头服务，不需要cluster-IP，直接绑定具体的Pod的IP

2.3 示例

vim nginx-service.yaml

apiVersion: v1  
kind: Service  
metadata:
  name: nginx-service
  labels:
    app: nginx  
spec:
  type: NodePort  
  ports:
  - port: 80
    targetPort: 80  
  selector:
    app: nginx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

kubectl create -f nginx-service.yaml
kubectl get svc
1
2

验证DNS解析

vim dns-test.yaml

apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

解析kubernetes和nginx-service名称

kubectl exec -it dns-test sh

nslookup kubernetes

nslookup nginx-service
1
2
3
4
5

可以解析成功

查看statefulSet的定义

KIND:     StatefulSet
VERSION:  apps/v1

DESCRIPTION:
     StatefulSet represents a set of pods with consistent identities. Identities
     are defined as: - Network: A single stable DNS and hostname. - Storage: As
     many VolumeClaims as requested. The StatefulSet guarantees that a given
     network identity will always map to the same storage identity.

FIELDS:
   apiVersion	<string>
   kind	<string>
   metadata	<Object>
   spec	<Object>
   status	<Object>

kubectl explain statefulset.spec
KIND:     StatefulSet
VERSION:  apps/v1

RESOURCE: spec <Object>

DESCRIPTION:
     Spec defines the desired identities of pods in this set.

     A StatefulSetSpec is the specification of a StatefulSet.

FIELDS:
   podManagementPolicy	<string>  #Pod管理策略
   replicas	<integer>    #副本数量
   revisionHistoryLimit	<integer>   #历史版本限制
   selector	<Object> -required-    #选择器，必选项
   serviceName	<string> -required-  #服务名称，必选项
   template	<Object> -required-    #模板，必选项
   updateStrategy	<Object>       #更新策略
   volumeClaimTemplates	<[]Object>   #存储卷申请模板，必选项
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

创建StatefulSet.yaml文件，一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate 组成。如下资源清单中的定义：

vim statefulSet.yaml

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  labels:
    app: myapp-svc
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: myapp-pod
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp
spec:
  serviceName: myapp-svc
  replicas: 3
  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:
  - metadata:
      name: myappdata
	  annotations:          #动态PV创建时，使用annotations在PVC里声明一个StorageClass对象的标识进行关联
        volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 2Gi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

**解析上例：由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源，所以需要先定义一个名为 myapp-svc 的 Headless Service 资源，用于为关联到每个 Pod 资源创建 DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod 资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。
**

创建pv

NFS节点

定义pv

创建statefulset

kubectl apply -f statefulSet.yaml
1

查看创建的无头服务myapp-svc

查看statefulset

查看pvc绑定

查看pv

查看pod信息

在创建的每一个Pod中，每一个Pod自己的名称都是可以被解析的

从上面的解析，我们可以看到在容器当中可以通过对Pod的名称进行解析到ip。其解析的域名格式如下：
(pod_name).(service_name).(namespace_name).svc.cluster.local

小结

无状态：

• deployment 认为所有的pod都是一样的
• 不用考虑顺序的要求
• 不用考虑在哪个node节点上运行
• 可以随意扩容和缩容

有状态：

• 实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
• 实例之间不对等的关系，以及依靠外部存储的应用。

常规service和无头服务区别

• service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
• Headless service：无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。

3.DaemonSet

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

DaemonSet 的一些典型用法：

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
• 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash。
• 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

示例

vim ds.yaml

apiVersion: apps/v1
kind: DaemonSet 
metadata:
  name: nginx-daemonset
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

kubectl apply -f ds.yaml

kubectl get pods
1
2
3

DaemonSet会在每个node节点都创建一个Pod

4.Job

ob分为普通任务（Job）和定时任务（CronJob）
常用于运行那些仅需要执行一次的任务
应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等业务

示例

vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4
1
2
3
4
5
6
7
8
9
10
11
12
13
14

参数解释
.spec.template.spec.restartPolicy该属性拥有三个候选值：OnFailure，Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never，否则Job将不间断运行。

.spec.backoffLimit用于设置job失败后进行重试的次数，默认值为6。默认情况下，除非Pod失败或容器异常退出，Job任务将不间断的重试，此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到，作业将被标记为失败。

5.CronJob

周期性任务，像Linux的Crontab一样。
周期性任务
应用场景：通知，备份

示例：每分钟打印hello

vim cronjob.yaml

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

cronjob其它可用参数的配置
spec:
concurrencyPolicy: Allow #要保留的失败的完成作业数（默认为1）
schedule: ‘*/1 * * * *’ #作业时间表。在此示例中，作业将每分钟运行一次
startingDeadlineSeconds: 15 #pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败
successfulJobsHistoryLimit: 3 #要保留的成功完成的作业数（默认为3）
terminationGracePeriodSeconds: 30 #job存活时间 默认不设置为永久
jobTemplate: #作业模板。这类似于工作示例

---