kubernetes Pod 控制器
定义pod的资源清单一共有五个字段： Pod
apiVersion kind metadata spec status(只读)
那么在spec中内嵌的为Container的字段有：
spec :
containers:
nodeSelector:
restartPolicy:
always, Never, OnFailure
container:
name
image
imagePullPolicy: Always, Never, IfNotPresent
ports:
name
containerPort
livenessProbe
readinessProbe
lifecycle
ExecAction: exec
TCPSocketAction: tcpsocket
HTTPGetAction: httpget 哪个地址的哪个端口发起请求
那么下来我们说一下Pod控制器：
那么配置清单的配置，是定义pod内部的所需的资源，而后直接提交给apiserver，由apiserver转交给schelder完成调度，由目标节点启动相关的资源创建就完成了，那么在由yaml文件创建的pod在被删除的情况下会被重建吗？ 答案：是当然不会的。那么此次的行为称为自主式pod，是不由pod控制器重建的。
那么在定义pod的时候是很少用自主式的pod来进行创建的，一般都是由pod控制器来实现的，那么pod的创建被内嵌到了pod控制器中。
pod控制器的类型：
ReplicationController: 最早的k8s的控制工具，后来人们发现这个设计的目标过于庞大，不现实，目前废弃了这个功能。
ReplicaSet: 代用户创建指定数量的pod副本，并确保pod副本一直处于用户期望的数量状态，日过少了多退少补，而且还支持滚动更新，扩容缩容。
ReplicaSet的组件：一共由三个组件组成：
1.用户期望的pod副本数 2.标签选择器，以便pod方便管理属于自己的pod 3.pod模版，那么在pod当前的数量不符合期望值，那么根据模版进行补全
但是ReplicaSet并不是直接使用的pod控制器，或者说k8s并不建议使用ReplicaSet的控制器，
而是应该使用Deployment控制器，但是Deployment并不是直接控制pod而是基于ReplicaSet之上的，那么Deployment通过控制ReplicaSet来控制Pod，那么一定是Deployment一定是提供了比ReplicaSet更强大的功能,那么Deployment支持滚动更新等更多更请大的功能，而且还提供了声明式的配置，那么声明式的配置可以随时进行声明，可以随时改变我们在apiserver上的目标状态，只要那么资源支持动态的更新，运行时的修改，那么由了一个更为请大的接口，那么Deployment就是将来掌握的控制器之一，支持无状态应用最好的控制器。
注：pod的副本数和节点的数量并没有什么必然的关系，pod数量超过节点数的时候必然是不同的pod数分布在不同的节点上，或者一个节点上分布多个pod对象，那么对于pod内部的日志的信息的收集就比较麻烦，日志存在的信息是在节点上以存储卷映射的形式存于节点上的，
节点上日志的运作： 我们应该在每一个节点上收集节点和容器所创建的pod上的日志，他们通过卷的方式映射到节点上，
那么日志具体的应该怎么收集？
那么就引入了一个新的节点的控制器DaemonSet
这个进程没有终止的时候，忙着监听，
有时候我们需要对数据库做一个备份的操作，那么这个备份的操作，我们可以手动的启动一个程序运行也可以在k8s直接启动一个pod来进行，那么在备份结束pod退出的时候，我们就不需要启动它了，那么这种功能，相对于前几种控制器而言并不适合，那么我们只做一次完成才会退出，没完成那么叫做Job
那么Job作为控制器是这样控制节点的，那么在k8s集群上用户指定启动数量的pod资源，pod资源启动就会完成相应的任务，假如因为各种原因下任务没有完成，节点故障了，那么pod也就挂了，或者是因为其他的bug那么这个pod被删除了，那么pod本身的任务还存在，那么就会重构pod，如果pod任务完成，就正常的退出，那么pod就不需要被重建了。所以对pod而言，Job要不要重建的关键在于任务是否完成了！
但是Job只能执行一次的任务，Job帮我们确保pod中的任务是的确被完成的，那么有时候还会有周期性的工作，不同于Job。
Cronjob： 与linux上的任务相似，这是周期性的任务，每一次任务的运行都有周期性的退出，那么假如你的任务还没有完成那么pod退出了怎么办？ 所以Cronjob还会处理并解决这样的问题，那么Cronjob和Job与之前的控制器不相同的原因在于，前几种的控制器都要持续的运行而这两种不需要，另外Deployment只能用于管控无状态的应用，对那些关注群体，而不关注个体的那么就是用Deployment，
那么假如我们要管理的是 redis cluster 之间的组件，那么必然他们之间不可取代，那么他们之间是通过分布槽位的方式来进行分布式的，那么各个槽点之间是无法互相取代的，那么新的节点进行老的数据是无法相互覆盖的，那么这种情况下我们关注的是一个个体的行为。
那么对于Deployment而言就是群体性的行为，关注在于群体，而不是某个个体，当其中的某个个体失败或者被删除，可以迅速的备份相应的个体，那么在k8s的控制器中如果向关注点在个体，而不在群体就要使用另外的控制器。
StatfulSet : 能够实现管理每个应用，每个pod副本都是被单独管理的，它拥有自己独有的标记和数据集，一旦这个节点出现故障，那么在新的节点加入之前可能需要做很多初始化的操作，那么对于redis cluster其中的节点而言，那么当其中的一个节点挂机了之后，那么我们需要对节点之间做主从，对每个节点做主从，那么从节点怎么被恢复过来，可能我们需要很多个运维任务或者运维的操作过程来实现。
但是即使我们有StatfulSet,可以做pod的单独的管理，但是定义管理zoopkper ,redis 或者Msql 的主从复制，，那么StatfulSet更多的给我们提供了一种封装的控制器，这个封装的指的是我们需要人为的把我们手动做的操作，哪些复杂的执行的逻辑，定义成脚本，放置在StatfulSet的模版中，每一次一个节点的pod故障的时候会通过脚本快速的复制过来，有状态应用的托管在K8s上来说是及其麻烦的，要求是非常高，运维操作步骤是各不相同，没办法抽取他们的共同的特点，并定义一个模式来让他们工作，那么对每一种话应用来说都是单独的开发应用。
其实k8s支持一种特殊的操作，TPR ： Third Party Resources 第三方资源 ，从1.2的版本开始支持，但是在1.7又被废了因为有了更新的功能 CDR ： Custom Defined Resources 从1.7开始 用户的自定义资源。 那么这种方法可以把我们要管理的资源定义成一种独特的管理逻辑来实现，而后我们还可以借助 Operator : 封装 所以正真的有状态的应用托管于k8s之上还是考验能力。
那么在k8s难就难在每次使用的时候我们都要写配置清单才行，任何一系统如果不把用户当傻瓜的话，那么注定用户就不会太多，就不会有太多的市场占有率，那么K8s就提供了一种叫做Helm的东西,
Helm： 头盔 ，外壳 那么它可以用来做什么？ Helm就跟linux中的yum类似，那么在部署应用程序的时候，比如我们向在k8s上部署一个集群，那么我们就需要写配置清单，写半天，头疼阿 ～ ，那么有人写好了，我们直接Helm就可以了，我们只要传一个参数，指定规模的集群，Helm install 举例说明 ， 那么作为一个运维工程师，如果只靠Helm来进行部署应用，那么你就会成为下一个背锅的。开玩笑~ hahahahah
那么下来我们就看一下 ReplicaSet 示例：
那么我们来看一下它的用法，同样使用explain
[root@server1 ~]# kubectl explain rs
KIND: ReplicaSet
VERSION: extensions/v1beta1
DESCRIPTION:
DEPRECATED - This group version of ReplicaSet is deprecated by
apps/v1beta2/ReplicaSet. See the release notes for more information.
ReplicaSet ensures that a specified number of pod replicas are running at
any given time.
FIELDS:
apiVersion
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
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
spec
status
pod控制器的定义也是一个独立的对象，我们先来定义一个ReplicaSet 的模版
那么对Selector而言，有两种方式的选择的
[root@server1 ~]# kubectl explain rs.spec.selector
KIND: ReplicaSet
VERSION: extensions/v1beta1
RESOURCE: selector
DESCRIPTION:
Selector is a label query over pods that should match the replica count. If
the 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 replica set. More info:
https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
A label selector is a label query over a set of resources. The result of
matchLabels and matchExpressions are ANDed. An empty label selector matches
all objects. A null label selector matches no objects.
FIELDS:
matchExpressions <[]Object>
matchExpressions is a list of label selector requirements. The requirements
are ANDed.
matchLabels
matchLabels is a map of {key,value} pairs. A single {key,value} in the
matchLabels map is equivalent to an element of matchExpressions, whose key
field is "key", the operator is "In", and the values array contains only
"value". The requirements are ANDed.
那么下来我们就写一下ReplicaSet的资源定义的清单：
[root@server1 ~]# vim rs-demo.yaml
apiVersion: apps/v1 此时的apiVersion的版本改变了
kind: ReplicaSet
metadata:
name: myapp
namespace: default
spec:
replicas: 2
selector: 标签选择器
matchLabels: 选择标签的一个参数 以 key-value的键值存在
app: myapp
release: canary
template: 模版，定义pod的资源的模版
metadata:
name: myapp-pod
labels: 那么在模版中定义的标签一定要是选择器中可以选择的
app: myapp
release: canary
enviroment: qa
spec:
containers:
- name: myapp-container 名字 那么在speec中的控制器的名称是没有用的，是以控制器的名称+一串随机的字符数字
image: ikubernetes/myapp:v1 镜像
ports: 暴露的端口
- name: http
containerPort: 80 也可以在container下的参数中添加就绪性探测和存储性探测的检测
[root@server1 ~]# kubectl create -f rs-demo.yaml
replicaset.apps/myapp created
[root@server1 ~]# kubectl get rs
NAME DESIRED CURRENT READY AGE
myapp 2 2 2 18s
[root@server1 ~]# curl 10.244.2.35
Hello MyApp | Version: v1 | Pod Name
那么版本的改变，只有在重建的时候才会被改变新的版本