-
pod控制器
- A：pod控制器类型
- ReplicaSet控制器
- A：ReplicaSet控制器介绍
- B：ReplicaSet控制器的使用
- Deployment控制器
- A：Deployment控制器的介绍和简单使用
- DaemonSet控制器
- A：Deployment控制器的介绍
- B：Deployment控制器的简单使用
- C：pod的共享字段介绍
♣一：Pod控制器
A：Pod控制器类型
通过yaml格式创建的pod资源我们手动delete之后，是不会重建的，因为这个属于自主式pod，不是属于控制器控制的pod。之前我们直接通过run启动是通过控制器来管理的，delete之后还能通过控制器来重构一个新的一模一样的pod，控制器会严格控制其控制的pod数量符合用户的期望
而且控制器管理端的pod是不建议直接delete的，可以通过修改控制器管理相应的pod的数量从而达到我们的预期。
pod控制器主要功能也就是带我们去管理端pod的中间层，并帮我们确保每一个pod资源始终处于我们期望的状态，例如pod里面的容器出现故障，控制器会去尝试重启容器，当一直重启不成功，就会基于内部策略来进行重新的编排和部署。
如果容器的数量低于用户的目标数据就会新建pod资源，多余则会终止。
控制器是一种泛称，真正的控制器资源有多种类型：
1：ReplicaSet：（带用户创建指定数量的pod副本，并确保pod副本数量一直处于满足用户期望的数量，另外ReplicaSet还支持扩缩容机制，而且已经替代了ReplicationController）
ReplicaSet的三种核心资源：
1：用户定义的pod副本
2：标签选择器
3：pod模板
ReplicaSet功能如此强大，但是我们却不能直接使用ReplicaSet，而且连k8s也建议用户不直接使用ReplicaSet，而是转而使用Deployment。
Deployment（也是一种控制器，但是Deployment不是直接替代了ReplicaSet来控制pod的，而是通过控制ReplicaSet，再由ReplicaSet来控制pod，由此Deployment是建构在ReplicaSet之上的，不是建立在pod之上的，除了控制ReplicaSet自身所带的两个功能之外，Deployment还支持滚动更新和回滚等强大的功能，还支持声明式配置的功能，声明式可以使得我们创建的时候根据声明的逻辑来定义，方便我们随时动态修改在apiservice上定义的目标期望状态）
Deployment也是目前最好的控制器之一
Deployment指用于管理无状态应用，指需要关注群体，无需关注个体的时候更加需要Deployment来完成。
控制器管理pod的工作特点：
1：pod的数量可以大于node节点数量，pod的数量不和node的数量形成精准匹配的关系，大于node节点数量的pod会通过策略分派不通的node节点上，可能一个node有5个，一个node有3个这样的情况，但是这对某些服务来说一个节点出现多个相同pod是完全没有必要的，例如elk的日志收集服务亦或者监控工具等，一个节点只需要跑一个pod即可来完成node节点上所有的pod所产生的日志收集工作，多起就等于在消耗资源
对于这种情况，Deployment就不能很好的完成，我既要日志收集pod数量每个节点是唯一的，又要保证一旦pod挂掉之后还能精准的从挂掉的pod上重构起来，那么就需要另外一种控制器DaemonSet。
DaemonSet：
用于控制运行的集群每一个节点只运行一个特定的pod副本，这样不仅能规避我们上面的问题，还能完成当新的节点加入集群的时候，上面能运行一个特定的pod，那这种控制器控制的pod数量就直接取决于你的集群的规模，当然pod模板和标签选择器依然是不能少的
Job
Job可以用于指需要在计划内按照指定的时间节点取执行一次，执行完成之后就退出，无需长期运行在后台，例如数据库的备份操作，当备份完成应当立即退出，但是还有特殊的情况，例如mysql程序连接数满了或者mysql挂了，这个时候job控制器控制的pod就需要把指定的任务完成才能结束，如果中途退出了需要重建来直道任务完成才能退出。Job适合完成一次性的任务。
Cronjob：
Cronjob和job的实现的功能类似，但是适合完成周期性的计划任务，面对周期性计划任务我们需要考虑到就是上一次任务执行还没有完成下一次的时间节点又到了应该怎么处理。
StatefulSet
StatefulSet就适合管理有状态的应用，更加关系个体，例如我们创建了一个redis集群，如果集群中某一个redis挂了，新起的pod是无法替代之前的redis的，因为之前的redis存储的数据可能被redis一起带走了。
StatefulSet是将没一个pod单独管理的，每一个pod都有自己独有的标识和独有的数据集，一旦出现故障新的pod加进来之前需要做很多初始化操作才能被加进来，但是我们对于这些有状态而且有数据的应用如果是出现故障需要重构的时候，会变得很麻烦，因为redis和mysql重构和主从复制的配置是完全不一样的，这就意味需要将这些内容编写脚本的形式放到StatefulSet的模板中，这就需要人为的去做大量的验证，因为控制器一旦加载模块都是自动完成的，可能弄不好数据就丢失了。
不管是k8s还是直接部署的应用，只要是有状态的应用都会面临这种难题，一旦故障怎么保证数据不会丢失，而且能快速用新的应用顶上来接着之前的数据继续工作，可能在直接部署的应用上完成了，但是移植到k8s上的时候将会面临的又是另外一种情况。
在k8s上还支持一种特殊类型的资源TPR，但是在1.8版本之后就被CDR取代了，其主要功能就是自定义资源，可以将目标资源管理成一种独特的管理逻辑，然后将这种管理逻辑灌注到Operator里面，但是这种难度会变的很大，以至于到目前支持这种形式的pod资源并不多。
k8s为了使得使用变得简单，后面也提供了一种Helm的工具，这个工具类似centos上的yum工具一样，我们只需要定义存储卷在哪里，使用多少内存空间等等资源，然后直接安装即可，helm现在已经支持很多主流的应用，但是这些应用很多时候都适用于我们的环境，所以也导致helm使用的人也不是很多。
♣二：ReplicaSet控制器
A：ReplicaSet控制器介绍：
我们可以通过kubectl explain rc（ReplicaSet的简写）
[root@www kubeadm]# kubectl explain rc 可以看到一级字段也我们看 KIND: ReplicationController VERSION: v1 DESCRIPTION: ReplicationController represents the configuration of a replication controller. FIELDS: apiVersion <string> APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources kind <string> Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds metadata <Object> If the Labels of a ReplicationController are empty, they are defaulted to be the same as the Pod(s) that the replication controller manages. Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata spec <Object> Spec defines the specification of the desired behavior of the replication controller. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status status <Object> Status is the most recently observed status of the replication controller. This data may be out of date by some window of time. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status spec： [root@www kubeadm]# kubectl explain rc.spec KIND: ReplicationController VERSION: v1 RESOURCE: spec <Object> DESCRIPTION: Spec defines the specification of the desired behavior of the replication controller. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status ReplicationControllerSpec is the specification of a replication controller. FIELDS: minReadySeconds <integer> Minimum number of seconds for which a newly created pod should be ready without any of its container crashing, for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready) replicas <integer> Replicas is the number of desired replicas. This is a pointer to distinguish between explicit zero and unspecified. Defaults to 1. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#what-is-a-replicationcontroller selector <map[string]string> Selector is a label query over pods that should match the Replicas count. If Selector is empty, it is defaulted to the labels present on the Pod template. Label keys and values that must match in order to be controlled by this replication controller, if empty defaulted to labels on Pod template. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors template <Object> Template is the object that describes the pod that will be created if insufficient replicas are detected. This takes precedence over a TemplateRef. More info: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller#pod-template [root@www kubeadm]#