kubernetes控制器

忘是亡心i 2022-01-11 08:49 202阅读 0赞

# 一 概述 #

## 1 控制器的必要性 ##

> 自主POD调度绑定至节点若主程序崩溃则节点kubelet能够自动重启容器，但若是非主进程崩溃类的容器kubelet无从感知。这便需要依赖于POD对象定义的存活探测，以便kubelet能够探知到此类故障，但若pod被删除或者工作节点自身发生故障（工作节点上都有kubelet，kubelet不可用，因此其健康状态便无法保证），则便需要控制器来处理相应的容器重启和配置。

## 2 常见的工作负载控制器 ##

> POD 控制器有master 的 kube-controller-manager组件提供，其类型有：  
> 1 replicationcontroller  
> 2 replicaset  
> 3 deployment  
> 4 daemonset  
> 5 statefulset  
> 6 job  
> 7 cronjob

## 3 控制器概述 ##

> kubernetes的核心之一是确保各资源对象的当前状态以匹配用户期望的状态，使当前状态不断向期望状态靠近的方式来完成容器应用和管理。

--------------------

> 控制器通过api server 提供的接口持续监控相关资源对象的当前状态，并在因故障灯导致系统发生变化时，尝试让资源向期望状态迁移和逼近。

--------------------

> list-watch ： kubernetes 的核心机制之一，其在资源状态发生变化时，由API server 负责写入etcd并通过水平触发机制主动通知给相关客户端程序企鹅包不会错过事件，控制器通过api server 的watch 接口实时监控目标资源对象的变动和执行趋近操作，并不会与其他控制器进行交互。

## 4 POD和POD控制器 ##

> pod 控制器通过（list-watch）监控集群中y运行着的POD资源对象来确保其受管控的资源严格符合用户期望状态，通常POD控制器包含的基本组成部分：  
> 1 标签选择器：匹配相关的POD，来确保POD的数量（kubectl explain deployment.spec.selector）  
> 2 期望副本数：期望在集群中与运行着的POD资源的对象数量（kubectl explain deployment.spec.replicas）  
> 3 POD模板： 用于新建POD资源对象的POd模板资源（kubectl explain deployment.spec.template）  
> 注：demonset 用于确保每个工作（node）节点上都运行着一个POD，因此不具备第二个选项。

# 二 replicaSet 控制器 #

## 1 概述 ##

> kubernetes 中replicaset是取代早期的replicationcontroller，其replicationcontroller将被废弃，但其功能和replicaset基本类似。

--------------------

> replicaset 用于保证其管理的POD对象副本数量在任意时刻都能精确满足期望数量，其原理是：控制器资源在启动后会查找集群中欧匹配其标签选择器的POD资源对象，当前活动对象的数量与期望数量不吻合时，则删除或创建POD。

--------------------

> replicaset能够实现的功能  
> 1 确保POD资源独享的数值精确反应期望值  
> 2 确保POD健康运行：探测到期POD对象因工作节点故障而不可用时，会自动由调度器调度至其他节点创建缺失的POD副本。  
> 3 弹性伸缩：可通过replicaset控制器动态调整相关POD资源对象数量，必要时还可以通过HPA 控制器实现POD资源规模的自动伸缩。

## 2 创建replicaset 相关资源 ##

### 1 核心字段 ###

> replicas： 用于定义当前期望副本数量  
> selector： 用于选择和计数当前POD的数量  
> template：用于定义POD资源信息  
> minreadysecond： 用于定义POD启动后多长时间为可用状态

### 2 资源创建 ###

apiVersion: extensions/v1beta1
    kind: ReplicaSet
    metadata:
        name: replicaset-demo
        namespace: default
    spec:
        replicas: 2  # 定义POD副本数量
        selector:
            matchLabels:
                app: replicaset1
                release: test
        minReadySeconds: 5  #定期启动后多久认为正常
        template:  # 定义POD资源
            metadata:
                name: replicaset-demo
                namespace: default
                labels:  #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
                    app: replicaset1
                    release: test
            spec:
                containers:
                    - name: replicaset-demo
                      image: nginx:1.14
                      ports:
                        - name: httpd
                          containerPort: 80

