目录
一、deployment控制器
二、statefulset控制器
1、验证数据可以持久化
2、验证删除后名称不会改变,数据还会一直存在
3、验证扩容的创建过程是升序串行执行,并且自动创建pv
4、验证滚动更新的时候也是升序执行,数据持久化还在
5、验证缩容的时候是倒序执行
6、验证statefulset管理的pod的名称 可以通过coredns解析出pod的ip
总结statefulset的特点
三、daemonset控制器
四、Job
五、CronJob
一、deployment控制器
Pod控制器,又称之为工作负载(workload),是用于实现管理pod的中间层,确保pod资源符合预期的状态,pod的资源出现故障时,会尝试进行重启,当根据重启策略无效,则会重新新建pod的资源。
//pod控制器有多种类型:
1、ReplicaSet: 代用户创建指定数量的pod副本,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能。
ReplicaSet主要三个组件组成:
(1)用户期望的pod副本数量
(2)标签选择器,判断哪个pod归自己管理
(3)当现存的pod数量不足,会根据pod资源模板进行新建
帮助用户管理无状态的pod资源,精确反应用户定义的目标数量,但是RelicaSet不是直接使用的控制器,而是使用Deployment。
Deployment:工作在ReplicaSet之上,用于管理无状态应用,目前来说最好的控制器。支持滚动更新和回滚功能,还提供声明式配置。
ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/
二、statefulset控制器
apiVersion: v1
kind: Service
metadata:
labels:
app: mysvc
name: mysvc
namespace: testapp
spec:
selector:
app: myapp
type: ClusterIP
clusterIP: None
常规service和无头服务区别
service:一组Pod访问策略,提供cluster-IP群集之间通讯,还提供负载均衡和服务发现。
Headless service:无头服务,不需要cluster-IP,而是直接以DNS记录的方式解析出被代理Pod的IP地址。
apiVersion: apps/v1
kind: StatefulSet
metadata:
labels:
app: sts01
name: sts01
namespace: testapp
spec:
serviceName: mysvc
replicas: 2
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- image: soscscs/myapp:v1
name: nginx
ports:
- containerPort: 80
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "nfs-client-storageclass"
resources:
requests:
storage: 1Gi
由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service 资源,
需要先定义一个 Headless Service 资源,用于关联到每个 Pod 资源创建 DNS 资源记录。
接着定义了一个StatefulSet 资源,它通过 Pod 模板创建了 3 个 Pod 资源副本,并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 1Gi 的专用存储卷。
1、验证数据可以持久化
2、验证删除后名称不会改变,数据还会一直存在
3、验证扩容的创建过程是升序串行执行,并且自动创建pv
4、验证滚动更新的时候也是升序执行,数据持久化还在
滚动更新为先删除1个pod 然后再创建一个新的pod
5、验证缩容的时候是倒序执行
验证缩容的时候pv和pvc不会删除
模拟只有一个pod了
模拟pod扩容 副本数为2了 现在是否会自动将pvc存储卷挂载到sts01-01中
6、验证statefulset管理的pod的名称 可以通过coredns解析出pod的ip
总结statefulset的特点
1、statefulset用于部署有状态的应用(有实时数据需要存储的应用)
2、部署statefulset之前,需要先创建一个headless service(表示clusterip为node的特殊service类型),statefulset的配置清单模板需要去指定servicename为headless service的名称。
3、statefulset创建的pod名称是固定不变的,且唯一的
4、statefulset的资源配置模板可以设置pvc模板,指定storageclassname字段值,可以引用storageclass资源,调用存储卷插件,动态创建pv
5、statefulset管理的pod有滚动更新和扩容和缩容功能,扩容的时候为升序执行,滚动更新和缩容的时候为降序执行。
6、statefulset管理的pod可以在k8s集群的pod中,基于headless service以及coredns实现对pod名称解析出podIP
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
annotations:
#动态PV创建时,使用annotations在PVC里声明一个StorageClass对象的标识进行关联
volume.beta.kubernetes.io/storage-class: nfs-client-storageclass
拓展:官方文档说明 关于statefulset的特点 https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/statefulset/
三、daemonset控制器
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: demo1
namespace: testapp
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
tolerations:
- operator: Equal
key: node-role.kubernetes.io/master
effect: NoSchedule
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
四、Job
Job分为普通任务(Job)和定时任务(CronJob)
常用于运行那些仅需要执行一次的任务
应用场景:数据库迁移、批处理脚本、kube-bench扫描、离线数据处理,视频解码等业务
https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
示例:
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
//参数解释
.spec.template.spec.restartPolicy该属性拥有三个候选值:OnFailure,Never和Always。默认值为Always。它主要用于描述Pod内容器的重启策略。在Job中只能将此属性设置为OnFailure或Never,否则Job将不间断运行。
.spec.backoffLimit用于设置job失败后进行重试的次数,默认值为6。默认情况下,除非Pod失败或容器异常退出,Job任务将不间断的重试,此时Job遵循 .spec.backoffLimit上述说明。一旦.spec.backoffLimit达到,作业将被标记为失败。
//在所有node节点下载perl镜像,因为镜像比较大,所以建议提前下载好
docker pull perl
kubectl apply -f job.yaml
kubectl get pods
pi-bqtf7 0/1 Completed 0 41s
//结果输出到控制台
kubectl logs pi-bqtf7
3.14159265......
//清除job资源
kubectl delete -f job.yaml
//backoffLimit
vim job-limit.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: busybox
spec:
template:
spec:
containers:
- name: busybox
image: busybox
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
restartPolicy: Never
backoffLimit: 2
kubectl apply -f job-limit.yaml
kubectl get job,pods
NAME COMPLETIONS DURATION AGE
job.batch/busybox 0/1 4m34s 4m34s
NAME READY STATUS RESTARTS AGE
pod/busybox-dhrkt 0/1 Error 0 4m34s
pod/busybox-kcx46 0/1 Error 0 4m
pod/busybox-tlk48 0/1 Error 0 4m21s
kubectl describe job busybox
......
Warning BackoffLimitExceeded 43s job-controller Job has reached the specified backoff limit
五、CronJob
周期性任务,像Linux的Crontab一样。
周期性任务
应用场景:通知,备份
https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
示例:
//每分钟打印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
//cronjob其它可用参数的配置
spec:
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: #必需字段,作业模板。这类似于工作示例
kubectl create -f cronjob.yaml
kubectl get cronjob
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 <none> 25s
kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1621587180-mffj6 0/1 Completed 0 3m
hello-1621587240-g68w4 0/1 Completed 0 2m
hello-1621587300-vmkqg 0/1 Completed 0 60s
kubectl logs hello-1621587180-mffj6
Fri May 21 09:03:14 UTC 2021
Hello from the Kubernetes cluster
//如果报错:Error from server (Forbidden): Forbidden (user=system:anonymous, verb=get, resource=nodes, subresource=proxy) ( pods/log hello-1621587780-c7v54)
//解决办法:绑定一个cluster-admin的权限
kubectl create clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous