pod 控制器：
pv pvc 动态pv
pod控制器：工作负载，workload，用于管理pod的中间层，确保pod资源符号预期的状态。
预期状态：
1，副本数
2，容器的重启策略
3，镜像拉取策略
pod出现故障时的重启等等。
pod控制器的类型：
1，replicaSet：指定pod副本的数量。
三个组件：
一，pod的副本数
二，标签选择器，颇多哪个pod归自己管理
三，扩缩容
2，Deployment控制器，他是工作在replicaSet之上。管理无状态应用。目前是最好的控制器。支持广东更新和回滚。提供声明式配置。
3，statefulSet：控制器的一种，管理有状态的应用，可以可以设置副本数，可以扩缩容。pod的序号的固定的，重启之后，pod的名称也不会发生变化。有状态
4，DaemonSet：可以在使用节点的部署一个pod，他没有副本数。可以限制部署的节点。也是无状态的应用。一般来说，服务必须的后台守护进程。 ingress logstash flannel
5，job：工作pod控制器，执行完成即可退出，不用重启，不需要重建
6，cronjob：周期的定时容器控制器。不需要在后台持续运行
pod和控制器之间的关系
1，controllers：管理控制器。
pod提供label------>selector进行关联
补充：
startegy：
type: Recreate
#每次有更新，都会把旧的pod全部停止，然后再启动新的实例。服务可能会短暂的终端。
无特殊需要，这个字段不要加
默认策略：
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
这是Deployment的默认更新策略
rollingUpdate:滚动更新。
maxSurge: 25%升级过程中,新启动的pod数量不能超过期望pod数的25%
maxUnavailable: 25%在升级的过程中，新的pod启动好后，销毁的就的pod的数量不能超过pod的25%
2，无状态应用，pod名称的无序的，认为所有pod都是一体的。共享存储NFS
sydeployment下的pod共享一个存储。
statefulSet：有状态的应用，pod的名称的有序的，所有的pod都是独立的。存储卷也是独立的。顺序0-n,delete删除也不会改变pod的序号。扩缩容也是有序扩缩容
创建一个有序的pod
特点：headless service：无头服务，没有clusterIP
必须要有动态的pvc
删除重启的名称不变
每一个pod都是独立的个体，扩缩容都是有序的
pv的删除和本身的策略有关，和pod删除无关
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地址。ip地址可能会变。
为什么要有volumeClaimTemplates：
有状态的副本把 集群会设计持久化存储，每个pod是独立个体，每个pod都有一个自己专用的存储点。
satefulset在定义的时候就规定看每个pod是不能同一个存储。所以才需要动态pv。
statefulset的应用场景：
不是固定节点的应用，不是固定ip的应用，
共享发布比较频繁
支持自动伸缩，节点的资源资源不够,可以自动扩容。
删除：基于控制器删除
kubectl delete statefulsets.apps web
3，daemonSet：确保每个节点上都运行一个pod副本。当node加入集群也会为他新增一个pod。当中node节点从集群当中移除时，pod也会被回收。
不能指定副本数。在每一个节点部署一个
每个节点上创建一个
在指定节点上创建
kubectl label nodes master01 ingeress=true
匹配标签来部署
daemonSet不需要指定调度策略，默认会在每个节点创建一个pod。除非污点。
我们也可以提供指定的方式，只把deamonset部署在指定的节点。
面试：daemonSe没有副本选择，不需要设置。
控制器类型的资源创建方式：基于控制器创建的pod，delete只是相当于重启，要测定删除pod，必须上传控制器。
4，job：job分为两类，job普通任务 定时任务cronjob。
job的作用，执行只需要一次性的任务。
脚本需要执行，数据库迁移，视频解码等等业务。
对于k8s系统来说，既然定义了是job,你只需要执行一次, 或者指定次数即可。不能一直允许。
第一个：必须指定容器的重启策略：OnFailure或者Never
第二个：执行失败的次数也是受限的。默认是6次，可以设置
达到限制之后才是根据restartPolicy的策略，来对容器进行重启或者不重启
第三个：重新yamI文件，先删除任务，再更新。不能动态更新。
面试：容器化部署，部署过数据库吗？核心组件不会容器化部署的。
前端你们会容器化部署吗？我们公司前端nginx就是容器化部署
5，cronjob：
周期性任务，定时执行，和linux的crontab一模一样，语法一样
分 时 日 月 周
应用场景：定时备份 通知作用。定时检测（结合探针一起做）
也需要给容器定义重启策略
查看定时任务
执行完的任务会被保留，但最多就保留3个
concurrencyPolicy: Allow
#如果执行失败的任务的保留的个数默认是1个
startjingDeadlineSeconds: 15
#pod启动之后必须在一 定的时间内开始执行，如果超过15秒没有运行，任务将不会运行，任务也会标记失败
successfuljobsHistoryLimit: 3
#保留成功的任务数，默认值就是3
可选字段
删除：基于控制器删除
总结：
五个都是控制器创建的pod
都是依赖于控制器
deployment：无状态应用，最好用，也是最多的
statefulSet：有状态应用，有序的，独立的pod
daemonSet：: 无状态应用，不能定义副本数。每个节点都运行一个pod。 可以指定节点。
job：执行一次性的任务，必须要有重启策略，同时默认失败次数6次，之一失败次数达到，重启才会生效
cronjob：定时任务，通知，备份或者探测。
cronjob定期检测nginx的80端口是否存活tcpsocker */1 * * * *