部署

kubectl apply -f replicaset1.yaml

查看

![kubernetes控制器][kubernetes]

## 3 replicaset下POD管控 ##

### 1 删除指定指定标签的POD ###

![kubernetes控制器][kubernetes 1]  
删除对应pod后新的POD已经被创建，副本数仍然是两个

### 2 强制清除对应POD的标签 ###

kubectl label pods  replicaset-demo-lbvl4 app= release=  --overwrite

查看其POD副本数已上升至3个，因其中一个标签不符合要求

![kubernetes控制器][kubernetes 2]

### 3 增加POD 用于匹配对应标签 ###

kubectl run   nginx10 --image=nginx:1.14  -l app=replicaset1,release=test

查看

删除了其余的pod（replicaset-demo开头的）  
![kubernetes控制器][kubernetes 3]

### 4 查看POD资源变动事件 ###

1 查看控制器

kubectl get replicaset

![kubernetes控制器][kubernetes 4]  
2 查看控制器中POD变化信息

kubectl describe  replicaset  replicaset-demo

![kubernetes控制器][kubernetes 5]

> 事实上，replicaset控制器能够对POD对象数目的异常进行响应是因为其向API server注册监听了watch 相关资源及列表的变动信息，于是API server会在变动发生时立即通知给相关的监听客户端。

## 4 更新replicaset控制器 ##

> 其更新主要是replicas 和template 字段进行的，毕竟对标签的带动是很少的，修改template就是更新POD，修改replicas就是扩容或缩容。

### 1 升级应用 ###

> replicas 控制器的POD template 的变更只会影响新建的POD对象，对于已经存在的副本没有影响，因此，若更新版本，则在修改了template.spec.containers.image 之后，还需要删除之前版本对应的副本或按一定方式进行更新。

修改配置文件中image

apiVersion: extensions/v1beta1
    kind: ReplicaSet
    metadata:
        name: replicaset-demo
        namespace: default
    spec:
        replicas: 2  # 定义POD副本数量
        selector:
            matchLabels:
                app: replicaset1
                release: test
        minReadySeconds: 5  #定期启动后多久认为正常
        template:  # 定义POD资源
            metadata:
                name: replicaset-demo
                namespace: default
                labels:  #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
                    app: replicaset1
                    release: test
            spec:
                containers:
                    - name: replicaset-demo
                      image: nginx:1.12 #修改了镜像
                      ports:
                        - name: httpd
                          containerPort: 80

部署

kubectl replace  -f replicaset1.yaml

查看相关镜像

kubectl get   pods -l app=replicaset1,release=test   -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

![kubernetes控制器][kubernetes 6]

删除对应的POD

kubectl delete pods -l  app=replicaset1,release=test

查看POD

kubectl get   pods -l app=replicaset1,release=test   -o custom-columns=Name:metadata.name,Image:spec.containers[0].image

![kubernetes控制器][kubernetes 7]

> 更新方式  
> 1 一次性删除控制器相关的所有POD副本或更改相关标签  
> 2 分批删除就有的POD副本或更新其标签，滚动更替，更替期间新旧版本共存。

### 2 扩容和缩容 ###

> 改动replicaset控制器对象配置中期望的POD副本数量会由控制器实时响应，从而实现应用规模的水平伸缩，kubelet提供了专用的子命令scale 用于实现应用规模的伸缩，它支持从资源清单文件中获取新的目标副本数量，也可直接在命令中获取"--replicas"选项进行读取

扩容

kubectl scale replicasets replicaset-demo --replicas=5

查看  
![kubernetes控制器][kubernetes 8]

缩容

kubectl scale replicasets replicaset-demo --replicas=1

查看  
![kubernetes控制器][kubernetes 9]

配置文件扩容

