Kubernetes学习笔记(2)-Pod与Pod Controller

Pod

结构与定义

在Kubernetes中，每个Pod都可以包含一个或者多个容器，这些容器可以分为两类：

• 用户程序所在的容器，数量可多可少

• Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个，一方面可以以它为依据，评估整个Pod的健康状态；另一方面可以在根容器上设置Ip地址，其它容器都此Ip（Pod IP），以实现Pod内部的网络通信

在Kuberents中，每个Resource最终都可以对应一个yaml配置文件，不同的Resource对应的配置文件可选项不同。利用kubectl explain可以查看对应Resource的可配置项以及相关含义：

# kubectl explain 资源类型         查看某种资源可以配置的一级属性
# kubectl explain 资源类型.属性     查看属性的子属性
kubectl explain pod
kubectl explain pod.metadata

每种Resource的可配置项众多，这里不全部列出，需要时可以使用explain命令进行查看。

在Kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分：

• apiVersion <string>： 版本信息，由Kubernetes内部定义，版本号必须可以用 kubectl api-versions 查询到
• kind <string>：Resource类型信息，由Kubernetes内部定义，Resource必须可以用 kubectl api-resources 查询到
• metadata <Object> ：元数据信息，主要是资源标识和说明，常用的有name、namespace、labels等
• spec <Object>：描述信息，这是配置中最重要的一部分，其中是对各种Resource配置的详细描述
• status <Object>：状态信息，里面的内容不需要定义，由Kubernetes自动生成

在上面的属性中，spec详细信息是配置重点，具有如下的常见子属性:

• containers <[]Object> ：容器列表，用于定义容器的详细信息
• nodeName <String> ：根据nodeName的值将pod调度到指定的Node节点上
• nodeSelector <map[]> ：根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node 上
• hostNetwork <boolean> ：是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
• volumes <[]Object> ：存储卷，用于定义Pod上面挂载的存储信息
• restartPolicy <string> ：重启策略，表示Pod在遇到故障的时候的处理策略

Pod 配置

Pod 基础配置

Pod中可以运行多个Container，Container的配置即为Pod的基础配置。通过kubectl explain pod.spec.containers查看相关信息，其中可配置项如下：

KIND:     Pod
VERSION:  v1
RESOURCE: containers <[]Object>   # 数组，代表可以有多个容器
FIELDS:
   name  <string>     # 容器名称
   image <string>     # 容器需要的镜像地址 [image_name:version]
   imagePullPolicy  <string> # 镜像拉取策略 
   command  <[]string> # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
   args     <[]string> # 容器的启动命令需要的参数列表
   env      <[]Object> # 容器环境变量的配置
   ports    <[]Object>     # 容器需要暴露的端口号列表
   resources <Object>      # 资源限制和资源请求的设置

name表示运行的container名称，可自定义；image表示container的镜像地址，通常由镜像名称和版本构成。

imagePullPolicy用于设置镜像拉取策略，Kubernetes支持配置三种拉取策略：

• Always：总是从远程仓库拉取镜像（一直远程下载）
• IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就本地 本地没远程下载）
• Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错 （一直使用本地）

镜像拉取策略的默认值与镜像tag有一定关系，如果镜像tag为具体版本号，那么默认策略是IfNotPresent，如果镜像tag是latest，那么默认策略是Always。

command表示容器启动命令，args表示启动命令所需的参数。这两个参数主要对应的是DockerFile中的ENTRYPOINT，并且此处的配置要优先于DockerFile中的配置，具体有如下的规则：

• 如果command和args均没有配置，那么用Dockerfile的配置；
• 如果command配置来，但args没有配置，那么Dockerfile默认的配置会被忽略，执行输入的command
• 如果command没配置，但args配置了，那么Dockerfile中配置的ENTRYPOINT的命令会被执行，并且使用当前args的参数
• 如果command和args都写配置了，那么Dockerfile的配置被忽略，执行command并追加上args参数

# command example
spec:
  containers:
  - name: busybox
    image: busybox:1.30
    command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]

env用于在Pod的Container中设置环境变量。不过这种方式不是很推荐，推荐使用后续的ConfigMap来完成相关操作。

ports用于指定容器需要暴露的端口设置，支持如下选项：

KIND:     Pod
VERSION:  v1
RESOURCE: ports <[]Object>
FIELDS:
   name         <string>  # 端口名称，如果指定，必须保证name在pod中是唯一的		
   containerPort<integer> # 容器要监听的端口(0<x<65536)
   hostPort     <integer> # 容器要在主机上公开的端口，注意要避免端口冲突(一般省略) 
   hostIP       <string>  # 要将外部端口绑定到的主机IP(一般省略)
   protocol     <string>  # 端口协议。必须是UDP、TCP或SCTP。默认为“TCP”。

# ports example
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    ports: # 设置容器暴露的端口列表
    - name: nginx-port
      containerPort: 80
      protocol: TCP

resources用于指定容器的资源限制和配额，其中包含两个子选项，分别是limits和requests。limits用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启；requests 用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动。

# resources example
spec:
  containers:
  - name: nginx
    image: nginx:1.17.1
    resources: # 资源配额
      limits:  # 限制资源（上限）
        cpu: "2" # CPU限制，单位是core数
        memory: "10Gi" # 内存限制
      requests: # 请求资源（下限）
        cpu: "1"  # CPU限制，单位是core数
        memory: "10Mi"  # 内存限制

Pod 生命周期

概述

Pod的生命周期包括Pod对象从创建到终止的全部流程，确切地说分为下面的阶段：

1. pod创建过程

2. 初始化容器（init container）创建运行过程（这里的初始化容器是个名词）

3. 运行主容器（main container）

   • 容器启动后钩子（post start）、容器终止前钩子（pre stop）

   • 容器的存活性探测（liveness probe）、就绪性探测（readiness probe）

4. pod终止过程

在整个生命周期中，Pod会出现5种状态，分别如下：

• 挂起(Pending)：ApiServer已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
• 运行中(Running)：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
• 成功(Succeeded)：pod中的所有容器都已经成功终止并且不会被重启
• 失败(Failed)：所有容器都已经终止，但至少有一个容器终止失败，即容器返回了非0值的退出状态
• 未知(Unknown)：ApiServer无法正常获取到pod对象的状态信息，通常由网络通信失败所导致

创建和终止

Pod的创建过程：

1. 用户通过kubectl或其他api客户端提交需要创建的pod信息给ApiServer

2. ApiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端

3. ApiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查ApiServer上的变动

4. Scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至ApiServer

5. Node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至ApiServer

6. ApiServer将接收到的pod状态信息存入etcd中

Pod的终止过程：

1. 用户向ApiServer发送删除pod对象的命令
2. ApiServer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
3. 将pod标记为terminating状态
4. kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
5. Endpoint控制器监控到pod对象的关闭行为时，将其从所有匹配到此Endpoint的service资源的端点列表中移除
6. 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行
7. pod对象中的容器进程收到停止信号
8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
9. kubelet请求ApiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见

初始化容器

初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：

1. 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么Kubernetes需要重启它直到成功完成
2. 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行

初始化容器有很多的应用场景，下面列出的是最常见的几个：

• 提供主容器镜像中不具备的工具程序或自定义代码
• 初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足

初始化容器的配置可以在spec.initContainers中完成，它具有的配置项与spec.Containers基本相同。

钩子函数

钩子（hook）函数向用户提供生命周期对应时间点的控制方法。用户可以通过hook函数完成在生命周期的不同时间点执行不同的方法。

Kubernetes在主容器的启动之后和停止之前提供了两个钩子函数：

• post start：容器创建之后执行，如果失败了会重启容器
• pre stop ：容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作

钩子处理器支持使用下面三种方式定义动作，配置在spec.containers.lifecycle选项当中。下面演示的是post start阶段的配置，pre stop阶段有类似的配置选项。

# exec: 在容器内部执行一次命令
spec:
	containers:
		lifecycle:
			postStart:
        exec:
          command:
          - cat
          - /tmp/healthy
		
# tcpSocket: 在容器内部尝试访问指定一个用户容器的端口
spec:
	containers:
		lifecycle:
			postStart:
				tcpSocket:
					port: 8080

# httpGet: 在容器内部向某url发起http请求
spec:
	containers:
		lifecycle:
			postStart:
				httpGet:
					path: /xxx
					port: 80
					host: 192.168.5.3 # 主机地址
					scheme: HTTP # 支持的协议 HTTP/HTTPS

容器探测

