Docker$Kubernetes笔记---05---Pod调度&控制器

自动调度：pod运行在哪个Node节点上，完全由Scheduler经过算法分配

定向调度：NodeName、NodeSelector

亲和性调度与反亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity

污点（容忍）调度：Taints、Toleration

k8s提供了四种调度方式：

在默认情况下，一个pod被调度到哪个Node节点运行是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的，但是在实际工作中，我们想要控制某些pod调度到指定的Node节点，就需要用到pod调度

Pod调度---Pod调度概述

定向调度是通过在pod上声明NodeName或者NodeSelector，以此将pod调度到指定的节点上，但是定向调度属于强制调度，即使指定的Node节点不存在，也会向该节点进行调度，只不过pod运行失败而已；定向调度方式其实是直接跳过了Scheduler的调度逻辑，直接将pod调度到指定名称的节点

vim pod-nodename.yml

提示：node节点名称是在定义集群时指定的，名称通过下边命令查看kubectl get nodes

创建podkubectl create -f pod-nodename.yml

查看pod详细信息kubectl get po pod-nodename -n dev -o wide 

为了验证调度的准确性，我们指定一个不存在的nodeName节点，修改文件内容vim pod-nodename.yml

创建podkubectl create -f pod-nodename.yml 

查看pod详细信息kubectl get po pod-nodename -n dev -o wide

查看pod详细信息  PS：可以发现，定向调度属于强制调度，即使节点不存在，也会执行调度，只是pod会运行失败

实验：创建一个pod，并通过nodeName名称进行调度

nodeName调度介绍

nodeSelector用于将pod调度到添加了指定标签的node节点上，是通过label-selector机制实现的，也就是说在pod创建之前，会由Scheduler使用MatchNodeSelector调度策略进行label匹配，找出目标node，然后将pod调度到目标节点，该调度规则也是强制调度

实验：先为node节点打标签，然后创建一个pod，并通过nodeSelector进行调度

为node1与node2节点打标签kubectl label nodes node01 nodeenv=prokubectl label nodes node02 nodeenv=test

查看nodes标签kubectl get nodes --show-labels

创建pod-nodeselector.yml文件vim pod-nodeselector.yml

创建podkubectl create -f pod-nodeselector.yml 

查看pod详细信息kubectl get po pod-nodeselector -n dev -o wide

为了验证调度的准确性，我们指定一个不存在的标签节点，修改文件内容vim pod-nodeselector.yml

创建podkubectl create -f pod-nodeselector.yml

查看pod详细信息kubectl get po pod-nodeselector1 -n dev -o wide

提示：当前pod处于Pending挂起状态，应为没有找到相对应标签的节点；总结：定向调度方式使用比较方便，但是定向调度如果没有满足条件的Node，那么pod将运行失败，即使集群中还有可用的Node节点也没用，这就限制了使用场景

NodeSelector调度介绍

Pod调度---Pod定向调度

Affinity亲和性调度它可以优先选择满足条件的Node进行调度，如果没有，也可以调度到不满足条件的节点上，使调度更加灵活

nodeAffinity（node亲和性）：以node为目标，指定pod可以调度到哪些node上

podAffinity（pod亲和性）：以pod为目标，指定pod可以和哪些已存在的pod部署在同一个节点上

podAntiAffinity（pod反亲和性）：以pod为目标，指定pod不能和哪些pod部署在同一个节点上

kubectl explain pod.spec.affinity

Affinity主要分为三类，可通过下边命令查看：

亲和性：如果两个应用频繁交互，那就有必要利用亲和性让两个应用尽可能的在同一个节点，这样可以减少因网络原因带来的性能问题

反亲和性：当应用采用多副本部署时，那就有必要利用反亲和性让各个应用实例分散部署在不同的node节点，这样可以提高服务的高可用性

关于亲和性与反亲和性调度使用场景说明：

