pod控制器

空中连线

已于 2024-07-06 21:03:35 修改

阅读量579

点赞数 24

文章标签： kubernetes 容器云原生

于 2024-05-31 00:06:07 首次发布

本文链接：https://blog.csdn.net/mcb134/article/details/139322529

版权

一 Pod控制器及其功用

Pod控制器，又称之为工作负载（workload），是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试进行重启，当根据重启策略无效，则会重新新建pod的资源。

od是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元，一个node可以有多个Pod。

Pod（就像在鲸鱼荚或者豌豆荚中）是一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。 Pod 所建模的是特定于应用的 “逻辑主机”，其中包含一个或多个应用容器，这些容器相对紧密地耦合在一起。在非云环境中，在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。

除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 Init 容器。

Pod可以分为：自主式Pod(不是控制器控制的pod, 死了没人拉起来)，控制器管理的Pod。

自主式Pod：（不是被控制器管理的Pod）：死亡后不会被拉起来，也不会有人创建新的Pod：

每个Pod里运行着一个特殊的被称为Pause容器，其他容器为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交互更为高效。

在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中，同一个Pod里的容器之间仅需通过localhost就能互相通信。

1 pod控制器有多种类型：

1） ReplicaSet:

代表用户创建指定数量的pod副本，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能。

ReplicaSet主要三个组件组成：

用户期望的pod副本数量
标签选择器，判断哪个pod归自己管理
当现存的pod数量不足，会根据pod资源模板进行新建

帮助用户管理无状态的pod资源，精确反应用户定义的目标数量，但是RelicaSet不是直接使用的控制器，而是使用Deployment。

2） Deployment：

工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功

能，还提供声明式配置。

ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。

3 ）DaemonSet：

用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。

比如ELK服务特性：服务是无状态的；服务必须是守护进程(微服务就是无状态)

确保每个节点上都运行着一个指定的 Pod 实例，比如日志收集、监控代理等。当有新的节点加入集群时，DaemonSet 会自动在新节点上创建 Pod；节点从集群移除时，对应的 Pod 也会被清理。

4） StatefulSet：管理有状态应用

StatefulSet 中的每个 Pod 都有唯一的、持久的标识符和稳定的存储卷。它确保 Pod 按顺序启动和关闭（理论上是倒序），且在重启后仍能访问相同的存储资源，这对于维护数据一致性至关重要。

5 ）Job：只要完成就立即退出，不需要重启或重建

用于运行完成特定次数后终止的 Pod，即执行一次性或批处理任务。只要完成就立即退出，不需要重启或重建

6） Cronjob：周期性任务控制，不需要持续后台运行

周期性任务控制，基于时间调度来定期执行 Job，类似于Linux的cron定时任务，不需要持续后台运行。

二 Pod与控制器之间的关系

controllers：在集群上管理和运行容器的 pod 对象， pod 通过 label-selector 相关联。
Pod 通过控制器实现应用的运维，如伸缩，升级等。

可以理解为：Pod 与控制器之间是一种管理和被管理的关系，控制器利用 K8s 的标签系统来识别和控制其管理的 Pod 集合，从而实现了应用的自动化运维和高可用性。

1 Deployment 部署无状态应用

部署无状态应用
管理Pod和ReplicaSet（为了保证其副本）
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景：web服务

案例

部署并维护一个由2个副本组成的 Nginx 服务，管理 Pod 和 ReplicaSet；应用场景：web服务。

vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx	
spec:
  replicas: 3
  selector:   #标签选择器
    matchLabels:
      app: nginx
  template:    #模板
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

kubectl create -f nginx-deployment.yaml

kubectl get pods,deploy,rs    #看副本信息

也可以用命令行编辑文本

kubectl create deployment nginx-deployment --image=ngigx:1.15 --port=80 --replicas=1 --dry-run=client -oyaml > nginx-deployment

① 获取集群中Pods、Deployments、以及 ReplicaSets 的信息

kubectl get pod,deploy,rs

排错总结：一直在创建或者等待中可能需要重启

① 查看控制器配置

kubectl edit deployment/nginx-deployment

查看控制器配置
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2021-04-19T08:13:50Z"
  generation: 1
  labels:
    app: nginx					#Deployment资源的标签
  name: nginx-deployment
  namespace: default
  resourceVersion: "167208"
  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/nginx-deployment
  uid: d9d3fef9-20d2-4196-95fb-0e21e65af24a