容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么Kubernetes就会把该问题实例" 摘除 "，不承担业务流量。Kubernetes提供了两种探针来实现容器探测，分别是：

• liveness probe：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器
• readiness probe：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量，但是并不会处理(重启或杀死)这个容器

这两种探针均支持三种方式，配置在spec.containers.livenessProbe或者readinessProbe中。三种方式与钩子函数中的三种方式基本相同：

# exec: 如果命令执行的退出码为0则认为正常，否则不正常
spec:
	containers:
		livenessProbe:
			exec:
				command:
				- cat
				- /tmp/healthy
		
# tcpSocket: 访问一个用户容器的端口，如果能够建立socket连接则认为正常，否则不正常
spec:
	containers:
		livenessProbe:
			tcpSocket:
				port: 8080

# httpGet: 如果返回的状态码在200和399之间则认为正常，否则不正常
spec:
	containers:
		livenessProbe:
			httpGet:
				path: /xxx
				port: 80
				host: xxx.xxx.xxx.xxx
				scheme: HTTP # HTTP/HTTPS

重启策略

对于出现问题的Pod，Kubernetes会对其进行重启，而重启是遵循一定的重启策略的。Pod的重启策略可以在spec.restartPolicy中进行配置，共有三种可选项，如下所示：

• Always ：容器失效时，自动重启该容器，这也是默认值
• OnFailure ： 容器终止运行且退出码不为0时重启
• Never ： 不论状态为何，都不重启该容器

重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。

Pod 调度

在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，我们可能想控制某些Pod到达某些节点上，Kubernetes也提供相应的方式来完成这种需求。Kubernetes提供了四种调度方式：

• 自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
• 定向调度：NodeName、NodeSelector
• 亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
• 污点（容忍）调度：Taints、Toleration

定向调度

定向调度的含义是Pod声明自己期望被调度到Node。我们可以在Pod上声明需要被调度到的目标Node，或者目标Node列表（以NodeSelector的形式提供）。由于定向调度是强制性的，因此如果期望的目标Node不存在的话，Pod会运行失败。这种方式实际上是直接跳过了Scheduler的调度逻辑，直接向目标Node上进行调度。

期望Node可以通过NodeName或者NodeSelector来提供，配置项的位置为spec.nodeName或者spec.nodeSelector。其中NodeSelector是基于label-selector机制进行匹配的，通常会选择出一组具有对应Label的Node作为目标Node。

# nodeName
spec:
	nodeName: node1

# nodeSelector
spec:
	nodeSelector:
		nodeenv: preprod  # 指定调度到具有nodeenv=preprod标签的节点上

亲和性调度

亲和性调度描述的是一种调度的倾向。与定向调度的强制性不同，亲和性调度会优先满足倾向条件，但是如果实在没有办法满足的话，Pod还是能够运行，这样使得调度更加灵活。

亲和性实际上描述的是是否将两个Pod部署得更加靠近，如果两个Pod之间交互频繁，那么就可以认为它们之间具有亲和性，因此就可以尽可能得将其部署在同一个Node上，减少网络传输带来的性能损耗。不过在进行应用的多副本部署的时候，反而要注意不应该将Pod都部署在同一个Node上，这样不利于提高服务的高可用性。

亲和性调度主要分为以下三种类型：

• nodeAffinity：描述Node倾向于接受哪些Pod
• podAffinity：描述Pod倾向于和哪些已经被调度的Pod部署在一起
• podAntiAffinity：描述Pod倾向于不和哪些已经被调度的Pod部署在一起

污点和容忍

前面的调度方式都是站在Pod的角度上，通过在Pod上添加属性，来确定Pod是否要调度到指定的Node上，其实我们也可以站在Node的角度上，通过在Node上添加污点(Traints)属性，来决定是否允许Pod调度过来。

在Node上如果添加了污点Traints，就表示这个Node会拒绝这类Node调度过来，甚至可以将已经存在的Pod进行驱逐。实际上，如果我们使用的是kubeadm来搭建的集群，默认就会给master节点添加一个污点标记,所以pod就不会调度到master节点上。

污点的格式为：key=value:effect, key和value是污点的标签，effect描述污点的作用，支持如下三个选项：

