问题：
此前使用配置清单创建Pod，直接在配置清单指明创建的pod是什么，然后提交给apiserver，由apiserver转交给schuduler完成调度，由目标节点的kubelete和容器引擎完成对pod和容器的创建与启动。如果我们把pod资源意外删除，他会重建吗？
答案：
不会。因为我们用手动配置清单创建出来的pod属于自主式pod。
不是由控制器控制管理的pod。
不是由控制器控制管理的pod，这种pod资源删除之后就没了。我们此前用kubectl run创建的pod，删除之后会被重建，因为它是属于控制器控制的pod，它不是我们手动的方式直接创建的，而是借由控制器代为管理的，控制器必须确保他控制的Pod数据严格符合期望。如果想要修改控制器控制的pod数量，不能通过删除资源来实现，而应该修改控制器的定义的副本数量。以后我们管理Pod资源，很少用自主式pod的方式，为什么此前还好强调自足式pod呢，主要是为了更加认清Pod配置清单的结构。后面控制器控制pod都是内嵌的Pod模板
（1）pod控制器类型：
deployment
statefulset
daemonset
job
Cronjob
（一）第一种控制器类型：deployment
（1）deployment控制器：用于部署无状态应用。
啥叫无状态：只关心pod‘数量’，称为无状态。
（2）功能：保持Pod的数量能够保持和期望状态一致。
具有副本设定、滚动升级、回滚等功能。
提供声明式更新，例如只更新一个新的image
（3）应用场景：web服务
（二）第二种控制器类型：statefulset
（1）stateful控制器：部署有状态应用
啥叫有状态：保持pod的启动顺序（例如：mysql主从关系，先启动主，在启动从）和唯一性（唯一的网络标识符、持久存储）
（2）功能：能够确保pod的有序性；
能够实现唯一的网络标识以及持久存储
备注：
statefulset控制器的pod是有数据有状态的，需要永久存储这些数据。
（3）应用场景：数据库、redis。
有状态和无状态的区别：
无状态：
1）deployment认为所有的pod都是一样的。
2）不用考虑顺序地要求
3）不用考虑在哪个node节点上运行
4）可以随意扩容和缩容
有状态：
1）实例之间有差别，每个实例都有自己的独特性，元数据不同
2）实例之间不对等的关系，以及依靠外部存储的应用
（三）第三种控制器类型：daemonset
（1）daemonset控制器：守护进程控制器。
（2）确保集群上的每个节点都能够运行一个pod的副本
特点：在每一个node上运行一个pod；新加入的node也同样会自动运行一个pod。
备注：
daemonset控制的pod与节点的数量和位置无必然关系，一个node节点上可能有多个deployment控制的pod，也可能一个也没有。
（3）应用场景：
在每个节点上运行监控daemonset。
在每个节点上运行日志收集daemonset
在每个节点上运行集群存储daemonset
示例：
用DaemonSet 控制器类型创建nginx pod资源，“没有指定副本replicats，它会根据node节点的个数创建”，如果再新加一个node节点，也会给新node节点创建pod。
备注：pod挂掉之后是否会立马生成新的pod
1）daemonset
一般用于实现系统级别后台任务。托管在k8s上的好处就是可以以守护进程的方式运行，down之后可以被控制器重构；
守护进程需要持续在后台运行。
2）无状态：
deployment关注群体，而不用关注个体，一般使用deployment。举个例子：我们养了一群鸡，某一天馋了，随机挑一个，红烧清蒸都是，吃完之后是不是少了一只，因此再选一只鸡苗养。我们只关系群体，不关系个体。谁挂了我们都可以迅速找一个新的pod去替代
3）有状态：
如果你养了三个宠物狗，比如哈士奇、泰迪、雪纳瑞。如果你的哈士奇被人宰了，是不是可以立马找一只一模一样的哈士奇来替代它。恐怕没那么容易，对于养宠物的人来说，每个个体都有特殊价值、特殊感情的。这个时候关注的是个体而不是群体。个体之间是很难相互替代的。
比如你用三个主机组建一个redis 集群。他们彼此之间可以取代吗。其实是不能或者很难的。因为老的生成的很多数据被带走了，新的进来它没有数据。我们这里关注的个体，每个个体都需要被单独对待的。statefulset能够管理由状态的应用，而且每个pod应用都是被单独管理的，每个pod都有自己独有的标识和数据集。一旦一个节点故障，加进来之前可能要做很多初始化的操作