apiVersion: extensions/v1beta1
    kind: ReplicaSet
    metadata:
        name: replicaset-demo
        namespace: default
    spec:
        replicas: 3  # 定义POD副本数量
        selector:
            matchLabels:
                app: replicaset1
                release: test
        minReadySeconds: 5  #定期启动后多久认为正常
        template:  # 定义POD资源
            metadata:
                name: replicaset-demo
                namespace: default
                labels:  #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
                    app: replicaset1
                    release: test
            spec:
                containers:
                    - name: replicaset-demo
                      image: nginx:1.12
                      ports:
                        - name: httpd
                          containerPort: 80

部署

kubectl apply -f replicaset1.yaml

查看  
![kubernetes控制器][kubernetes 10]

### 3 删除replicaset 控制器资源 ###

> 使用kubectl delete命令删除replicaset对象时默认会一并删除其管控的各POD对象，有时，考虑到这些POD未必尤其创建，或者即使尤其创建却也并非其自身的组成部分，故而可以为命令使用"--cascade=false"取消级联，删除相关POD对象，

查看replicaset创建的POD  
![kubernetes控制器][kubernetes 11]

删除POD

kubectl delete  replicasets replicaset-demo  --cascade=false

查看

![kubernetes控制器][kubernetes 12]

# 三 deployment控制器 #

## 1 概述 ##

> deployment 是kubernetes控制器的另一种实现，其构建与replicaset控制器之上，可为POD和replicaset资源提供声明式更新。

--------------------

> deployment控制器资源的主要职责是为了保证POD资源的健康运行，其不同于replicaset的功能：  
> 1 事件和状态查看：必要时可以查看deployment对象升级的详细进度和状态  
> 2 回滚：升级操作完成后发现问题，支持使用回滚机制将应用程序返回到前一个由用户指定的历史记录版本中  
> 3 版本记录：对deployment 对象的每一次升级操作都予以保存，以供后续可能的回滚操作  
> 4 暂停和启动：对于每一次更新，都能够随时暂停和启动  
> 5 多种自动更新方案： 一个是recreate，及重建机制，全面停止、删除旧有的POD后用心版本替代，另一种是rollingupdate，及滚动升级机制，逐步替换旧有的POD到新版本。

## 2 创建deployment ##

其核心资源和replicaset相似

apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
        name: deployment-demo
        namespace: default
    spec:
        replicas: 3  # 定义POD副本数量
        selector:
            matchLabels:
                app: deploy
                release: test
        minReadySeconds: 5  #定期启动后多久认为正常
        template:  # 定义POD资源
            metadata:
                name: replicaset-demo
                namespace: default
                labels:  #此处必须和上面的selector中对应的标签相同，否则无法进行匹配
                    app: deploy
                    release: test
            spec:
                containers:
                    - name: deploy-demo
                      image: nginx:1.12
                      ports:
                        - name: httpd
                          containerPort: 80

构建

kubectl apply -f deploy.yaml

查看：  
![kubernetes控制器][kubernetes 13]  
![kubernetes控制器][kubernetes 14]

> deployment控制器会自动管理至replicaset控制器资源，其名称是 deployement 名称+ hash 。其中hash 是由deployment随机生成，

查看  
![kubernetes控制器][kubernetes 15]

## 3 更新策略 ##

> replicaset控制器应用更新需要手动分成多步并以特定的次序进行，过程繁杂，而deployment只需要用户指定POD模板中要改动的内容，余下的步骤是操作系统自动完成的，其副本数量也是相同

--------------------

> deployment支持滚动更新和重建更新，其默认是滚动更新，重建更新和之前的replicaset相同，首先删除所有POD，而后由控制器基于新模板重新创建出新版本资源对象，此情况仅用于新旧版本不兼容的情况。
> 
> 滚动升级是默认的更新策略，它在删除一部分旧版本POD资源的同时，补充创建一部分新版本的POD对象进行应用升级，其优势是升级期间，服务不会中断，但更新期间，不同客户端得到的相应内容可能会来自不同的版本的应用。  
> deployment的滚动更新是将新旧版本用在不同的replicaset控制器对象下，删除旧的POD的同时增加新的POD，新的POD对象数量不断增加，直到旧的控制器不在拥有POD对象，而新的控制器的副本数量变得完全符合期望值为止。