• PreferNoSchedule：kubernetes将尽量避免把Pod调度到具有该污点的Node上，除非没有其他节点可调度
• NoSchedule：kubernetes将不会把Pod调度到具有该污点的Node上，但不会影响当前Node上已存在的Pod
• NoExecute：kubernetes将不会把Pod调度到具有该污点的Node上，同时也会将Node上已存在的Pod驱离

可以使用kubectl命令行来设置和去除污点：

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

# 去除污点[减号]
kubectl taint nodes node1 key:effect-

# 去除所有污点[减号]
kubectl taint nodes node1 key-

容忍(Toleration)与污点的作用正好是相反的，污点的作用是让Node拒绝某些Pod；而容忍的作用是强制让这类Pod调度到Node上。容忍是针对与污点来说的，污点表示Node的拒绝策略，而容忍污点表示Pod忽略这种拒绝策略。容忍的相关配置在spec.tolerations中：

KIND:     Pod
VERSION:  v1
RESOURCE: tolerations <[]Object>
FIELDS:
   key       # 对应着要容忍的污点的键，空意味着匹配所有的键
   value     # 对应着要容忍的污点的值
   operator  # key-value的运算符，支持Equal和Exists（默认）
   effect    # 对应污点的effect，空意味着匹配所有影响
   tolerationSeconds   # 容忍时间, 当effect为NoExecute时生效，表示pod在Node上的停留时间

Pod Controller

简介

Pod是Kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：

• 自主式pod：Kubernetes直接创建出来的Pod，这种pod删除后就没有了，也不会重建
• 控制器创建的pod：kubernetes通过控制器创建的pod，这种pod删除了之后还会自动重建

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器我们最终的期望状态就行，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod。

在Kubernetes中，有很多类型的pod控制器，每种都有自己的适合的场景，常见的有下面这些：

• ReplicaSet：保证副本数量一直维持在期望值，并支持pod数量扩缩容，镜像版本升级
• Deployment：通过控制ReplicaSet来控制Pod，并支持滚动升级、回退版本
• Horizontal Pod Autoscaler：可以根据集群负载自动水平调整Pod的数量，实现削峰填谷
• DaemonSet：在集群中的指定Node上运行且仅运行一个副本，一般用于守护进程类的任务
• Job：创建出来的pod只要完成任务就立即退出，不需要重启或重建，用于执行一次性任务
• Cronjob：它创建的Pod负责周期性任务控制，不需要持续后台运行

ReplicaSet(RS)

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

ReplicaSet的资源清单描述如下：

apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: # 标签
    controller: rs
spec: # 详情描述
  replicas: 3 # 副本数量，即需要创建出Pod的数量，默认为1
  selector: # 选择器，通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本，其中的字段与Pod相关字段基本相同
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

如果需要临时执行扩缩容的话，直接修改对应的yaml配置文件即可，Pod Controller会监测配置文件并确保系统的最终状态符合文件的描述。

# 可以通过edit命令修改对应配置文件，该命令会唤起编辑器
kubectl edit rs <rs-name> -n <namespace>

当然也可以直接使用scale命令进行扩缩容，直接在--replicas=n后面指定目标数量即可：

# scale扩缩容
kubectl scale rs <rs-name> --replicas=xx

如果需要升级镜像的话，也可以通过编辑配置文件的命令来完成，或者通过set image命令来完成：

# set image更新镜像
# kubectl set image rs rs名称 容器=镜像版本 -n namespace
kubectl set image rs <rs-name> <container-name>=<image_name>:<version>

Deployment(Deploy)

为了更好的解决服务编排的问题，Kubernetes在V1.2版本开始，引入了Deployment Pod 控制器。这种控制器并不直接管理pod，而是通过管理ReplicaSet来简介管理Pod，因此Deployment比ReplicaSet功能更加强大。

除了支持ReplicaSet的所有功能之外，Deployment还支持发布的停止和继续，支持版本的滚动升级和回滚等。

Deployment的资源清单描述如下：

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: deploy
spec: # 详情描述
  replicas: 3 # 副本数量
  revisionHistoryLimit: 3 # 保留历史版本
  paused: false # 暂停部署，默认是false，决定创建了Deployment之后是暂停，还是直接创建Pod
  progressDeadlineSeconds: 600 # 部署超时时间（s），默认是600
  strategy: # 镜像更新策略
    type: RollingUpdate # 滚动更新策略
    rollingUpdate: # 滚动更新
      maxSurge: 30% # 最大额外可以存在的副本数，可以为百分比，也可以为整数
      maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值，可以为百分比，也可以为整数
  selector: # 选择器，通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

