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
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策略。来进行容器的重启或
不重启
~
~
~ 