--------------------

> 滚动更新时，应用升级期间需要确保POD对象数量不低于某个阈值以确保可以持续处理客户端的服务请求，变动的方式和POD对象的数量范围通过 kubectl explain deployment.spec.strategy.rollingUpdate.maxSurge 和 kubectl explain deployment.spec.strategy.rollingUpdate.maxUnavailable 两个属性协同进行定义，其功能如下：
> 
> 1 maxSurge ： 指定升级期间存在的总POD对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是期望值百分比，如期望是3，maxsurge是1，则表示POD对象的总数不能超过4个。
> 
> 2 maxUnavailable：升级期间正常可用的POD副本数最多不能低于期望数值的个数，可以是整数或0，也可以是一个期望值百分比，默认是1，则表示若期望值是3，则升级期间至少要两个POD对象处于正常运行状态。
> 
> **注 maxsuarge 和 maxunavailable属性值不可同时为0，否则POD对象的副本数量在符合用户期望数量后无法做出合理变动以进行滚动更新操作。**

--------------------

> 用户可以通过spec.minReadySeconds 属性来控制应用程序升级速度，新旧更替过程中，新创建的POD对象一旦成果相应就绪探测及被视为可用，而后便开始新一轮的替换操作，而deployment.spec.minReadySeconds 定义在新的POD创建后至少等待多久才视为就绪，此期间，更新操作被被阻塞。
> 
> deployment 的历史版本保留数量由deployment.spec.revisionHistoryLimit 属性进行定义，只有保存与revision历史中的replicaset版本可用于回滚。

--------------------

> 注： 为了保存版本升级的历史，需要在创建deployment对象时在命令中使用"--record"选项。

## 4 升级deployment ##

> 修改POD模板相关的配置参数以便完成deployment控制器资源的更新，由于是声明式配置，因此对deployment控制器的修改使用apply 和patch 命令进行，若仅是修改镜像，则可使用set image 即可

修改副本数量

kubectl patch deployment deployment-demo -p '{"spec":{"replicas":4}}'

查看配置  
![kubernetes控制器][kubernetes 16]

修改更新等待时间

kubectl patch deployment deployment-demo -p '{"spec":{"minReadySeconds":4}}'

查看  
![kubernetes控制器][kubernetes 17]

> **注： 修改deployment控制器的minreadyseconds，replicas 和 strategy 等字段值并不会触发POD资源更新操作，因为其不属于模板的内嵌字段，对现存的POD对象不会产生任何影响**

实例  
之前版本  
![kubernetes控制器][kubernetes 18]  
更新操作

kubectl edit deployment deployment-demo

修改镜像  
![kubernetes控制器][kubernetes 19]

查看  
![kubernetes控制器][kubernetes 20]

使用kubectl set image 更新镜像

kubectl set image deployment  deployment-demo deploy-demo=nginx:1.12

> 其中deployment-demo 是deployment的名称， deploy-demo 是其控制器中containers.name的名称

查看其版本  
![kubernetes控制器][kubernetes 21]

## 5 金丝雀发布 ##

> deployment 控制器还支持金丝雀发布，及随时展厅或继续更新操作，通过 maxsurge 和 maxunavailable属性还能实现更为精巧的控制过程，其采用先添加再删除的方式，且可用POD资源对象总数不低于期望值的方式进行，配置如下：

### 1 添加其总数多于期望值一个 ###

kubectl patch deployments deployment-demo -p  '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailable":0}}}}'

### 2 启动更新过程 ###

> 在修改相应容器的镜像版本后立即暂停更新进度，其会在启动第一批新版本POD对象后转为暂停，这里之所以能暂停，是因为第一步设置了其maxReadySeconds属性时长，因此用户要在更新命令启动后此时长指定的时间范围内启动暂停操作。

kubectl set image deployment deployment-demo  deploy-demo=nginx:1.14 && kubectl rollout pause deployment  deployment-demo

查看  
![kubernetes控制器][kubernetes 22]  
![kubernetes控制器][kubernetes 23]

查看更新情况

kubectl rollout status deployment deployment-demo