nodeSelectorTerms 节点选择列表 matchFields\t\t\t按节点字段列出的节点选择器要求列表 matchExpressions\t\t按节点标签列出的节点选择器要求列表（推荐） key \t\t\t键 values \t\t\t值 operator \t\t\t关系符（支持：Exists、DoesNotExist、In、NotIn、Gt、Lt）

requiredDuringSchedulingIgnoredDuringExecution    优先调度到满足指定的规则的Node节点，相当于硬限制

preference\t\t\t\t一个节点选择器项，与相应的权重相关联 matchFields\t\t\t按节点字段列出的节点选择器要求列表 matchExpressions\t\t按节点标签列出的节点选择器要求列表（推荐） key\t\t\t\t\t键 values\t\t\t\t值 operator\t\t\t\t关系符（支持：Exists、DoesNotExist、In、NotIn、Gt、Lt、weight 倾向权重，范围在1-100之间）

preferredDuringSchedulingIgnoredDuringExecution    Node节点必须满足指定所有规则才可以，相当于软限制

关于关系符的说明：matchExpressions:    - key: nodeenv               匹配存在标签的key为nodeenv的节点      operator: Exists    - key: nodeenv               匹配存在标签的key为nodeenv，且value在“zzz”或“yyy”的节点      operator: In      values: [\"zzz\

NodeAffinity的可配置属性可通过下边命令查看：kubectl explain pod.spec.affinity.nodeAffinity

新建yaml文件vim pod-nodeaffinity-required.yml

创建pod kubectl create -f pod-nodeaffinity-required.yml 

查看pod信息kubectl get po -n dev

查看pod描述信息kubectl describe po pod-nodeaffinity-required -n dev 

查看nodes节点标签kubectl get nodes --show-labels

修改pod-nodeaffinity-required.yml文件，选择一个存在的valus进行调度vim pod-nodeaffinity-required.yml

创建podkubectl create -f pod-nodeaffinity-required.yml 

查看pod描述信息kubectl describe po pod-node-required -n dev

实验：创建pod-nodeaffinity-required.yml文件，设置pod亲和度为硬限制

新建yaml文件vim pod-nodeaffinity-preferred.yml

创建podkubectl create -f pod-nodeaffinity-preferred.yml 

查看pod详细信息kubectl get po pod-nodeaffinity-preference created -n dev -o wide

PS：虽然没有找到要调度的标签节点，但是该pod被调度到一台正常的node节点上运行

实验：创建pod-nodeaffinity-preferred.yml 文件，设置pod亲和度为软限制

如果同时定义了nodeSelector和nodeAffinity，那么必须两个条件都要满足，pod才能运行在指定的node上

如果nodeAffinity指定了多个nodeSelectorTerms，那么只需要其中一个能够匹配成功即可

如果一个nodeSelectoryTerms中有多个matchExpressions，则一个节点必须满足所有的才能匹配成功

如果一个pod所在的node在pod运行期间其标签发生了改变，不在符合该pod的节点亲和性需求，则忽略此变化

nodeAffinity规则设置注意事项：

 Pod调度---Pod亲和性调度-nodeAffinity

requiredDuringSchedulingIgnoredDuringExecution:   #硬限制  namespaces:               #指定参照pod的namespace  topologyKey:              #指定调度的作用域  labelSelector:            #标签选择器    matchExpressions:       #匹配节点标签（推荐）      key:                  #键      values:               #值      operator:             #关系符（支持：Exists、DoesNotExist、In、NotIn、Gt、Lt）    matchLabels:            #指多个matchExpressions映射内容

硬限制

preferredDuringSchedulingIgnoredDuringExecution:   #软限制  podAffinityTerm:            #选项    namespaces:               #指定参照pod的namespace    topologyKey:              #指定调度的作用域    labelSelector:            #标签选择器      matchExpressions:       #匹配节点标签（推荐）        key:                  #键        values:               #值        operator:             #关系符（支持：Exists、DoesNotExist、In、NotIn、Gt、Lt）      matchLabels:            #指多个matchExpressions映射内容    weight:                   #倾向权重，在范围1-100之间

软限制

如果指定kubernetes.io/hostname  #以node节点名称为区分范围

如果指定beta.kubernetes.io/os   #以node节点的操作系统类型来区分范围

topologyKey指定调度的作用域说明：

通过下边命令可以查看podAffinity的可配置项kubectl explain pod.spec.affinity.podAffinity

podAffinity主要实现以pod为参照，实现让新创建的pod与被参照的pod运行在同一个节点上

创建一个参照的podvim pod-podaffinity-target.yml

创建podkubectl create -f pod-podaffinity-target.yml 

查看pod详细信息，并显示标签 kubectl get po pod-podaffinity-target -n dev -o wide --show-labels

创建pod，并参照pod-podaffinity-target的标签进行调度vim pod-podaffinity-required.yml

创建podkubectl create -f pod-podaffinity-required.yml 

查看pod详细信息；PS：发现pod状态属于Pending（挂起）状态kubectl get po pod-podeaffinity-required -n dev -o wide

删除该pod，并重新分配节点进行调度kubectl delete -f pod-podaffinity-required.yml

修改配置文件，指定一个存在的标签值进行调度；PS：这个标签值可以只写values: [\"pro\"]；这里或者的关系，符合其中一个即可vim pod-podaffinity-required.yml

查看pod详细信息kubectl get po pod-podaffinity-required -n dev -o wide

PS：发现该pod已经被调度到所倾向的pod节点

实验：接下来以硬限制演示调度方式

Pod调度---Pod亲和性调度-podAffinity

podAntiAffinity（反亲和性调度）主要实现以运行的pod为参照，让新创建的pod跟参照的pod不在同一个区域中

podAntiAffinty的配置属性与上边podAffinity配置属性是一样的，就不重复讲解了。

查看当前pod的标签kubectl get po pod-nodeaffinity-target -n dev --show-labels

创建pod-podantiaffinity-required.ymlvim pod-podantiaffinity-required.yml

创建podkubectl create -f pod-podantiaffinity-required.yml

查看pod详细信息kubectl get po pod-podantiaffinity-required -n dev -o wide

提示：可以发现，该pod被调度到了node2节点上

实验：继续使用上一个案例中的pod-podaffinity-target作为参照，配置pod反亲和性调度

Pod调度---Pod反亲和性调度-podAntiAffinity

前面的调度方式都是站在pod的角度上，通过在pod上添加属性，来确定pod是否要调度到指定的node上，其实我们也可以站在node的角度上，通过在node上添加污点属性，来决定是否允许pod调度过来；node被设置上污点以后，就和pod之间存在了一种相互排斥的关系，进而拒绝pod调度进来，甚至可以将已经存在的pod驱逐出去。

PreferNoSchedule：k8s将尽量避免把pod调度到具有该污点的node上，除非没有其他节点可调度

NoSchedule：k8s将不会把pod调度到具有该污点的node上，但不会影响当前node上已经存在的pod

NoExecute：k8s将不会把pod调度到具有该污点的node上，同时也会将node上已经存在的pod隔离

污点的格式：key=value:污点，key和value是污点的标签，目前支持如下三个污点：

设置污点kubectl taint nodes node1 key=value:污点

去除污点kubectl taint nodes node1 key:污点-

去除所有污点kubectl taint nodes node1 key-

使用kubectl设置和去除污点的命令实例如下

1. 为了演示污点的效果更加明显，暂时停止node2节点，node2节点关机即可

2. 为node1节点设置一个污点：tag=abc:PreferNoSchedule；然后创建pod1

3. 修改node1污点为：tag=abc:NoSchedule；然后创建pod2

4. 修改node1污点为：tag=abc:NoExecute；然后创建pod3

实验步骤

查看node节点状态kubectl get nodes

为node1设置污点为PreferNoSchedulekubectl taint nodes node1 tag=abc:PreferNoSchedule

查看node1污点信息kubectl describe nodes node1

创建pod1kubectl run taint1 --image=nginx:1.17.1 -n dev

为node1取消PreferNoSchedule污点，并重新设置污点为NoSchedulekubectl taint nodes node1 tag:PreferNoSchedule-kubectl taint nodes node1 tag=abc:NoSchedule

创建pod2kubectl run taint2 --image=nginx:1.17.1 -n dev

查看pod信息  PS：可以发现当前的pod状态为Pending（挂起状态），而原有的pod并没有受到影响kubectl get po -n dev

为node1取消NoSchedule污点，并重新设置污点为NoExecutekubectl taint nodes node1 tag:NoSchedule-kubectl taint nodes node1 tag=abc:NoExecute

创建pod3节点kubectl run taint3 --image=nginx:1.17.1 -n dev

查看pod状态kubectl get po -n dev

使用kubeadm搭建的集群，默认就会给master节点添加一个污点，所以pod不会被调度到master节点kubectl describe nodes master

实验描述：

Pod调度---Pod调度污点-Taints

上章节讲解了污点的作用，可以通过在node节点添加污点用于拒绝pod调度上来，但如果我们非要将一个pod调度到一个有污点的node上，通过容忍（忽略）可以实现

新增配置文件vim pod-toleration.yml

创建podkubectl create -f pod-toleration.yml

查看pod详细信息kubectl get po -n dev -o wide

实验：上章节我们为node1节点打上了一个NoExecute的污点，此时pod是调度不上去的，我们通过为pod添加容忍，然后将pod调度到node1节点

Pod调度---Pod调度容忍-Toleration

自主式pod：k8s直接创建出来的pod，这种pod删除后就没有了，也不会重建

控制器创建的pod：通过控制器创建的pod，这种pod删除了还会自动重建

在k8s中，pod的创建方式分为两类

pod控制器是管理pod的中间层，使用了pod控制器之后，我们只需要告诉pod控制器，需要多少个什么样的pod就可以了，它就会创建出满足条件的pod，并确保每一个pod处于用户期望的状态，如果pod在运行中出现故障，控制器会基于指定的策略重新启动或重建pod

Pod控制器

ReplicationController：比较原始的pod控制器，目前已经被废弃，由ReplicaSet代替

ReplicaSet：保证指定数量的pod运行，并支持pod数量变更，镜像版本变更

Deployment：通过控制ReplicaSet来控制pod，包含ReplicaSet所有功能，还支持滚动升级，版本回退

Horizontal Pod Autoscaler：可以根据集群负载自动调整pod数量，实现pod容缩

DaemonSet： 确保全部（或者一些）Node 上运行一个 Pod 的副本，当有 Node 加入集群时，也会为他们新增一个 Pod ，当有 Node 从集群移除时，这些 Pod 也会被回收，删除 DaemonSet 将会删除它创建的所有 Pod

Job：它创建的pod只要完成就立即退出

在k8s中，pod控制器的种类有很多，每种pod控制器的应用场景都不一样，常见的有下面这些

服务类容器通常持续提供服务，需要一直运行，比如 **http server**，**daemon** 等 

工作类容器则是一次性任务，比如批处理程序，完成后容器就退出 

容器按照持续运行的时间可分为两类：服务类容器和工作类容器

Cronjob：它创建的pod会周期性的执行，用于执行周期性任务（常用在数据备份工作）

StatefulSet：管理有状态应用

Pod控制器---Pod控制器概述

ReplicaSet的主要作用是保证一定数量的pod能够正常的运行，它会持续监听这些pod的运行状态，一旦pod发生故障，就会重启或重建pod，同时还支持对pod数量的扩缩容和版本镜像的升级

创建rs-replicaset.yml文件vim rs-replicaset.yml

创建podkubectl create -f rs-replicaset.yml 

查看pod详细信息kubectl get po -n dev

查看pod控制器详细信息kubectl get rs rs-replicaset -n dev -o wide

ReplicaSet的资源清单文件介绍：在下面配置中，需要了解的配置项是spec下面的配置项

通过edit（配置文件形式）可直接修改pod的副本数量kubectl edit rs rs-replicaset -n dev

直接根据需求修改pod的副本数量即可replicas: 6

第一种方式

直接通过scale命令修改rs的副本数量，--replicas=副本数量kubectl scale rs rs-replicaset --replicas=3 -n dev

第二种方式

ReplicaSet 扩缩容功能

通过edit（配置文件形式）可直接修改镜像版本kubectl edit rs rs-replicaset -n dev

查看rs详细信息kubectl get rs rs-replicaset -n dev -o wide

通过命令修改：set image rs rs名称 容器名=镜像版本 -n namespacekubectl set image rs rs-replicaset nginx=nginx:1.17.1 -n dev

ReplicaSet 镜像版本升级

kubectl delete rs rs-replicaset -n dev

查看rs信息kubectl get rs -n dev

命令删除方式

kubectl delete -f rs-replicaset.yml

配置文件删除方式

使用delete命令可以删除此rs以及它管理的所有pod，也可以通过配置文件删除；删除的过程先将pod数量调整为0，然后在执行删除pod操作，在删除rs

删除ReplicaSet

Pod控制器---Pod控制器-ReplicaSet（RS）

为了更好的解决服务编排问题，k8s在v1.2版本开始，引入了Deployment（Deploy）控制器，该pod控制器不会去直接管理pod，而是通过管理ReplicaSet来间接的管理pod，所以Deployment比ReplicaSet功能更强大

支持ReplicaSet所有功能

支持发布的停止、继续

支持版本滚动更新和版本回退

Deployment功能如下

Deployment的资源清单文件介绍：

通过deployment.yml文件创建基本的podvim deployment.yml

创建podkubectl create -f deployment.yml 

查看deploy详细信息kubectl get deploy -n devkubectl get deploy -n dev -o widePS：UP-TO-DATE：最新版本的pod数量；AVAILABLE：当前可用的pod数量

查看rs控制器信息，应为deploy通过控制rs管理pod，所以rs控制器也会被创建出来kubectl get rs -n dev PS：rs控制器的名称是在deploy基础上随机添加

查看pod信息kubectl get po -n devPS:pod名称是在rs基础上随机添加

Pod控制器---Pod控制器-Deployment基础

Deployment控制器在对pod进行扩缩容时，可以通过命令与配置文件方式实现

通过命令扩容pod数量kubectl scale deploy deployment --replicas=6 -n dev

通过edit（修改配置文件）方式缩减pod数量kubectl edit deploy deployment -n dev

Pod控制器---Pod控制器-Deployment扩缩容

Recreate：重建更新策略，一次性将所有旧版本pod全部重建成新版本pod

RollingUpdat：滚动更新策略（默认策略），先删除一部分旧版本pod，在更新成新版本pod

Deployment支持两种镜像更新的策略：通过strategy属性进行配置

修改deployment.yml文件，在spec属性下添加Recreate策略vim deployment.yml

更新podkubectl apply -f deployment.yml

更新镜像版本kubectl edit deploy deployment -n dev

第一步：会将运行的pod先终止（Terminating）

第二步：pod接下来处于等待状态（Pending）

第三步：重新创建容器

第四步：新的容器被创建且以成功运行（Running ）

观察pod的重建过程   PS：在开一个终端动态观察pod的信息kubectl get po -n dev -w

查看镜像版本kubectl get deploy -n dev -o wide

Recreate：重建更新策略配置

修改deployment.yml文件，在spec属性下设置RollingUpdat策略vim deployment.yml

另外一个终端动态查看pod信息kubectl get po -n dev -wPS：这里起了三个新的pod，依次先起一个然后再关闭一个

更新镜像版本kubectl edit deploy deployment -n devPS：动态观察pod滚动更新过程；当pod滚动更新后，rs也会随之跟着更新，原有的rs中的pod会被删除

查看rs信息kubectl get rs -n dev PS：原有的rs并不会删除，用于做版本回退

RollingUpdat：滚动更新策略（默认策略）

Pod控制器---Pod控制器-Deployment更新策略

status        #显示当前升级状态

history       #显示升级历史记录

pause         #暂停版本升级过程

resume      #继续已经暂停的版本升级过程

restart        #重启版本升级过程

undo           #回滚到上一级版本（可以通过--to-revision回滚到指定版本）

kubectl rollout: 版本升级相关功能，支持下面的选项：

deployment支持版本升级过程中的暂停、继续、回退等功能，具体功能如下：

显示当前升级版本的状态kubectl rollout status deploy deployment -n dev

显示升级历史记录kubectl rollout history deploy deployment -n dev

为了让效果更加明显，我们可以删除该pod，在重新通过--record创建podkubectl delete -f deployment.yml 

创建podkubectl create -f deployment.yml --record

再次更新镜像版本kubectl edit deploy deployment -n dev

查看升级历史记录kubectl rollout history deploy deployment -n dev

查看当前所有版本（通过rs可以查看）kubectl get rs -o wide -n dev

查看当前使用版本（查看deploy）kubectl get deploy -o wide -n dev

查看当前使用的版本kubectl get deploy -o wide -n dev

查看升级历史记录kubectl rollout history deploy deployment -n devPS：发现没有1版本了，多了个4版本，4版本就是原先的1版本

Pod控制器---Pod控制器-Deployment版本回退

Deployment支持更新过程中的控制，如：暂停更新（pause），继续更新（resume）

当需要对现有的一批pod进行升级时，当有一小部分pod已经升级到新版本，此时可以通过**暂停更新**阻止所有pod全部升级，此时会有一部分pod已经升级到新版本，而还有一部分pod仍然是原有的版本，这时可以将用户的请求路由到新版本的pod中，测试新版本pod是否稳定运行，确定新版本pod没有问题以后，在继续升级剩余的pod，否则立即回滚到旧版本。

通过命令更新pod的版本，并通过暂停更新阻止所有pod全部升级kubectl set image deploy deployment nginx=nginx:1.21.1 -n dev && kubectl rollout pause deploy deployment -n dev

查看更新状态kubectl rollout status deploy deployment -n dev

在开一个终端查看rs信息kubectl get rs -n dev

继续更新kubectl rollout resume deploy deployment -n dev

删除Deployment，rs与pod也同时会被删除kubectl delete -f deployment.yml

查看rskubectl get rs -n dev

查看Deploymentkubectl get deploy -n dev

应用场景类似于灰度发布

Pod控制器---Pod控制器-Deployment金丝雀发布

Horizontal Pod Autoscaler（HPA）可以获取每个pod的资源利用率，然后和HPA中定义的资源利用率指标进行对比，同时计算出需要伸缩的具体值，最后实现pod的数量的自动（非手动）调整，其实HPA与之前的Deployment一样，也属于一种k8s资源对象，它通过追踪分析目标pod的负载变化情况，来确定是否需要针对性的调整目标pod的副本数量；HPA可以实现pod数量的自动扩缩容，对比于前边手动对pod数量进行调整，HPA更加的智能

下载metrics-server软件kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.4/components.yamlPS：这边要下载与当前K8S对应版本的metrics，不然会提示版本兼容问题

解压软件包&&进入解压后路径

vim metrics-server-deployment.yaml 

编辑metrics-server-deployment.yaml文件PS：1.metrics-server默认使用的是主机名方式访问kubelet，但是在集群DNS解析记录中并没有三台物理机器的主机名，需要改为使用主机IP地址；2.验证客户端证书的问题，需要改为不验证；

执行命令，安装metrics-serverkubectl apply -f ./

查看pod运行状态kubectl get po -n kube-system

查看node资源使用情况：kubectl top node/podkubectl top node

查看pod资源使用情况kubectl top pod -n kube-system

实验：安装metrics-server可以用来收集集群中的资源使用情况  ----这个实验先搁置下，原本的metrics-server版本与当前k8s版本不兼容，需要下载新版本，但是新版本的启动文件与老的不太一样，待后面再研究下如何操作，下载连接：https://github.com/kubernetes-sigs/metrics-server/releases/tag/v0.6.3

创建deploymentvim nginx-pod.yaml

查看deploy信息font color=\"#e74f4c\

创建service，暴露service端口kubectl expose deployment nginx --type=NodePort --port=80 -n dev

查看svc信息kubectl get svc -n dev

准备deployment和service

通过下边命令可以获取HPA支持的配置属性kubectl explain HorizontalPodAutoscaler.spec

创建hpa.yml文件vim hpa.yml

创建hpakubectl create -f hpa.yml

查看hpa信息kubectl get hpa -n dev

另开终端动态查看deploy信息kubectl get deploy -n dev -w

另开终端动态查看pod信息kubectl get po -n dev -w

另开终端动态查看hpa信息kubectl get hpa -n dev -w

部署HPA

Pod控制器---Pod控制器-HPA

DaemonSet（DS）控制器可以保障集群中的每一个（或指定）节点上都运行一个副本，如果一个pod提供的功能是节点级别的（每个节点都需要且只需要一个），一般适用于日志收集，节点监控场景，这种类型的pod就适合使用DaemonSet类型的控制器创建

每当像集群添加一个节点时，指定的pod副本也将添加到该节点上

当节点从集群中移除时，pod也就被垃圾回收

DaemonSet控制器的特点：

DaemonSet资源清单介绍

创建daemonset.yml文件vim daemonset.yml

创建podkubectl create -f daemonset.yml

查看ds信息kubectl get ds -n dev

删除dskubectl delete -f daemonset.yml 

实验：创建daemonset.yml文件

Pod控制器---Pod控制器-DaemonSet

前边的控制器作用都是需要持续运行pod，如果只想运行完成工作后就终止的任务，job控制器主要负责处理仅运行一次就终止的pod

当job创建的pod执行成功结束时，job将记录成功结束的pod数量

当成功结束的pod达到指定的数量时，job将完成执行

job特点如下

可以用来做数据备份，执行一次备份就结束任务

应用场景

job的资源清单文件：

OnFailure（失败重启）：则job会在pod出现故障时重启容器，而不是创建pod，failed次数不变

Never（失败不重启）：则job会在pod出现故障时创建新的pod，并且故障pod不会消失，也不会重启，failed次数加1

Always（一直重启）：就一直重启pod，就意味着job任务会重复去执行，所以不能设置为Always

关于重启策略配置说明：

创建job.yml文件vim job.yml

创建pod（可提前查看动态pod创建过程）kubectl create -f job.yml 

动态查看job信息kubectl get job -n dev -w

查看pod信息kubectl get po -n devPS：提示：发现容器以执行完成，当前状态为Completed（完成状态）

删除job控制器kubectl delete -f job.yml 

实验：创建job.yml文件

Pod控制器---Pod控制器-Job

CronJob（CJ）控制器通过控制job控制器管理pod资源，CronJob可以在指定的时间去运行pod

CronJob的资源清单文件：

创建cronjob.yml文件vim cronjob.yml

创建cronjob（可提前动态查看pod、job、cronjob信息）kubectl create -f cronjob.yml 

动态查看pod、job、cronjob信息kubectl get cj -n dev -wkubectl get po -n dev -wkubectl get job -n dev -w

删除cronjobkubectl delete -f cronjob.yml总结：job只能运行一次性任务，而cronjob可以定义时间点去指定指定的任务

实验：创建cronjob.yml文件

Pod控制器---Pod控制器-Cronjob

Docker$Kubernetes笔记---05---Pod调度&控制器