spec:
  progressDeadlineSeconds: 600
  replicas: 3					#期望的pod数量，默认是1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:
    rollingUpdate:
      maxSurge: 25%				#升级过程中会先启动的新Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
      maxUnavailable: 25%		#升级过程中在新的Pod启动好后销毁的旧Pod的数量不超过期望的Pod数量的25%，也可以是一个绝对值
    type: RollingUpdate			#滚动升级
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx				#Pod副本关联的标签
    spec:
      containers:
      - image: nginx:1.15.4				#镜像名称
        imagePullPolicy: IfNotPresent	#镜像拉取策略
        name: nginx
        ports:
        - containerPort: 80				#容器暴露的监听端口
          protocol: TCP
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always				#容器重启策略
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

② 查看历史版本

kubectl rollout history deployment/nginx-deployment

查看历史版本
kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment
REVISION  CHANGE-CAUSE
1         <none>

总结：

deployment 部署无状态应用的管理RS和创建Pod ，主要是维护pod副本数量与期望状态相同
创建和删除pod时并行执行(升级时是想创建一部分再删除一部分

2 SatefulSet--部署有状态应用

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现

有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现

DNS解析：就是把名称解析为ip地址

有序收缩，有序删除（即从N-1到0）

常见的应用场景：数据库statefulSets | K8s

https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

① StatefulSet由三部分组成：

Headless Service（无头服务）：用于为Pod资源标识符生成可解析的DNS记录。
volumeClaimTemplates（存储卷申请模板）：基于静态或动态PV供给方式为Pod资源提供专有的固定存储。
StatefulSet：用于管控Pod资源。

② 为什么要有headless？

在deployment中，每一个pod是没有名称，是随机字符串，是无序的。

而statefulset中是要求有序的，每一个pod的名称必须是固定的。

当节点挂了，重建之后的标识符是不变的，每一个节点的节点名称是不能改变的。pod名称是作为pod识别的唯一标识符，必须保证其标识符的稳定并且唯一。

为了实现标识符的稳定，这时候就需要一个headless service 解析直达到pod，还需要给pod配置一个唯一的名称。

③ 为什么要有volumeClainTemplate？

大部分有状态副本集都会用到持久存储，比如分布式系统来说，由于数据是不一样的，每个节点都需要自己专用的存储节点。而在 deployment中pod模板中创建的存储卷是一个共享的存储卷，

多个pod使用同一个存储卷，而statefulset定义中的每一个pod都不能使用同一个存储卷，由此基于pod模板创建pod是不适应的，这就需要引入volumeClainTemplate，

当在使用statefulset创建pod时，会自动生成一个PVC，从而请求绑定一个PV，从而有自己专用的存储卷。

服务发现：就是应用服务之间相互定位的过程。

④ 应用场景：

① 动态性强：Pod会飘到别的node节点

② 更新发布频繁：互联网思维小步快跑，先实现再优化，老板永远是先上线再慢慢优化，先把

idea变成产品挣到钱然后再慢慢一点一点优化

③支持自动伸缩：一来大促，肯定是要扩容多个副本

K8S里服务发现的方式---DNS，使K8S集群能够自动关联Service资源的“名称”和“CLUSTER-IP”，从而达到服务被集群自动发现的目的。

⑤ 实现K8S里DNS功能的插件：

skyDNS：Kubernetes 1.3之前的版本
kubeDNS：Kubernetes 1.3至Kubernetes 1.11
CoreDNS：Kubernetes 1.11开始至今

三安装CoreDNS，仅二进制部署环境需要安装CoreDNS

CoreDNS是一个开源的、轻量级的域名系统（DNS）服务器，用于在Kubernetes集群中提供服务发现和DNS解析服务。旨在替代Kubernetes集群中默认的kube-dns组件。

方法一：下载链接：

https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/dns/coredns/coredns.yaml.base

vim transforms2sed.sed
s/__DNS__SERVER__/10.0.0.2/g
s/__DNS__DOMAIN__/cluster.local/g
s/__DNS__MEMORY__LIMIT__/170Mi/g
s/__MACHINE_GENERATED_WARNING__/Warning: This is a file generated from the base underscore template file: coredns.yaml.base/g

sed -f transforms2sed.sed coredns.yaml.base > coredns.yaml

方法二：上传 coredns.yaml 文件
kubectl create -f coredns.yaml
kubectl get pods -n kube-system

1 先定义nginx-svc yaml

[root@master01 controller]# vim nginx-deployment.yaml
apiVersion: v1  
kind: Service  
metadata:
  name: nginx-service
  labels:
    app: nginx  
spec:
  type: NodePort  
  ports:
  - port: 80
    targetPort: 80  
  selector:
    app: nginx

2 创建nginx-svc

kubectl create -f coredns.yaml

kubectl get pods -n kube-system

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2024-05-17T08:38:00Z"
  labels:
    app: nginx
  name: nginx
  namespace: default
  resourceVersion: "10660"
  uid: 39063d6c-98ba-42be-9dee-253638c5fd48
spec:
  clusterIP: 10.96.54.9
  clusterIPs:
  - 10.96.54.9
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 30895
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

3 再定义一个dns-pod.yaml

简化版

apiVersion: v1
kind: Pod
metadata:
  name: dns-buxybox
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
     - /bin/sh
     -  -c
     - sleep 3600
  restartPolicy: Never

注意：因为K8s是内部解析方式所以暂时无法解析

4 但是进入容器对容器进行这样解析

5 查看statefulset的定义

kubectl explain statefulset
FIELDS:
   podManagementPolicy	<string>  #Pod管理策略
   replicas	<integer>    #副本数量
   revisionHistoryLimit	<integer>   #历史版本限制
   selector	<Object> -required-    #选择器，必选项
   serviceName	<string> -required-  #服务名称，必选项
   template	<Object> -required-    #模板，必选项
   updateStrategy	<Object>       #更新策略
   volumeClaimTemplates	<[]Object>   #存储卷申请模板，必选项

② 清单定义StatefulSet

如上所述，一个完整的 StatefulSet 控制器由一个 Headless Service、一个 StatefulSet 和一个 volumeClaimTemplate 组成。定义一个Kubernetes StatefulSet资源和一个Headless Service（无头服务），用于部署一个有状态应用：

③ 继续部署定义资源清单

vim stateful-demo.yaml

没有修改的yaml文件

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp-sts
spec:
  selector:
    matchLabels:
      app: myapp-sts # 必须匹配 .spec.template.metadata.labels
  serviceName: "sts-svc"
  replicas: 3 # 默认值是 1
  template:
    metadata:
      labels:
        app: myapp-sts # 必须匹配 .spec.selector.matchLabels
    spec:
      containers:
      - name: myapp
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-client-storageclass"
      resources:
        requests:
          storage: 1Gi

由于 StatefulSet 资源依赖于一个实现存在的 Headless 类型的 Service
资源，所以需要先定义一个名为 myapp-svc 的 Headless Service 资源，用于为关联到每个 Pod 资源创建
DNS 资源记录。接着定义了一个名为 myapp 的 StatefulSet 资源，它通过 Pod 模板创建了 3 个 Pod
资源副本，并基于 volumeClaimTemplates 向前面创建的PV进行了请求大小为 2Gi 的专用存储卷。

创建无头服务myapp-svc

查看绑定的pvc

查看绑定的pv

查看statefulset

④ 静态创建-stor01节点

mkdir -p /data/volumes/v{1,2,3,4,5}


配置NFS共享
vim /etc/exports
/data/volumes/v1 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v2 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v3 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v4 192.168.80.0/24(rw,no_root_squash)
/data/volumes/v5 192.168.80.0/24(rw,no_root_squash)

重启NFS服务

systemctl restart rpcbind
systemctl restart nfs

exportfs -arv   #重新导出共享

showmount -e    #查看共享列表

7 定义PV的yaml文件

注意：此pv-yaml文件要在上一篇博客动态pv建立

vim pv-demo.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv001
  labels:
    name: pv001
spec:
  nfs:
    path: /data/volumes/v1
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv002
  labels:
    name: pv002
spec:
  nfs:
    path: /data/volumes/v2
    server: stor01
  accessModes: ["ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
  labels:
    name: pv003
spec:
  nfs:
    path: /data/volumes/v3
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv004
  labels:
    name: pv004
spec:
  nfs:
    path: /data/volumes/v4
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv005
  labels:
    name: pv005
spec:
  nfs:
    path: /data/volumes/v5
    server: stor01
  accessModes: ["ReadWriteMany","ReadWriteOnce"]
  capacity:
    storage: 2Gi

kubectl apply -f pv-demo.yaml

kubectl get pv

这些 PV 定义使得 Kubernetes 集群能够使用 NFS 共享作为持久化存储。在 StatefulSet 或其他需要持久化存储的工作负载中，可以通过 PersistentVolumeClaim (PVC) 来请求这些 PV。这样，即使 Pod 在集群中重新调度，它们也能保持对这些共享存储的访问，这对于有状态的应用（如数据库）来说非常重要。

在上一篇博客动态pv基础上添加页面内容

8 解析dns

已创建statefulset

apiVersion: v1
kind: Service
metadata:
  labels:
    app: sts-svc
  name: sts-svc
  namespace: default
spec：
  clusterIP: None
  ports:
  - port: 80
    name: http
    protocol: TCP
    targetPort: 80
  selector:
    app: myapp-sts
  type: ClusterIP

kubectl get spv

kubectl apply -f stateful-demo.yaml 

kubectl get svc  #查看创建的无头服务myapp-svc

文本位置

piVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp-sts
spec:
  selector:
    matchLabels:
      app: myapp
  serviceName: "sts-svc"
  replicas: 3 # 默认值是 1
  template:
    metadata:
      labels:
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp-sts
spec:
  selector:
    matchLabels:
      app: myapp-sts
  serviceName: "sts-svc"
  replicas: 3 # 默认值是 1
  template:
    metadata:
      labels:
        app: myapp-sts
    spec:
      containers:
      - name: myapp
        image: soscscs/myapp:v1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "nfs-client-storageclas"
      resources:
        requests:
          storage: 1Gi

删除 statefulset

当删除的时候是从myapp-2开始进行删除的，关闭是逆向关闭（不过一般是同时删除）；然后再次创建，观察 pod 创建详情：

查看创建结果

k8s内部的负载均衡，访问的时候会根据资源占比进行调度，会调度到资源少的，请求少的pod，不会负载均衡轮询的调度

K8S的内部负载均衡是根据资源的请求量，每次登入数据库所查看的数据不同，根据内部的不同调度，可能每次调度的节点都不同

滚动更新

StatefulSet 控制器将在 StatefulSet 中删除并重新创建每个 Pod。它将以与 Pod 终止相同的顺序进行（从最大的序数到最小的序数），每次更新一个 Pod。在更新其前身之前，它将等待正在更新的 Pod 状态变成正在运行并就绪。如下操作的滚动更新是按照2-0的顺序更新。

vim stateful-demo.yaml #修改image版本为v2

kubectl  get pods -w   #查看滚动更新的工程 （倒叙更新）

kubectl  get pod

查看pvc pv绑定

kubectl get pvc,pv

在创建的每一个Pod中，每一个pod自己的名称都是可以被解析的

kubectl exec -it myapp-0 /bin/sh

总结

无状态：

1）deployment 认为所有的pod都是一样的
2）不用考虑顺序的要求
3）不用考虑在哪个node节点上运行
4）可以随意扩容和缩容 

有状态

1）实例之间有差别，每个实例都有自己的独特性，元数据不同，例如etcd，zookeeper
2）实例之间不对等的关系，以及依靠外部存储的应用。

常规service和无头服务区别

service：一组Pod访问策略，提供cluster-IP群集之间通讯，还提供负载均衡和服务发现。
Headless service：无头服务，不需要cluster-IP，而是直接以DNS记录的方式解析出被代理Pod的                                                                                                IP地址

三 DaemonSet 一次创建多个节点

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

使用 DaemonSet 的一些用法：

运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph。
在每个 Node 上运行日志收集 daemon，例如fluentd（可在每台机器收集日志）、logstash。
在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond。

应用场景：Agent

官方案例（监控）

https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/

案例

vim ds.yaml 
apiVersion: apps/v1
kind: DaemonSet 
metadata:
  name: nginx-daemonSet
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

kubectl apply -f ds.yaml

DaemonSet会在每个node节点都创建一个Pod
kubectl get pods

若把他们删除怎么样

四 Job

Job分为普通任务（Job）和定时任务（CronJob）
常用于运行那些仅需要执行一次的任务（如数据扩容删除）
应用场景：数据库迁移、批处理脚本、kube-bench扫描、离线数据处理，视频解码等业务

https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/

apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
        - name: busybox
          image: busybox
          imagePullPolicy: IfNotPresent
          command: ["/bin/sh", "-c", "sleep 10;date;exit 1"]
      restartPolicy: Never
  backoffLimit: 2

kubectl describe job busybox

五 CronJob

周期性任务，像Linux的Crontab一样。
周期性任务
应用场景：通知，备份

https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/

每分钟打印hello

vim cronjob.yaml
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

cronjob其它可用参数的配置
spec:
  concurrencyPolicy: Allow			#要保留的失败的完成作业数（默认为1）
  schedule: '*/1 * * * *'			#作业时间表。在此示例中，作业将每分钟运行一次
  startingDeadlineSeconds: 15		#pod必须在规定时间后的15秒内开始执行，若超过该时间未执行，则任务将不运行，且标记失败
  successfulJobsHistoryLimit: 3		#要保留的成功完成的作业数（默认为3）
  terminationGracePeriodSeconds: 30	#job存活时间 默认不设置为永久
  jobTemplate:						#作业模板。这类似于工作示例