pod控制器
pod控制器
pv pvc 动态pv
pod控制器：工作负载，workload，用于管理pod的中间层，确保pod资源符合预期的状态
预期状态：
1、副本数
2、容器的重启策略
3、镜像拉取策略
pod出现故障时的重启等等
pod控制器的类型：
1、replicaSet：指定pod副本的数量
三个组件：
（1）pod的副本数
（2）标签选择器，判断哪个pod归自己管理
（3）扩缩容
2、Deployment控制器，他是工作在replicaSet之上。管理无状态应用。目前是最好的控制器，可以支持滚动更新和回滚。他还能提供声明式配置
3、statefulSet：控制器的一种，管理有状态的应用，也可以设置副本数，可以扩缩容。pod的序号是固定的，重启之后，pod的名称也不会发生变化。有状态
4、DaemonSet：可以在所有节点部署一个相同的pod，他没有副本数。可以限制部署的节点。也是无状态的应用。服务必须是一个守护进程
5、Job：工作pod控制器，执行完成之后即刻退出，不要重启
6、Cronjob：周期性的定时任务控制器，不需要在后台持续运行
pod和控制器之间的关系：
1、controllers：管理控制器
pod通过label-------->selector进行关联
如无特殊需要可以不加这个字段
strategy
Type:Recreate
#在spec里加这个就代表每次有更新，都会把旧的pod全部停止，然后再启动新的实例。服务可能会短暂的中断
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
这是Deployment的默认更新策略
rollingUpdate：滚动更新
maxUnavailable: 25%升级过程中，新启动的pod数量不能超过期望pod数的25%
maxUnavailable: 25%升级过程中，新的pod启动好之后，销毁的旧的pod数量不能超过期望pod数量的25%
2、无状态应用，pod名称是无序的，任务所有pod都是一体的，共享存储NFS
所有deployment下的pod共享一个存储
statfulSet：有状态的应用。pod的名称都是有序的，所有的pod都是独立的，存储卷也是独立的
顺序0-n，delete删除也不会改变pod的序号，扩缩容也是有序的扩缩容
headless service：无头服务，没有clusterIP
必须要有动态的pvc
headless service：k8s集群当中一种特殊的服务类型，不分配ClusterIP给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.1.10
为什么要用headless？
有序，独立个体
deployment的pod是没有名称的，随机字符串，无序，他需要一个集中的clusterip来集中统一为pod提供网络
statefulset是有序的，pod的名称是固定的，重建之后pod的标识符也不变，pod的名称是唯一的标识符
系统直接通过pod名称解析ip地址
为什么要有volumeClaimTemplates?
有状态的副本把集群都会设计持久化存储，每个pod是独立个体，每个pod都有一个自己专用的存储点
statefluset在定义的时候就规定了每个pod是不能同一个存储卷，所以才需要动态pv
应用场景：
不是固定节点的应用，不是固定ip的应用
更新发布比较频繁
支持自动伸缩，节点的资源不够，可以自动扩容、
3、daemonSet确保每个节点都运行一个pod副本，当node加入集群，也会为他新增一个pod，当node节点从集群当中移除时，pod也会被回收
daemonSet不需要指定调度策略，默认会在每个节点创建一个pod，除非污点
我们也可以通过指定的方式，只把deamonset部署在指定的节点
没有副本数选择，不需要设置
控制器类型的资源创建方式：基于控制器创建的pod，delete只是相当于重启
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-deamon
labels:
app: nginx5
#提高代码的可读性，别人读，不同业务可以通过namespace隔离，命名时要根据业务专业命名
spec:
selector:
matchLabels:
app: nginx5
template:
metadata:
labels:
app: nginx5
spec:
containers:
- name: nginx
image: nginx:1.22
4、Job：job分为两类，job普通任务，定时任务cronjob
job的作用，执行只需 要一次性的任务
脚本需要执行，数据库迁移，视频解码
对于k8s系统来说，既然定义了job，你只需要执行一次，或者指定次数即可。不能一直运行
第一个：必须指定的容器策略onfailure never
第二个：执行失败的次数也是受限的，默认是6次
第三个：更新yaml文件，先删除任务，再更新。不能动态更新
apiVersion: batch/v1
kind: Job
metadata:
name: centos
spec:
template:
spec:
containers:
- name: centos
image: centos:7
command: ["/bin/bash","-c","test -e /etc/passwd"]
restartPolicy: Never
backoffLimit: 4
#运行任务失败的次数是4次，4次到了之后，reatartPolicy的策略，来进行容器的重启或者不重启
面试题：
容器化部署，部署过数据库没有？
数据库是核心资产，不会容器化部署
前端你们会容器化部署吗？
nginx可以容器化部署
5、cronjob：周期性任务，定时执行，和linux的crontab语法一模一样
分 时 日 月 周
应用场景：定时备份，通知作用。定时检测（结合探针一起做）
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello(随便起)
spec:
schedule: "*/1 * * * *"
concurrencyPolicy: Allow
#如果执行失败的任务的保留的个数，默认是1个
startingDeadlineSeconds: 15
#表示pod启动之后必须在一定时间内开始执行，如果超过15秒仍未运行，任务将不会运行，任务也会标记失败
successfulJobsHistoryLimit: 3
#保留成功的任务数，默认值就是3
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: centos:7
command: ["/bin/bash","-c","test -e /etc/passwd"]
restartPolicy: Never
backoffLimit: 4
总结：
五个都是控制器创建的pod
都是依赖于控制器
deployment：无状态应用，最好用的，也是最多的
statefulSet：有状态应用，有序的，独立的pod
daemonSet：无状态应用，不能定义副本数。每个节点都运行一个pod，可以指定节点
job：执行一次性的任务，必须要有重启的策略，同时默认失败次数6次，只有失败次数达到，重启才会生效
cronjob：定时任务
cronjob定期检测nginx的80端口是否存活tcpsocket */1 * * * *