Deployment的扩缩容操作与ReplicaSet相同，可以通过修改配置文件或者scale命令来完成。

在镜像更新方面，Deployment支持两种更新策略:Recreate和RollingUpadte,可以通过strategy指定策略类型,支持两个属性:默认滚动更新。

• Recreate：在创建出新的Pod之前会先杀掉所有已存在的Pod
• RollingUpdate：杀死一部分，再启动一部分，在更新过程中，存在两个版本Pod

Deployment还支持版本升级过程中的暂停、继续功能以及版本回退等诸多功能。实际上，Deplyment会保存历史过程中的ReplicaSet，如果需要进行回退，可以直接重新调用原来的ReplicaSet。

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

- status	显示当前升级状态
- history   显示 升级历史记录
- pause    暂停版本升级过程
- resume   继续已经暂停的版本升级过程
- restart    重启版本升级过程
- undo 回滚到上一级版本（可以使用--to-revision回滚到指定版本）

补充：金丝雀发布

金丝雀发布指的是在发布过程中先让一部分Pod进行更新，此时在整个提供服务的Pod中，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。

Horizontal Pod Autoscaler(HPA)

Horizontal Pod Autoscaler(HPA)能够完成Pod数量的动态调整，即自动化扩缩容。

HPA可以获取每个Pod利用率，然后和HPA中定义的指标进行对比，同时计算出需要伸缩的具体值，最后实现Pod的数量的调整。其实HPA与之前的Deployment一样，也属于一种Kubernetes资源对象，它通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数。

DaemonSet(DS)

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

每当向集群中添加一个Node的时候，指定的Pod副本也会添加到该节点上；当节点从集群中移除时，Pod也会被垃圾回收。

Job

Job，主要用于负责批量处理短暂的，一次性的(每个任务仅运行一次就结束)任务。当Job创建的pod执行成功结束时，Job将记录成功结束的pod数量；当成功结束的pod达到指定的数量时，Job将完成执行

Job的资源描述如下：

apiVersion: batch/v1 # 版本号
kind: Job # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: job
spec: # 详情描述
  completions: 1 # 指定job需要成功运行Pods的次数。默认值: 1
  parallelism: 1 # 指定job在任一时刻应该并发运行Pods的数量。默认值: 1
  activeDeadlineSeconds: 30 # 指定job可运行的时间期限，超过时间还未结束，系统将会尝试进行终止。
  backoffLimit: 6 # 指定job失败后进行重试的次数。默认是6
  manualSelector: true # 是否可以使用selector选择器选择pod，默认是false
  selector: # 选择器，通过它指定该控制器管理哪些pod
    # ...
  template: # 模板，当副本数量不足时，会根据下面的模板创建pod副本
   	# ...
    spec:
      restartPolicy: Never # 重启策略只能设置为Never或者OnFailure
      containers:
      	# ...

CronJob(CJ)

CronJob控制器以 Job控制器资源为其管控对象，并借助它管理pod资源对象。Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但CronJob可以用作定时任务，控制其运行时间点和重复运行的方式。调度方式使用Linux中的cron格式描述，可以参考How to Set Up a Cron Job in Linux? {Schedule Tasks} | PhoenixNAP KB

CronJob的资源描述如下：

apiVersion: batch/v1beta1 # 版本号
kind: CronJob # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: cronjob
spec: # 详情描述
  schedule: # cron格式的作业调度运行时间点,用于控制任务在什么时间执行
  concurrencyPolicy: # 并发执行策略，用于定义前一次作业运行尚未完成时是否以及如何运行后一次的作业
  failedJobHistoryLimit: # 为失败的任务执行保留的历史记录数，默认为1
  successfulJobHistoryLimit: # 为成功的任务执行保留的历史记录数，默认为3
  startingDeadlineSeconds: # 启动作业错误的超时时长
  jobTemplate: # job控制器模板，用于为cronjob控制器生成job对象;下面其实就是job的定义
   # ...

其中并发执行策略有三种选项：

• Allow：允许Jobs并发运行(默认)
• Forbid：禁止并发运行，如果上一次运行尚未完成，则跳过下一次运行
• Replace：替换，取消当前正在运行的作业并用新作业替换它