文章目录
- pod控制器
- 概述
- 有状态和无状态
- Deployment
- DaemonSet
- SatefulSet
- 配置
- Job
- CronJob
- 总结
pod控制器
概述
-
Pod控制器及其功用
- Pod控制器,又称之为工作负载(workload),是用于实现管理pod的中间层,确保pod资源符合预期的状态,pod的资源出现故障时,会尝试进行重启,当根据重启策略无效,则会重新新建pod的资源。
-
pod控制器有多种类型:
-
ReplicaSet: 代用户创建指定数量的pod副本,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能。
- ReplicaSet主要三个组件组成:
- 用户期望的pod副本数量
- 标签选择器,判断哪个pod归自己管理
- 当现存的pod数量不足,会根据pod资源模板进行新建
帮助用户管理无状态的pod资源,精确反应用户定义的目标数量,但是RelicaSet不是直接使用的控制器,而是使用Deployment。
-
Deployment:工作在ReplicaSet之上,用于管理无状态应用,目前来说最好的控制器。支持滚动更新和回滚功能,还提供声明式配置。
- ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
-
DaemonSet:用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务。比如ELK服务
- 特性:服务是无状态的
- 服务必须是守护进程
-
StatefulSet:管理有状态应用
-
Job:只要完成就立即退出,不需要重启或重建
-
Cronjob:周期性任务控制,不需要持续后台运行
-
有状态和无状态
- 有状态:有实时的数据需要存储,集群服务中,把某一台服务器抽离出去,过一段时间再加入到集群中,如果服务集群无法正常工作(相互之间需要数据同步)
- 无状态:没有实时的数据需要存储,集群服务中,把某一台服务器抽离出去,过一段时间再加入到集群中,如果服务集群还是正常工作(相互之间不用数据同步)
Deployment
- 部署无状态应用
- 负责创建和管理ReplicaSet,并维护pod副本数量与期望值相同
- 负责创建和删除pod资源,多个pod副本是并行执行的,升级策略默认为滚动更新的方式
- 具有上线部署、副本设定、滚动升级、回滚等功能
- 提供声明式更新,例如只更新一个新的image
- 应用场景:web服务
kubectl create deployment test01 --image=nginx:1.14 --port=80 --replicsa=3 --dry-run=client -o yaml > deploy-demo1.yaml
DaemonSet
- 部署无状态应用
- 理论上可以在k8s所有node节点上创建相同的pod资源,无论node节点什么时候加入到k8s集群(需要考虑到污点和cordon不可调度的影响)
- 在DaemonSet资源清单配置中不需要设置pod副本数
- https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
SatefulSet
-
部署有状态应用
-
稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
-
稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
-
有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现
-
有序收缩,有序删除(即从N-1到0)
-
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
#前面是无头服务,实现稳定的网络标识
apiVersion: v1
kind: Service
metadata:name: nginxlabels:app: nginx
spec:ports:- port: 80name: webclusterIP: None #设置无头服务selector:app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:name: web
spec:selector:matchLabels:app: nginx # 必须匹配 .spec.template.metadata.labelsserviceName: "nginx"replicas: 3 # 默认值是 1minReadySeconds: 10 # 默认值是 0template:metadata:labels:app: nginx # 必须匹配 .spec.selector.matchLabelsspec:terminationGracePeriodSeconds: 10 #设置pod被删除的等待时间containers:- name: nginximage: registry.k8s.io/nginx-slim:0.8ports:- containerPort: 80name: webvolumeMounts:- name: wwwmountPath: /usr/share/nginx/htmlvolumeClaimTemplates: ##内置PVC控制模板- metadata:name: wwwspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "my-storage-class"resources:requests:storage: 1Gi
-
StatefulSet由以下几个部分组成:
- Headless Service(无头服务):用于为Pod资源标识符生成可解析的DNS记录。
- volumeClaimTemplates(存储卷申请模板):基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
- StatefulSet:用于管控Pod资源。
-
为什么要有headless?
- 在deployment中,每一个pod是没有名称,是随机字符串,是无序的。而statefulset中是要求有序的,每一个pod的名称必须是固定的。
- 当节点挂了,重建之后的标识符是不变的,每一个节点的节点名称是不能改变的。
- pod名称是作为pod识别的唯一标识符,必须保证其标识符的稳定并且唯一。
- 为了实现标识符的稳定,这时候就需要一个headless service 解析直达到pod,还需要给pod配置一个唯一的名称。
-
为什么要有volumeClaimTemplate?
- 大部分有状态副本集都会用到持久存储,比如分布式系统来说,由于数据是不一样的,每个节点都需要自己专用的存储节点。
- 而在 deployment中pod模板中创建的存储卷是一个共享的存储卷,多个pod使用同一个存储卷,而statefulset定义中的每一个pod都不能使用同一个存储卷,由此基于pod模板创建pod是不适应的,这就需要引入volumeClaimTemplate,当在使用statefulset创建pod时,会自动生成一个PVC,从而请求绑定一个PV,从而有自己专用的存储卷。
配置
kubectl create svc clusterip svc-test01 --tcp=80:80 --dry-run=client -o yaml > svc-test01.yaml
apiVersion: v1
kind: Service
metadata:name: svc-test01
spec:ports:- name: httpport: 80protocol: TCPtargetPort: 80selector:app: svc-test01type: ClusterIPclusterIP: None ##创建无头服务
status:loadBalancer: {}
kubectl create deployment deploy-test --image=nginx:1.14 --port=80 --replicas=3 --dry-run=client -o yaml > deploy-test.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:name: deploy-test
spec:serviceName: svc-test01replicas: 3selector:matchLabels:app: deploy-testtemplate:metadata:labels:app: deploy-testspec:containers:- image: nginx:1.14name: nginxports:- containerPort: 80
#升级
apiVersion: apps/v1
kind: StatefulSet
metadata:name: deploy-test
spec:serviceName: svc-test01replicas: 3selector:matchLabels:app: deploy-testtemplate:metadata:labels:app: deploy-testspec:containers:- image: nginx:1.15name: nginxports:- containerPort: 80
#扩容
apiVersion: apps/v1
kind: StatefulSet
metadata:name: deploy-test
spec:serviceName: svc-test01replicas: 6selector:matchLabels:app: deploy-testtemplate:metadata:labels:app: deploy-testspec:containers:- image: nginx:1.15name: nginxports:- containerPort: 80
#缩容
apiVersion: apps/v1
kind: StatefulSet
metadata:name: deploy-test
spec:serviceName: svc-test01replicas: 3selector:matchLabels:app: deploy-testtemplate:metadata:labels:app: deploy-testspec:containers:- image: nginx:1.15name: nginxports:- containerPort: 80
#绑定PVC
apiVersion: apps/v1
kind: StatefulSet
metadata:name: deploy-test
spec:serviceName: svc-test01replicas: 3selector:matchLabels:app: deploy-testtemplate:metadata:labels:app: deploy-testspec:containers:- image: nginx:1.15name: nginxports:- containerPort: 80volumeMounts:- name: pvcmountPath: /usr/share/nginx/html volumeClaimTemplates:- metadata:name: pvcspec:accessModes: [ "ReadWriteOnce" ]storageClassName: "nfs-client-storageclass"resources:requests:storage: 2Gi
Job
- job分为普通任务(Job)和定时任务(CronJob)
- 常用于运行那些仅需要执行一次的任务
apiVersion: batch/v1
kind: Job
metadata:name: job-test01namespace: default
spec:template:spec:containers:- name: busyboximage: busyboximagePullPolicy: IfNotPresentcommand:- /bin/sh- -c- "sleep 10; exit 0"restartPolicy: NeverbackoffLimit: 2
.spec.backoffLimit用于设置job失败后进行重试的次数,默认值为6。默认情况下,除非Pod失败或容器异常退出,Job任务将不间断的重试,此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到,作业将被标记为失败
apiVersion: batch/v1
kind: Job
metadata:name: job-test01namespace: default
spec:template:spec:containers:- name: busyboximage: busyboximagePullPolicy: IfNotPresentcommand:- /bin/sh- -c- "sleep 10; exit 1"restartPolicy: NeverbackoffLimit: 2
kubectl describe jobs.batch job-test01
CronJob
- 周期性任务,像Linux的Crontab一样。
apiVersion: batch/v1beta1
kind: CronJob
metadata:name: cronjob-test01namespace: default
spec:schedule: "*/1 * * * *"jobTemplate:spec:template:spec:containers:- name: busyboximage: busyboximagePullPolicy: IfNotPresentcommand:- /bin/sh- -c- "date; echo 123"restartPolicy: NeverbackoffLimit: 2
concurrencyPolicy: Allow
#声明了 CronJob 创建的任务执行时发生重叠如何处理(并发性规则仅适用于相同 CronJob 创建的任务)。spec仅能声明下列规则中的一种:●Allow (默认):CronJob 允许并发任务执行。
●Forbid:CronJob 不允许并发任务执行;如果新任务的执行时间到了而老任务没有执行完,CronJob 会忽略新任务的执行。
●Replace:如果新任务的执行时间到了而老任务没有执行完,CronJob 会用新任务替换当前正在运行的任务。startingDeadlineSeconds: 15
#它表示任务如果由于某种原因错过了调度时间,开始该任务的截止时间的秒数。过了截止时间,CronJob 就不会开始任务,且标记失败.如果此字段未设置,那任务就没有最后期限。successfulJobsHistoryLimit: 3 #要保留的成功完成的任务数(默认为3)failedJobsHistoryLimit:1 #要保留多少已完成和失败的任务数(默认为1)suspend:true
#如果设置为 true ,后续发生的执行都会被挂起。 这个设置对已经开始的执行不起作用。默认是 false。schedule: '*/1 * * * *'
#必需字段,作业时间表。在此示例中,作业将每分钟运行一次jobTemplate:
#必需字段,作业模板。这类似于工作示例
总结
- Pod 的 5 种控制器:
- Deployment
- 部署无状态应用
- 负责创建和管理 ReplicaSet,维护 Pod 副本数量与期望值相同
- 负责创建和删除 Pod 资源,多个 Pod 副本时是并行执行的,升级策略默认为滚动更新的方式
- DaemonSet
- 部署无状态应用
- 理论上可以在 K8S 所有 Node 节点上创建相同的 Pod 资源,无论 Node 节点什么时候加入到 K8S 集群(需要考虑到污点和cordon不可调度的影响)
- 在 DaemonSet 资源清单配置中不需要设置 Pod 副本数(replicas)
- StatefulSet
- 部署有状态应用
- 每个 Pod 名称都是唯一且固定不变的
- 每个 Pod 都可以有自己专属的持久化存储(基于PVC模板 volumeClaimTemplates 绑定PV实现的)
- 需要提前创建一个 Headless Service 资源(无头服务,ClusterIP可以为None),并在 StatefulSet 资源清单配置中使用 serviceName 字段关联 Headless Service
- 可以在 Pod 内通过 <Pod名称>.<svc名称>.<命名空间>[.svc.cluster.local] 格式解析出 PodIP。(基于 Headless Service 和 CoreDNS 实现的)
- 创建、滚动升级、扩容、缩容 Pod 都是有序进行的(默认为串行执行的,基于字段 .spec.podManagementPolicy: OrderedReady 实现的;字段值若设置为 Parallel,则为并行执行)
- 创建、扩容 是升序执行的(顺序为 Pod 标识号从 0 到 n-1)
- 滚动升级、缩容 是倒序执行的(顺序为 Pod 标识号从 n-1 到 0)
- Service 资源的类型: 4个常规类型 + 1个特殊类型
- ClusterIP NodePort LoadBalancer ExternalName + Headless Service
- Job
- 部署一次性的短期任务的Pod资源,Pod不会持久运行
- 任务正常完成后Pod容器会正常退出并不会再重启(restartPolicy需要设置为Never或OnFailure),且也不会重建Pod
- 如果任务执行异常导致Pod容器异常退出,会重建Pod重试任务,重试次数受 backoffLimit 字段配置影响(默认为任务失败后重试6次)
- CronJob
- 部署周期性的短期任务的Pod资源,Pod不会持久运行
- 任务正常完成后Pod容器会正常退出并不会再重启(restartPolicy需要设置为Never或OnFailure),且也不会重建Pod
- 使用必配字段 schedule 设置任务执行的周期表,格式为 “分 时 日 月 周”
- Deployment