![kubernetes控制器][kubernetes 24]  
旧版本的4个因为不超出5个，上述定义的是1个  
全部更新

kubectl rollout resume deployment deployment-demo

查看  
![kubernetes控制器][kubernetes 25]

![kubernetes控制器][kubernetes 26]

### 3 回滚deployment 控制器下的应用发布 ###

> 若上述升级失败，则需要即可执行回滚操作，或者回滚到之前用户指定的历史版本，回滚到此前版本

kubectl rollout undo deployment  deployment-demo

查看  
![kubernetes控制器][kubernetes 27]

查看历史版本

kubectl rollout history deployment deployment-demo

![kubernetes控制器][kubernetes 28]

回滚到指定版本

kubectl rollout undo deployment deployment-demo --to-revision=4

查看  
![kubernetes控制器][kubernetes 29]

> 回滚操作中，其revision记录的信息会发生变动，回滚操作会被当做一次滚动更新追加进历史记录中，而被滚动的条目则会被删除。

## 6 扩容和缩容 ##

> 通过修改spec.replicas 即可修改deployment控制器中的POD资源副本的数量，其将实时作用控制器直接生效，deployment控制器是声明式皮遏制，replicas属性的值可直接修改资源配置文件，然后使用"kubectl apply"进行更新，也可使用kubctl edit 进行实时修改，其kubectl scale 是专用扩展POD，包括deployment和job。

相关配置

apiVersion: extensions/v1beta1
    kind: DaemonSet
    metadata:
        name: daem-demo
        namespace: default
    spec:
        minReadySeconds: 5
        selector:
            matchLabels:
                app: daem
        template:
            metadata:
                name: daem-demo
                namespace: default
                labels:
                    app: daem
            spec:
                containers:
                    - name: daem-demo   
                      image: nginx:1.12
                      ports:
                        - name: httpd
                          containerPort: 80

部署

kubectl apply -f daemonsey.yaml

查看  
![kubernetes控制器][kubernetes 32]

> **注： 自kubernetes1.8开始，daemonset也必须使用selector来匹配Pod模板中指定的标签，并且也支持matchlabels和matchexpressions 两种标签选择器**

kubectl get pods -l app=daem -o custom-columns=NAME:metadata.name,NODE:spec.nodeName

查看POD部署位置  
![kubernetes控制器][kubernetes 33]

## 3 更新daemonset对象 ##

> daemonset自1.6版本来时支持更新机制，相关配置嵌套在daemonset.spec.updateStrategy中，其支持滚动更新(RollingUpdate)和删除时更新(OnDelete)两种更新策略，滚动更新为默认的更新策略，其仅支持maxUnavailabe属性定义不可用Pod资源副本数，默认为1，而删除更新则是在删除节点POD资源后重新更新为新版本。

滚动更新

### 1 查看默认镜像源： ###

kubectl get pods -l app=daem -o custom-columns=NAME:metadata.name,NODE:spec.nodeName,Image:spec.containers[0].image

### 2 更新 ###

kubectl set image daemonset daem-demo daem-demo=nginx:1.14

> 默认的滚动更新策略是一次删除一个工作节点上的POD资源，等其新版本POD重建完成后再开始操作另一个工作节点上的POD资源  
> daemonset控制器的滚动更新机制可以借助minreadyseconds 字段控制节奏，必要时可以执行和暂停继续操作。其也可进行回滚

# 五 job控制器 #

## 1 概述 ##

> job 控制器用户调配Pod对象执行一次性任务，容器中的进程完成任务后容器不会进行重启，而是将其置于completed（完成）状态，若容器中的进程因错误而终止，则需要依据重启策略判断是否需要重启，未运行完成的Pod若节点故障，则其会被调度至其他节点进行处理。

## 2 运行方式 ##

> 1 单工作队列的串行式Job，及以多次一次性的作业方式串行执行多次作业，直至满足期望的次数。

--------------------

> 2 多工作队列的并行式Job: 这种方式可以设置工作队列数，每个队列仅负责运行一个作业，也可以使用有限队列运行较多作业，即队列数小于总作业数，相当于多个串行队列一起运行

