pod控制器
1.概述
pod的控制器: 工作负载,workload,管理pod的中间层(对上apiserver,对下scheduler),确保pod符合预期的状态。pod出现故障时,会自动进行重启(根据重启策略),相当于重建新的pod资源,也可以理解为重启(回到pod的原始状态)
2.pod的控制器类型
2.1ReplicaSet
用户在创建pod时,指定pod的数量,只有基于控制器创建的pod才可以设置pod的数量(daemonset不属于这个范畴),支持自动扩容和缩容功能。
主要作用
- 满足用户期望的pod数量。
- 标签选择器,根据标签进行匹配pod,判断哪些pod归自己管理。
- pod数量不满足预期时,必须要根据资源模板重新创建。
- 帮助无状态的控制器管理pod,也可以管理有状态控制器部署的pod。
- ReplcaSet不是直接使用控制器,而是通过deployment,StatefulSet来间接的加入到pod的控制过程之中。
2.2 Deployment
无状态部署,也是目前使用最多的控制器,支持滚动更新和回滚功能,提供命令行配置。
无状态-->pod的名称是不固定的且无序
2.3 Daemonset
用该控制器部署的pod也是无状态,而且会在每一个节点上都部署一个pod,不能有pod数量字段(需要在每个节点都安装一个应用的情况下,使用DaemonSet进行部署),如果节点上有污点,其他拒绝部署的设置,那么控制器也会跳过这些pod。
StrategyType: Recreate #该字段可以不加
每次升级时,都会将所有的旧的pod先停止,然后再创建新的pod。
2.4 Satefulset
有状态部署,稳定的持久化部署,持久化存储,一般都是和pvc来共同实现。
持久化数据
稳定的网络标志:pod重新调度或者delete重启,pod的名称和hostname都不变,基于Headless service来实现内部的通信,即该控制器关联的servcie,不会分配cluster ip。
有状态:pod的名称不变,而且pod是按照序号来进行排列的,从0-n有序的收缩和删除。
用healess的原因
在deployment中,pod的名称无序的,随机的字符串。
Satefulset中,pod的名称是固定的,且pod的名称是有序的。即便是对pod进行重建,pod的名称还是不变的,必须要保证pod识别的唯一标识符是pod的名称,不再是ip地址。
通过headless service直接解析pod的名称就可以把流量转发到pod。
用pvc的原因
大部分有状态的pod都会用到持久化数据,对于分布式系统来说都是要求有序的。
主和从的数据是不一样的,每个节点都需要自己的专用存储节点,如果是在deployment,所有的pod使用pvc请求时,共用一个共享存储,但是satefulset,定义了pvc之后,每个都会有独享的专门数据目录,每个pod都会有一个自己的pvc去请求pv。
VCT: 定义所有pod的pvc请求模版,这个模版是分配给每一个pod都有一个pvc。
实例
headless的特点是没有cluster ip,无法进行负载均衡,不负责把流量转发到后台的每一个pod,适用于需要直接访问Pod实例的场景。
web-0.nginx-webdefault.svc.cluster.local
web-0 pod的名称
nginx-web: web-0匹配的service的名称
defaut: 命令空间
10.96.0.10: 是coredns在集群当中dns的解析服务器地址
以上三种控制器类型的区别:
Deployment和StatfulSet才有pod数量的字段,DaemonSet不能设置pod的数量
DaemonSet主要用于确保在集群中的每个节点上运行一个特定的Pod副本,适用于运行集群级别的守护进程,如日志收集器、监控代理或网络插件等。而Deployment管理无状态应用的部署,StatfulSet管理有状态应用的部署。
headless通常和StatfulSet一起使用,service没有cluster ip,每个pod都会有自己独立的数据卷。
2.5 job和cronjob
job: 普通任务,运行一次的任务,数据库迁移,批量处理脚本等等,视频解码控制器类型就是job,重启策略: Never和Onfailure。
cronjob:周期性执行的任务。和linux的crontab是一个意思。应用场景: 备份和通知。
实例
#job类型
apiVersion: batch/v1
kind: Job
metadata:
name: centos
spec:
template:
spec:
containers:
- name: centos
image: centos:7
command: ["/bin/bash","-c","test -e /opt/123.txt"]
restartPolicy: Never
backoffLimit: 2
#job失败的重试次数,默认是6次,跟重启策略是不冲突的
#重启策略是onfailure时,backofflimit就是非0状态码重启的次数
#cronjob类型
apiVersion: batch/vlbeta1
kind: CronJob
metadata:
name: centos-2
spec:
schedule: "*/2 * * * *"
#执行定时任务的时间
concurrencyPolicy: Allow
#保留失败的完成作业数,默认是1
successfulJobHistoryLimit: 3
#保留成功的任务数,默认是3
termainationGracePeriodSeconds: 30
#job存活的时间,默认不设置就是永久
jobTemplate:
#定义定时任务的执行时间
spec:
template:
spec:
containers:
- name: centos
image: centos:7
command: ["/bin/bash","-c","date;echo hello,world"]
restartPolicy: OnFailure