一、什么是 pod 的控制器
Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层
确保pod资源符合预期状态；pod的资源故障时会进行重启；
当重启策略无效时，则会重新新建pod的资源
二、pod控制器的多种类型
1、ReplicaSet
代用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。
ReplicaSet 的主要三个组件
1）用户期望的pod副本数量
2）标签选择器，判断哪个pod归自己管理
3）当现存的pod数量不足时，会根据pod资源模板进行新建
帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment
2、Deplayment
工作在ReplicaSet 之上，用于管理无状态应用，是目前来说最好的控制器；
支持滚动更新和回滚功能，还提供声明式配置。
ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。
3、DaemonSet
用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如ELK服务
特性：服务是无状态的
服务必须是守护进程
4、StatefulSet
管理有状态应用
5、Job
只要完成就立即退出，不需要重启或重建
6、CronJob
周期性任务控制，不需要持续后台运行
三、pod 与控制之间的关系
controllers：在集群上管理和运行容器的 pod 对象， pod 通过 label-selector 相关联。
Pod 通过控制器实现应用的运维，如伸缩，升级等。
1、Deployment
部署无状态应用
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景：web服务
通过陈述式生成声明式的yaml文件
kubectl create deployment nginx-dep --imae=nginx:1.15 --port=80 --replicas=1 --dry
查看控制器配置
kubectl edit deployment/nginx-deployment
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "1"
creationTimestamp: "2021-04-19T08:13:50Z"
generation: 1
labels:
app: nginx #Deployment资源的标签
name: nginx-deployment
namespace: default
resourceVersion: "167208"
selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
progressDeadlineSeconds: 600
replicas: 3 #期望的pod数量，默认是1
revisionHistoryLimit: 10
selector:
matchLabels:
app: nginx
strategy:
rollingUpdate:
maxSurge: 25% #升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
maxUnavailable: 25% #升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
type: RollingUpdate #滚动升级
template:
metadata:
creationTimestamp: null
labels:
app: nginx #Pod副本关联的标签
spec:
containers:
- image: nginx:1.15.4 #镜像名称
imagePullPolicy: IfNotPresent #镜像拉取策略
name: nginx
ports:
- containerPort: 80 #容器暴露的监听端口
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always #容器重启策略
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
......查看历史版本，升级，回滚
2、SatefulSet
部署有状态应用
稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
有序收缩，有序删除（即从N-1到0）
Headless 无头模式
k8s 中pod 因为故障导致重启或新建会导致pod名称和IP地址发生改变；(IP改变会导致数据丢失以及服务无法访问)
k8s 中的数据库的 ip 也会因此发生改变，为了避免这种情况；通过设置Headless无头模式
Headless 通过dns解析来让外部访问
headless 会定义好service的名称，分配时不会分配ip
为什么要有 volumeClainTempalte
实现K8S 里 DNS 功能的插件：
skyNDS
清单定义StatefulSet
拉取一个centos:7 镜像
倒叙删除
k8s 内部负载均衡是根据访问量来算的，所以可能会导致一直访问到同一个服务器
那是k8s内部的负载均衡 ，会根据资源占比进行调度，会调度到资源少的，请求少的pod
滚动更新
除了创建时是正序，其他如删除、更新时都是倒叙进行
DaemonSet
DaemonSet会在每个node节点都会创建；删除也是同时删除
Job
重启的是pod 不是容器
5、CronJob
可以用于进行周期性备份，把xx文件拷贝出来，存储到xxx
周期性创建pod
总结
创建pod的两种方式
自主式pod和以控制器创建的pod
什么是有状态、无状态？
无状态就是类似于nginx 的静态页面，一般不会进行改变；每次访问内容都是一样的
有状态则类似于数据库，每天都会进行改变；每次访问都是不一样的
声明式 == yaml文件
陈述式 == 命令
kafka消息队列
Pod 控制器
①deployment 部署无状态应用的管理RS 和 pod 创建Pod，主要是维护pod副本数量与期望状态一致
创建和删除pod是并行执行的；升级时也是 先创建一部分再删除一部分
②statfulset 部署有状态的应用时，每个pod的名称唯一且不变，每个pod 拥有自己专属的持久化存储（PV和PVC）
在 k8s 集群内部可以通过{pod_name}.{service_name}.{namespace}.svc.cluster.local 解析出pod 的IP（基于headless service 和 coreDNS）
在创建和pod时是有顺序的，串行执行；升级时也是串行执行，会删除旧的pod，再创建新pod；
删除和升级时是倒叙执行的（从标识符最大的 n-1 开始，一直到最小的 0）
③Daemonset 理论上在k8s 集群的所有node节点上创建相同的pod（无论node节点什么时候加入到k8s 集群），但是会受到node节点上污点影响
④部署一次性任务的pod，正常完成后容器立即退出并且不重启容器（restartpolicy 不设置Always），也不会重建异常完成后重试任务
重建次数根据 backofflimit 配置（默认为6次）
⑤CronJob 周期性部署任务的pod，正常完成后容器会立即退出，并不会重启容器（restartpolicy 不设置Always），也不不会重建pod
schedule 配置周期性的事件表分时日月周 * * * * *
无状态
常规service和无头服务的区别
扩展伸缩
可以通过 logs 和 describe 来排查pod的异常信息
html 页面的协议
SLB 负载均衡
网关：转发请求，获取信息