## 3 创建JOB对象 ##

### 1 创建串行JOB ###

> job中内嵌的必选资源为template，其使用方式与deployment等控制相同，job 会为其POD对象自动添加 job-name 和 controller-uid 标签，并使用标签选择器完成与controller-uid标签的关联，配置清单如下:

apiVersion: batch/v1
    kind: Job
    metadata:
        name: job-demo
    spec:
        template:
            spec:
                containers:
                    - name: job-demo
                      image: nginx:1.14
                      command: ["/bin/bash","-c","sleep 60"]
                restartPolicy:  Never  #重启策略，发生错误，不进行重启

部署

kubectl apply -f job.yaml

查看状态  
![kubernetes控制器][kubernetes 34]

查看其标签选择器和标签  
![kubernetes控制器][kubernetes 35]

### 2 创建并行JOB ###

> job.spec.parallelism ： 并行度量，及队列的数量
> 
> job.spec.completions： 作业数量，其总数量

创建5个作业的串行job,每个job60s后自动关闭

apiVersion: batch/v1
    kind: Job
    metadata:
        name: job-demo1
    spec:
        completions: 3
        template:
            spec:
                containers:
                    - name: job-demo1
                      image: nginx:1.14
                      command: ["/bin/bash","-c","sleep 60"]
                restartPolicy:  Never  #重启策略，不进行重启

查看

![kubernetes控制器][kubernetes 36]  
目前已经有一个JOB执行完成了，正在执行第二个JOB

创建5个job的并行为3的并行作业

apiVersion: batch/v1
    kind: Job
    metadata:
        name: job-demo2
    spec:
        completions: 5
        parallelism: 3
        template:
            spec:
                containers:
                    - name: job-demo2
                      image: nginx:1.14
                      command: ["/bin/bash","-c","sleep 60"]
                restartPolicy:  Never  #重启策略，不进行重启

部署

kubectl apply -f job2.yaml

查看

![kubernetes控制器][kubernetes 37]

> 因为其队列为3，因此同时可创建3个POD进行作业，总共5个，需要2分钟完成

## 4 job扩容 ##

> job 控制器的.spec.parallelism 定义的并行度表示同时运行Pod对象数，此属性值支持运行时调整从而改变队列总数，实现扩容和缩容，其必须是前面的JOB 未运行完，若运行完成的job，则其无相关效果

删除job2并修改

kubectl delete  -f job2.yaml

修改其队列数值为1

apiVersion: batch/v1
    kind: Job
    metadata:
        name: job-demo2
    spec:
        completions: 5
        parallelism: 1
        template:
            spec:
                containers:
                    - name: job-demo2
                      image: nginx:1.14
                      command: ["/bin/bash","-c","sleep 60"]
                restartPolicy:  Never  #重启策略，不进行重启

重新部署

kubectl apply -f job2.yaml

查看当前POD

![kubernetes控制器][kubernetes 38]  
一个POD

修改至3个

kubectl scale jobs  job-demo2 --replicas=3

![kubernetes控制器][kubernetes 39]  
同时运行三个job

## 5 删除 ##

> job 控制器待其POD资源运行完成后，将不再占用系统资源，用户可以按需保留或使用资源删除命令删除。但若某些资源无法正常结束，且其重启策略是restartPolicy是 Always，则其会一致重启，但job 提供了两个属性用于抑制这种情况发生：  
> job.spec.activeDeadlineSeconds ： 用于定义其最大活动时间长度，若超出则被终止  
> job.spec.backoffLimit： 用于设置其失败状态之前重试次数，默认为6次

# 六 cronjob控制器 #

## 1 概述 ##

> cronjob 控制器用于管理Job控制器资源的运行时间，job控制器定义的作业做任务在执行控制器资源创建之后便会立即执行，但cronjob可以以类似Linux系统的周期性任务计划的方式控制器运行的时间点击重复运行的方式，具体如下：  
> 1 在未来某一时间运行作业一次  
> 2 在指定的时间点重复运行作业
> 
> crpnjob控制器在指定的时间点时，"" 和 "\*"意义相同，都表示任何可用的有效值。

