一、回顾
1、Pod是标准的kubernetes资源，因此其遵循为其资源清单配置定义的基本格式，包含：apiVersion，kind，metadata,spec，status(只读)
2、spec的内嵌字段
containers：
name
image
imagePullPolicy：Always，Never，IfNotPresent
ports：name，containerPort
livenessProbe
readinessProbe
liftcycle
ExecAction： exec
TCPSocketAction：tcpSocket
HTTPGetAction：httpGet
nodeSelector
nodeName
restartPolicy（重启策略）：Always，Never，OnFailure
二、pod控制器：前面介绍的创建pod的方式创建的为自主式pod，而不是控制器控制管理的pod，当我们删除后其不会再启动。
1、pod控制器用于实现代我们去管理pod的中间层，并帮我们确保每一个pod资源始终保持我们所定义或者所期望的目标状态，万一这个pod资源出现故障那么首先会尝试重启容器，如果一直重启有问题那其可能会基于某种策略进行重新编排。如果pod的副本数量低于用户所定义的目标数量那么他也会自动补全，若多余那么也会自动终止多余的资源。
2、ReplicaSet：pod控制器有多种类型，第一种为ReplicaSet：其核心作用在于，待用户创建指定数量的pod副本，并确保pod副本一直处于满足用户数量的状态，并且支持副本多退少补，并且支持自动扩缩容机制。ReplicaSet被称为是新一代的ReplicationController，在最早时候，k8s只有一种控制器叫ReplicationController，但是后来发现ReplicationController设计目标过于庞大，要一个来完成所有的功能不怎么现实，因此目前其基本已经废弃了，所以推荐使用ReplicaSet(其相当于是新一代的ReplicationController)。他主要是帮助用户管理无状态的pod资源，并确保其能够精确反应用户所定义的目标数量，其由三个组件组成：
a、用户定义的由其管控的pod副本有几个
b、标签选择器，怎么判定哪些pod是由自己管理的
c、pod资源模板：集群的现存的pod副本不够我们定义的期望数量时怎么办，一般是基于pod模板新建
3、Deployment ：k8s不建议我们直接使用ReplicaSet而是使用deployment，其也是一个控制器，比较诡异的是其工作在ReplicaSet之上，因此，deployment是直接通过控制ReplicaSet来控制pod，因此其能够提供比ReplicaSet更为强大的功能，比如ReplicaSet支持的扩缩容其也是支持的，而Deployment还支持滚动更新回滚等众多更为强大的功能，并且其还提供了声明式配置的功能，这种声明式配置使得我们将来创建资源时可以基于声明的逻辑来定义。我们那些所有更新的资源可以随时重新进行声明，随时改变我们在api server上定义的目标期望状态，只要资源支持动态运行时修改。因此其是帮我们管理无状态应用的目前来讲最好的控制器。
4、DaemonSet：用于确保集群每一个节点只运行一个特定的pod副本，因此他们通常是用来实现系统级别的后台任务，将其托管到k8s上的好处是可以用守护进程的方式运行它，并且当有新节点加入集群时他会自动在上面启动一个此类的pod副本。因此DaemonSet来讲你就不能定义所期望的数量，因为其数量不是取决于我们定义而是取决于集群规模。但是pod模板肯定是要存在的，因为只有有了pod模板才能在节点上建立起pod资源来。另外标签选择器也是需要的，毕竟每个节点上有没有符合我们所指定条件的pod资源是要考标签选择器来判定的。也可以设置只部分节点运行一个指定的pod副本。
5、无论是Deployment还是DaemonSet，他们都有以下特点：
a、这种服务是无状态的。
b、这种服务是守护进程类的，必须持续运行在后台，没有终止的这一刻。
6、Job控制器：我们k8s集群可以按照用户指定的数量启动指定数量的pod资源。这个pod资源启动起来后就可以执行其应该完成的任务。假如任务还没有完成的情况下出现异常问题导致pod被删除，但是其任务还没有完成的情况下其会重建pod，但是当其任务执行完成后正常退出的情况下就不会再进行重建。因此其要不要重建的前提是其任务是否完成。但是其只能执行一次性的作业。
7、Cronjob：周期性运行任务的控制器，和job一样
8、StatefulSet控制器：管理我们的有状态应用。像Deployment管理的是相同规格的无状态的群体，如nginx集群，而此控制器管理的为有状态的个体副本，比如redis 集群中的节点，其定义的每一个pod副本都是被单独管理的，他拥有自己独有的标识和独有的数据集，一旦这个节点出现故障，那么加进来可能要做很多操作，比如管理的redis集群中的单个节点宕机后需要将集群中故障节点的从节点设置为主节点。此时需要很多的运维任务或操作过程来实现，此时就需要进行定义。这个使用比较困难，需要很高的运维技能。
9、k8s还支持另一种资源TPR（Third Party Resources，第三方资源）：从1.2+版本开始支持，到1.7又被废了，因为其有了更新的功能，叫CDR（Custom Defined Resources，用户自定义资源）：从1.8+开始支持。用户可以自定义资源，可以将我们的运维操作技能封装进去，定义成一种特殊类型的资源，或者是把我们要管理的目标资源的管理方式定义成一种独特的管理逻辑来实现。而后，我们还可以借助于COR研发的一种Operator的东西来实现封装我们的运维技能，