pod控制器的作用
1、动态pv和pvc
deployment是控制器
pod空气器:工作负载,workload用于管理pod的中间层,确保podi资源符合预期的状态
预期状态
1、·副本数
2、容器重启策略
3、镜像拉取策略
pod、出现故障时重启等等
pod的控制器类型
1、replicaset:指定pod的副本数量
三个组件:
pod的副本数
标签的选择器,判断哪个pod归自己管理
扩缩容
2deployment控制器,他是工作在repalicaset之上,管理无状态应用,目前是最好的控制器,支持滚动更新和回滚
提供声明式配置
3、statefulSet:也是控制器的一种,管理有状态的应用,也可以设置副本数,可以扩缩容,pod之间的序号是固定的,重启之后pod的名称也不会发生变化,有状态
4、DaemonSet:可以在所有节点部署一个pod,他没有副本数,可以限制部署的节点。也是无状态应用,服务必须是守护进程
ingress logstash flannel
5、job:工作pod控制器,执行完成即可退出,不要重启,不需要构建
6、cronjob:周期性的定时任务控制器,不需要再后台持续运行
pod与控制器之间的关系:
1、controllers;管理控制器。
pod通过label----->selector进行关联。
startegy:
rollingUpdata:
maxSurge:25%
maxUnavailable:25%
这是Deployment的默认更细策略
rollingUpdate:滚动更新
maxSurge:25%:升级过程中,新启动的pod数量不能超过期望pod数的25%
,不能超过25%
maxUnavailable:25%:升级过程中新的pod启动好之后,销毁的旧的pod数量不能超过期望pod25%
2、无状态应用;pod名称是无序的,认为所有pod都是一体的,包括共享存储NFS,
所有deployment下的pod都共享一个存储。
statfulSet:有状态的应用。pod名称有序的,所有pod都是独立的,存储卷也是独立的
顺序0-n,delete删除也不会改变pod的序号,扩缩容也是有序的扩缩容
headless-service:无头服务,没有clusterIp,必须要有动态pvc
apiVersion: v1
kind: Service
metadata:
name: nginx-web
spec:
ports:
- port: 80
targetPort: 80
clusterIP: ""
selector:
app: nginx1
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
labels:
app: nginx2
spec:
replicas: 3
selector:
matchLabels:
app: nginc-sts
serviceName: "nginx-web"
template:
metadata:
labels:
app: nginx2
spec:
containers:
- name: nginx
image: nginx:1.22
volumeMounts:
- name: html
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: html
spec:
accessModes: ["ReadWriteMany"]
storageClassName: "nfs-client-storageclass"
resources:
requests:
storage: 2Gi
headless service:k8s集群当中一种特殊的服务类型,不分配Cluseter给service:也不会负载均衡到后端的pod,DNS来提供服务的发现和访问
由于Clusterip的是空,k8s集群会给每个headless service中的pod创建一个dns记录
格式:pod-name.headless-service-name.namespace.svc.cluster.local.
记录了 web-0 nginx-web defaults 本地地址(pod的ip地址)
通过dns直接解析访问pod的IP地址
web-0 10.244.10 做一个地址映射
为什么要用healdless:
有序,独立个体
deployment的pod是没有名称的,随机字符串,无序,他需要一个集中的clusterip来集中统一为pod提供网络
statefulset是有序的,pod的名称是固定的,重建之后pod的标识符也不变,pod的名称是唯一的标识符
系统直接通过pod名称直接解析ip地址。 ip会不会变
为什么要有volumeClaimTemplates:
有状态的副本集群都会涉及持久化存储,每个pod的都是独立个体,每个pod都有一个自己的专用的存储点
statefulset在定义的时候就规定了每个pod是不能使用同一个存储卷,所以才需要动态pv
不是是固定节点的应用,不是固定ip的一个用
更新发布比较频繁
支持自动伸缩,节点的资源不过,可以自动扩容
4、job:分为两类 job普通任务 cronjob定时任务
常用于运行那些仅需要执行一次的任务
应用场景:数据库迁移、批处理脚本执行、视频解码业务
对于k8s系统来说,既然定义了job,只需要执行一次或者指定次数即可,不能一直运行。
第一点:必须要指定容器的重启策略 onfailure和Never
第二点:执行失败的次数也是受限的,默认是6次,但是可以指定用backoffLimit:
backoffLimit: 4 #允许失败的次数是4次,4次之后,restartPolicy策略,来进行容器的重启或者不重启。
第三点:更新yaml文件。必须要先删除任务,再更新,不能动态更新的。
容器化部署,部署过数据库吗:
数据库是核心资产,不会容器化部署
5、cronjob:周期性任务,像linux的crontab一样语法一样:分 时 日 月 周
应用场景:如通知、定时备份 定时检测(结合探针一块做)
总结:
这五个都是控制器创建的pod,都是依赖于控制器
deployment:典型的无状态的应用,最好用的,也是最多的
statefulSet:有状态应用,有序的独立的pod
daemonSet:无状态应用,不能定义副本数,每个节点都运行一个pod,也可以指定节点
job:执行一次性的任务,必须要有重启策略,同时注意默认失败次数为6次。只有失败次数达到了,重启策略才会生效
cronjob:定时任务
写一个yaml用cronjob定期检测80端口是否存活 ,在加上存活探针检测80端口,用到tcpSocker文章来源:https://www.toymoban.com/news/detail-794580.html
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
metadata:
labels:
app: hello
spec:
containers:
- name: hello
image: nginx:1.22
command: ["/bin/bash", "-c", "date; echo hello is ok"]
livenessProbe: #定义存活探针
tcpSocket:
port: 80
restartPolicy: Never
backoffLimit: 4 #允许任务失败的4次,4次后restartPolicy策略。来进行容器的重启或
不重启
~
~
~
文章来源地址https://www.toymoban.com/news/detail-794580.html
到了这里,关于pod控制器的作用的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!