## 2 创建cronjob对象 ##

> cronjob 可嵌套的核心字段 cronjob.spec
> 
> jobTemplate ： job 控制器模板，用于为cronjob控制器生成job对象，必选字段。
> 
> schedule： cron格式的调度作业，必选字段
> 
> concurrencyPolicy：并发执行策略，有allow，forbid和replace，用于定义前一次作业运行尚未完成时是否以及如何运行后一次作业。
> 
> failedJobsHistoryLimit： 为失败的历史构建保留次数，默认为1
> 
> successfulJobsHistoryLimit： 为成功的任务执行保留的历史记录数，默认是3
> 
> startingDeadlineSeconds：因各种原因缺乏执行作业的时间点所导致的启动作业错误的超时时长，会被记录入错误历史记录。
> 
> suspend： 是否挂起后续的执行任务，默认为false。

apiVersion: batch/v1beta1
    kind: CronJob
    metadata:
        name: cronjob-demo
    spec:
        schedule: "*/1 * * * *"  #1分钟运行一次
        jobTemplate:
            spec:
                parallelism: 2 # 每次运行两个
                template:
                    spec:
                        containers:
                            - name: cronjob-demo
                              image: nginx:1.14
                              command: ["/bin/bash","-c","sleep 60"]
                        restartPolicy:  Never  #重启策略，不进行重启

部署

kubectl apply -f cronjob.yaml

查看  
![kubernetes控制器][kubernetes 40]

![kubernetes控制器][kubernetes 41]

> schedule 是其调度时间点，suspend 表示后续任务是否处于挂起状态，及暂停任务调度和运行，active表示活动状态的job对象的数量，而last schedule则表示上次调度运行至此时刻的时长。

## 3 cronjob的控制机制 ##

> cronjob 控制器是一个更高级别的资源，其以job控制器资源为其管控对象，并借助它管理Pod资源对象。因此，要使用类似的命令来查看某cronjob控制器创建的job对象，其只会在相关Job对象被执行时能够看到此类现象，可列出的job对象的数量取决于cronjob资源的cronjob.spec.successfulJobsHistoryLimit的属性值，默认是3

![kubernetes控制器][kubernetes 42]

> 如果作业重复执行时指定的时间点较接近，而执行时长跨过了其两次执行的时间长度，则会出现两个job对象同时存在的情形，有些job对象可能会存在无法或者不能同时运行的情况，这时候则需要"cronjob.spec.concurrencyPolicy"属性控制作业的并存机制，其默认为allow，及允许前后job，甚至属于同一个cronjob的更多job同时运行，forbid用于禁止前后两个job同时运行，若上一个尚未结束，则不允许启动后一个，replace 用于让后一个job取代前一个，及终止前一个并启动后一个。

转载于:https://blog.51cto.com/11233559/2370233

