pod控制器
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，他没有副本数。可以限制部署的节点。也是无状态的应用。服务必须是守护进程
logstash flannel ingress
5、job: 工作pod控制器，执行完成即可退出，不要重启，不需要重建
6、cronjob:周期性的定时任务控制器。不需要在后台持续运行
pod和控制器之间的关系
1、controllers: 管理控制器。
pod通过label---------->selector进行关联
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
这是Deployment的默认更新策略
rollingUpdate: 滚动更新
maxSurge: 25% 升级过程中，新启动的pod数量不能超过期望pod数的25%
3个
25%
1个拉起来，然后再拉第二个。
3个，2个
nginx1----1
nginx1--11
nginx1----2
nginx1--22
nginx1----3
maxUnavailable: 25%:升级过程中，新的pod启动好后，销毁的旧的pod数量不能超过期望pod的25%
3个
nginx1----1
nginx1----2
nginx1----3
2、无状态应用，pod名称是无序的，任务所有pod的都是一体的。共享存储 NFS.
所有deployment下的pod共享一个存储。
statfulSet:有状态的应用。pod的名称是有序的，所有pod都是独立的。存储卷也是独立的。顺序0-n,delete删除也不会改变pod的序号。扩缩容也是有序扩缩容
0
1
headless service: 无头服务,没有clusterlP
必须要有动态的pvc
headless service: k8s集群当中一种特殊的服务类型。不分配ClusterlP给service,也不会负载均衡到后端的pod。
DNS来提供服务的发现和访问。
由于clusterip的是空，k8s集群会给每个headless service中的pod创建一个dns记录
格式: pod-name.headless-service-nama.namespace.svc.cluster.local
nginx-web web-0 defaults 本地地址 (pod的ip地址)
通过dns直接解析访问pod的IP地址
web-0 10.244.1.10
为什么要用headless:
有序。独立个体。
deployment的pod是没有名称的，随机字符串，无序。他需要一个集中的clusterip来集中统一为pod提供网络.
statefulset是有序的，pod的名称是固定的。重建之后pod的标识符也不变。pod的名称是唯一的标识符.
系统直接通过pod名称解析ip地址。
系统直接通过pod名称解析ip地址。ip地址不变? ------- IP变，名称不变
为什么要有volumeClaimTemplates:
有状态的副本吧集群都会涉及持久化存储，每个pod是独立个体，每个pod都有一个自己专用的存储点。
statefulset在定义的时候就规定了每个pod是不能同一个存储卷。所以才需要动态pv
不是固定节点的应用，不是固定ip的应用
更新发布比较频繁
支持自动伸缩，节点的资源资源不够，可以自动扩容
3、daemonSet: 确保每个节点上都运行一个pod副本。当node加入集群，也会为他新增一个pod.当node节点从集群当中移除时，pod也会被回收
daemonSet不需要指定调度策略，默认会在每个节点创建一个pod。除非污点。
也可以通过指定的方式，只把deamonset部署在指定的节点
没有副本数选择，不需要设置
控制器类型的资源创建方式：基于控制器创建的pod，delete只是相当于重启，要彻底删除pod，必须删除控制器
不要随便的delete
4、job:job分为两类，job：普通任务 定时任务：cronjob
job的作用，执行只需要一次性的任务，或者指定次数即可。不能一直允许
第一个: 必须指定的容器策略 onfailure never
第二个: 执行失败的次数也是受限的（默认是6次）
第三点: 更新yaml文件，先删除任务，再更新。不能动态更新
Q：容器化部署，部署过数据库没有?
A：数据库是核心资产，不会容器化部署
Q：前端你们会容器化部署吗?
A：nginx可以容器化部署
5、cronjob:
周期性任务，定时执行，和linux的crontab一模一样，语法一样
分时日月周
应用场景: 定时备份 通知作用。定时检测(结合探针一起做)
总结一下:
五个都是控制器创建的pod
都是依赖于控制器
deployment：无状态应用，最好用的，也是最多的
statefulSet：有状态应用，有序的，独立的pod
daemonSet：无状态应用，不能定义副本数。每个节点都运行一个pod。可以指定节点
job：执行一次性的任务。必须要有重启策略，同时默认失败次数6次，只有失败次数到达，重启才会生效
cronjob：定时任务。通知，备份或者探测