[kubernetes]: https://s1.51cto.com/images/blog/201903/25/d65226c2554a91c11a3b5460e985d6bc.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 1]: https://s1.51cto.com/images/blog/201903/25/569eafcc94bc482b095fe726755652c3.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 2]: https://s1.51cto.com/images/blog/201903/25/af5830a19bd67736341e8984ffc6c003.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 3]: https://s1.51cto.com/images/blog/201903/25/26f537365f801e96b937fb0802e06f86.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 4]: https://s1.51cto.com/images/blog/201903/25/e5bb255aa9102503a74976bfc64607cd.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 5]: https://s1.51cto.com/images/blog/201903/25/3b8efeca06ec47db339f612c8a02d50e.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 6]: https://s1.51cto.com/images/blog/201903/25/e1ed6cf4fd89ed45b326634fe1579936.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 7]: https://s1.51cto.com/images/blog/201903/25/2eed2533cceeccda5b68a42de45c139f.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 8]: https://s1.51cto.com/images/blog/201903/25/3ef19dff6af78fba233b99ce0b004ac1.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 9]: https://s1.51cto.com/images/blog/201903/25/1569241edf1d9852e19dd21936f35569.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 10]: https://s1.51cto.com/images/blog/201903/25/79c54ec4b7870356357ef3fe96ca0364.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 11]: https://s1.51cto.com/images/blog/201903/25/0ad300baa183c13a0d5b6e02a18cc59d.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 12]: https://s1.51cto.com/images/blog/201903/25/7544406929e776acfe6688c7df56b734.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 13]: https://s1.51cto.com/images/blog/201903/25/4ff232071f471c6a3acf9df5eb410320.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 14]: https://s1.51cto.com/images/blog/201903/25/f08207b5011f9e9bea4fb4f2ea0bb638.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 15]: https://s1.51cto.com/images/blog/201903/25/7dfa82c8e8d2ca7af6a4d9da27be0554.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 16]: https://s1.51cto.com/images/blog/201903/25/5b47dce0b1efaf143f25ad906562e3a0.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 17]: https://s1.51cto.com/images/blog/201903/25/1184e5addf5bf6e41afe5e62d7b35dc5.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 18]: https://s1.51cto.com/images/blog/201903/25/bf13d50d62c47b38413c2db00d6a6ce9.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 19]: https://s1.51cto.com/images/blog/201903/25/2bd0bc77d60fb296e79c7ec666a44643.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 20]: https://s1.51cto.com/images/blog/201903/25/566d20588a8d749c993481851d2cdfd0.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 21]: https://s1.51cto.com/images/blog/201903/25/9cba9f62e1804609fee632afbce1bc87.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 22]: https://s1.51cto.com/images/blog/201903/26/c15caa1120e97587cf0facec03ec8b5d.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 23]: https://s1.51cto.com/images/blog/201903/26/6b945681698f4010d8b5c68f0f364135.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 24]: https://s1.51cto.com/images/blog/201903/26/87fd3dc91b02197611ec0f21dc91a44f.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 25]: https://s1.51cto.com/images/blog/201903/26/1ab5f4f0a4b6f391b8d63110baaea2bc.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 26]: https://s1.51cto.com/images/blog/201903/26/9f91f3a23297dcbf584bc0aa570572cd.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 27]: https://s1.51cto.com/images/blog/201903/26/694e615d3437e92bfe1ae4316280f370.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 28]: https://s1.51cto.com/images/blog/201903/26/5491251bb59590a06c2902ff908ab9a1.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 29]: https://s1.51cto.com/images/blog/201903/26/08e0ef2a4fea5bdb0304173d52356adb.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 30]: https://s1.51cto.com/images/blog/201903/26/6e8e19eb10d1684ee09d422a6da8c86d.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 31]: https://s1.51cto.com/images/blog/201903/26/6b8d7934317f573162edcd8b04120517.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 32]: https://s1.51cto.com/images/blog/201903/26/2f02bfd8acf34ffcef04e2987132b8ec.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 33]: https://s1.51cto.com/images/blog/201903/26/ab4d9acd64841950c123f4ff28e9fbdf.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 34]: https://s1.51cto.com/images/blog/201903/26/ac122acadcb4cce878bd99b54912ead4.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 35]: https://s1.51cto.com/images/blog/201903/26/353ee40ce32a92be0240ba04012fd6b3.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 36]: https://s1.51cto.com/images/blog/201903/26/9f1113abd4cb393e7502d01160ef21cc.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 37]: https://s1.51cto.com/images/blog/201903/26/81c67fbe24c6f6ebc89a181e2c319eca.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 38]: https://s1.51cto.com/images/blog/201903/26/61dfb2e40e4f04c593a1eb5876dbedec.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 39]: https://s1.51cto.com/images/blog/201903/26/a34c85bf20fc42d41e77817aff1c43fb.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 40]: https://s1.51cto.com/images/blog/201903/27/9a26b9c22c04f52ca515b878f0e4a7d7.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 41]: https://s1.51cto.com/images/blog/201903/27/040616541f5a41e91ed85adb23c38451.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[kubernetes 42]: https://s1.51cto.com/images/blog/201903/27/0e32c1b098fb892daee3301ccb9e984f.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=