kubernetes----资源控制器5

linuxkubernetes

资源控制器

什么是控制器
Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为

控制器类型

ReplicationController 和 ReplicaSet
Deployment
DaemonSet
StateFulSet
Job/CronJob
Horizontal Pod Autoscaling

ReplicationController 和 ReplicaSet

ReplicationController（RC）用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退
出，会自动创建新的 Pod 来替代；而如果异常多出来的容器也会自动回收
在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector (根据标签进行选择和控制)

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括

定义 Deployment 来创建 Pod 和 ReplicaSet ,DP-->RS-->POD

滚动升级和回滚应用

扩容和缩容

暂停和继续 Deployment

命令式编程：它侧重于如何实现程序，就像我们刚接触编程的时候那样，我们需要把程序的实现过程，按照逻辑结果一步步写下
声明式编程：它侧重于定义想要什么，然后告诉计算机/引擎，让他帮你去实现

命令式编程，手把手教 create 推荐最优方案
声明式编程，只要结果 apply 推荐最优方案

DaemonSet

DaemonSet 确保全部（或者一些） Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod (你的管理者不存在，也就相当于没有意义；只能定义一个，或定义多个daemonset)

使用 DaemonSet 的一些典型用法：

运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph

在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash

在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、 New Relic 代理，或 Ganglia gmond

示例

[root@k8s-master test]# cat daemonset.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: deamonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset-example
  template:
    metadata:
      labels:
        name: deamonset-example
    spec:
      containers:
      - name: daemonset-example
        image: wangyanglinux/myapp:v1
		
在每个节点下都会创建一个dameset
[root@k8s-master test]# kubectl get nodes
NAME            STATUS                     ROLES    AGE   VERSION
192.168.10.81   Ready,SchedulingDisabled   master   12d   v1.20.2
192.168.10.82   Ready                      node     12d   v1.20.2
192.168.10.83   Ready                      node     12d   v1.20.2
[root@k8s-master test]# kubectl get pods -o wide
NAME                      READY   STATUS    RESTARTS   AGE   IP              NODE            NOMINATED NODE   READINESS GATES
deamonset-example-c9b6w   1/1     Running   0          9s    10.20.169.160   192.168.10.83   <none>           <none>
deamonset-example-nt24q   1/1     Running   0          9s    10.20.235.195   192.168.10.81   <none>           <none>
deamonset-example-xxdhn   1/1     Running   0          9s    10.20.36.101    192.168.10.82   <none>           <none>

Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束 （能保证计划任务执行是成功的，是一种机制，也可以针对脚本正常退出的次数来判断）

spec.template格式同Pod

RestartPolicy仅支持Never或OnFaulure

单个Pod时，默认Pod成功运行后Job即结束

.spec.completions标志Job结束需要成功运行的Pod个数，默认为1

.spec.parallelism标志并行运行的Pod的个数，默认为1

spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

示例

[root@k8s-master test]# cat job.yaml 
apiVersion: batch/v1
kind: Job
metadata: 
  name: pi 
spec: 
  template:
    metadata: 
      name: pi 
    spec: 
      containers: 
      - name: pi 
        image: perl 
        command : ["perl", "-Mbignum=bpi", "-wle", "print bpi (2000)"]
      restartPolicy: Never
	  
	  
kubectl apply -f job.yaml 

[root@k8s-master test]# kubectl get job 
NAME   COMPLETIONS   DURATION   AGE
pi     1/1           35s        39s

查看POD中的日志，圆周率小数2000位
[root@k8s-master test]# kubectl logs pi-4k6zl 
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901

CronJob 在特定的时间循环创建Job

Cron Job 管理基于时间的 Job，即：（类似系统中的计划任务 * * * * * ）

在给定时间点只运行一次
周期性地在给定时间点运行

使用前提条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）。对于先前版本的集群，版本 <
1.8，启动 API Server时，通过传递选项 --runtime-config=batch/v2alpha1=true 可以开启 batch/v2alpha1
API

典型的用法如下所示：

在给定的时间点调度 Job 运行
创建周期性运行的 Job，例如：数据库备份、发送邮件

.spec.schedule：调度，必需字段，指定任务运行周期，格式同Cron

.spec.jobTemplate：Job模板，必需字段，指定需要运行的任务，格式同Job

.spec.startingDeadlineSeconds：启动Job的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限

.spec.concurrencyPoliy：并发策略，该字段也是可选的。它指定了如何处理被Cron Job创建的Job的并发执行。只允许指定下面策略中的一种：
Allow(默认)：允许并发运行Job
Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
Replace：取消当前正在运行的Job，用一个新的来替换
注意，当前策略只能应用于同一个Cron Job创建Job。如果存在多个Cron Job，它们创建的Job之前总是允许并发运行
.spec.suspend：扶起，该字段也是可选的。如果设置true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认为false
.spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit：历史限制，是可选的字段。它们指定了可保留多少完成的失败的Job。默认情况下，它们分别设置为3和1。设置限制的值为0，相关类型的Job完成后将不会被保留

示例

[root@k8s-master test]# cat cronjob.yaml 
apiVersion: batch/v1beta1
kind: CronJob
metadata: 
 name: hello 
spec: 
 schedule: "*/1 * * * *"
 jobTemplate:
   spec:
     template:
       spec: 
         containers: 
         - name: hello
           image: busybox 
           args:
           - /bin/sh
           - -c
           - date; echo Hello from the Kubernetes cluster
         restartPolicy: OnFailure
   	  
active激活一次
[root@k8s-master test]# kubectl get cronjobs.batch 	
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     1        6s              64s

查看jobs任务
[root@k8s-master test]# kubectl get jobs
NAME               COMPLETIONS   DURATION   AGE
hello-1616746260   1/1           18s        33s

[root@k8s-master test]# kubectl logs hello-1616746260-95rm2 
Fri Mar 26 08:11:23 UTC 2021
Hello from the Kubernetes cluster

kubectl delete cronjob hello

StatefulSet

StatefulSet 作为 Controller 为 Pod 提供唯一的标识。它可以保证部署和 scale 的顺序
StatefulSet 需要接触到存储
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计），其应用
场景包括：

稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现 （假设一个POD存储使用一个储存卷，当然也可以使用多个，当POD挂了，SS会保持副本数量重新创建，创建完成后继续使用上一个储存使用卷来达到持久化存储的效果）
稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有 Cluster IP的Service）来实现（使用PodName或HostName来决定连接对象）
有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到 N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现（START STOP readiness 都需要更改POD容器中的镜像，但INITC不需要，只需要StatefulSet POD容器运行前面加INITC，不会对原有POD发生改变）
有序收缩，有序删除（即从N-1到0）（注意顺序，部署顺序和启动顺序是相反的）

Horizontal Pod Autoscaling

自动扩展，简单来说就是控制器的附属品
比如，创建Deployment，在创建HPA管理Deployment
HPA需要接触到资源收集模块
应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod 个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放

RS 与 RC 与 Deployment 关联

RC （ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收

Kubernetes 官方建议使用 RS（ReplicaSet ）替代 RC （ReplicationController ）进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

自主式POD，删除就没了，但控制器下的POD删除，会重新创建

示例RS

查看API版本
[root@k8s-master test]# kubectl explain rs.apiVersion
KIND:     ReplicaSet
VERSION:  apps/v1

[root@k8s-master test]# cat rs.yaml 
apiVersion: apps/v1
#apiVersion: extensions/v1beta1
kind: ReplicaSet 
metadata: 
  name: frontend 
spec: 
  replicas: 3 
  selector: 
    matchLabels: 
      tier: frontend 	#标签
  template: 
    metadata: 
      labels: 
        tier: frontend 
    spec: 
      containers: 
      - name: myapp
        image: wangyanglinux/myapp:v1
        env: 
        - name: GET_HOSTS_FROM 
          value: dns 
        ports: 
        - containerPort: 80
       
 kubectl apply -f rs.yaml 
 
 [root@k8s-master test]# kubectl get rs
NAME       DESIRED   CURRENT   READY   AGE
frontend   3         3         3       92s
[root@k8s-master test]# kubectl get pods
NAME             READY   STATUS    RESTARTS   AGE
frontend-lqwqr   1/1     Running   0          95s
frontend-pz8ck   1/1     Running   0          95s
frontend-sc9hw   1/1     Running   0          95s
查看标签
[root@k8s-master test]# kubectl get pods --show-labels
NAME             READY   STATUS    RESTARTS   AGE     LABELS
frontend-lqwqr   1/1     Running   0          4m49s   tier=frontend
frontend-pz8ck   1/1     Running   0          4m49s   tier=frontend
frontend-sc9hw   1/1     Running   0          4m49s   tier=frontend

[root@k8s-master test]# kubectl label pods frontend-sc9hw tier=frontend1
error: 'tier' already has a value (frontend), and --overwrite is false
[root@k8s-master test]# kubectl label pods frontend-sc9hw tier=frontend1 --overwrite=True
pod/frontend-sc9hw labeled

已经有4个POD了，RS通地匹配标签来决定frontend
[root@k8s-master test]# kubectl get pods --show-labels               
NAME             READY   STATUS    RESTARTS   AGE     LABELS
frontend-lqwqr   1/1     Running   0          6m26s   tier=frontend
frontend-pz8ck   1/1     Running   0          6m26s   tier=frontend
frontend-s7czl   1/1     Running   0          2s      tier=frontend
frontend-sc9hw   1/1     Running   0          6m26s   tier=frontend1

删除RS发现标签frontend1还存在，没有控制器管理
[root@k8s-master test]# kubectl delete rs --all
replicaset.apps "frontend" deleted
[root@k8s-master test]# kubectl get pods --show-labels 
NAME             READY   STATUS    RESTARTS   AGE     LABELS
frontend-sc9hw   1/1     Running   0          9m20s   tier=frontend1
删除此POD
[root@k8s-master test]# kubectl delete pods frontend-sc9hw

示例deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：

定义Deployment来创建Pod和ReplicaSet

[root@k8s-master test]# kubectl explain deployment.apiVersion
KIND:     Deployment
VERSION:  apps/v1

kubectl create deployment nginx --image=wangyanglinux/myapp:v1 --dry-run -o yaml > deployment.yaml

[root@k8s-master test]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: wangyanglinux/myapp:v1
        name: nginx

# --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化 
[root@k8s-master test]# kubectl apply -f deployment.yaml --record 
deployment.apps/nginx-deployment created

查看deployment
[root@k8s-master test]# kubectl get deployments.apps 
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           13s
[root@k8s-master test]# kubectl get rs
NAME                         DESIRED   CURRENT   READY   AGE
nginx-deployment-c5b4b46cc   3         3         3       10s
#这里记录的deployment名称+MD5值，POD后面在加上随机值
[root@k8s-master test]# kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-c5b4b46cc-4pjkd   1/1     Running   0          3s
nginx-deployment-c5b4b46cc-s66bh   1/1     Running   0          3s
nginx-deployment-c5b4b46cc-sn9t4   1/1     Running   0          3s

扩容和缩容

扩容共5个副本
[root@k8s-master test]# kubectl scale deployment nginx-deployment --replicas 5
deployment.apps/nginx-deployment scaled
[root@k8s-master test]# kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-c5b4b46cc-4pjkd   1/1     Running   0          65s
nginx-deployment-c5b4b46cc-rz8sf   1/1     Running   0          3s
nginx-deployment-c5b4b46cc-s66bh   1/1     Running   0          65s
nginx-deployment-c5b4b46cc-sn9t4   1/1     Running   0          65s
nginx-deployment-c5b4b46cc-wfq2w   1/1     Running   0          3s

如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展

kubectl autoscale deployment nginx --min=10 --max=15 --cpu-percent=80

滚动升级和回滚应用

更新镜像也比较简单

[root@k8s-master test]# kubectl get pods -o wide
NAME                               READY   STATUS    RESTARTS   AGE     IP             NODE            NOMINATED NODE   READINESS GATES
nginx-deployment-c5b4b46cc-4pjkd   1/1     Running   0          3m35s   10.20.36.117   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-rz8sf   1/1     Running   0          2m33s   10.20.36.112   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-s66bh   1/1     Running   0          3m35s   10.20.36.119   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-sn9t4   1/1     Running   0          3m35s   10.20.36.113   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-wfq2w   1/1     Running   0          2m33s   10.20.36.116   192.168.10.82   <none>           <none>
[root@k8s-master test]# curl 10.20.36.112
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

[root@k8s-master test]# kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v2 
deployment.apps/nginx-deployment image updated

旧版本的RS还存在
[root@k8s-master test]# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-77d768665b   5         5         5       106s
nginx-deployment-c5b4b46cc    0         0         0       7m
[root@k8s-master test]# kubectl get pods -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP             NODE            NOMINATED NODE   READINESS GATES
nginx-deployment-77d768665b-4sd4l   1/1     Running   0          90s   10.20.36.115   192.168.10.82   <none>           <none>
nginx-deployment-77d768665b-dd2pt   1/1     Running   0          90s   10.20.36.124   192.168.10.82   <none>           <none>
nginx-deployment-77d768665b-m9mx2   1/1     Running   0          88s   10.20.36.120   192.168.10.82   <none>           <none>
nginx-deployment-77d768665b-rpbgd   1/1     Running   0          90s   10.20.36.125   192.168.10.82   <none>           <none>
nginx-deployment-77d768665b-z9b4p   1/1     Running   0          88s   10.20.36.121   192.168.10.82   <none>           <none>
[root@k8s-master test]# curl 10.20.36.124
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

回滚

[root@k8s-master test]# kubectl rollout undo deployment/nginx-deployment
deployment.apps/nginx-deployment rolled back

[root@k8s-master test]# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-77d768665b   0         0         0       3m34s
nginx-deployment-c5b4b46cc    5         5         5       7m27s
[root@k8s-master test]# kubectl get pods -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP             NODE            NOMINATED NODE   READINESS GATES
nginx-deployment-c5b4b46cc-4hb5p   1/1     Running   0          16s   10.20.36.66    192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-59cjt   1/1     Running   0          18s   10.20.36.126   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-ljnbx   1/1     Running   0          18s   10.20.36.122   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-nr8nc   1/1     Running   0          16s   10.20.36.65    192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-t9jlh   1/1     Running   0          18s   10.20.36.123   192.168.10.82   <none>           <none>
[root@k8s-master test]# curl 10.20.36.126 
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

更新策略

删除所有deployment
kubectl delete deployment --all
创建deployment建议加上record
kubectl apply -f deployment.yaml --record 

#查看deployment所有版本，如果不创建时不加record，CHANGE-CAUSE字段会为空
[root@k8s-master test]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=deployment.yaml --record=true

当前镜像和deployment都是V1的版本，将镜像升级到V3的版本
 kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v3
查看更新流程
kubectl rollout status deployment/nginx-deployment

[root@k8s-master test]#  kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v2
deployment.apps/nginx-deployment image updated
[root@k8s-master test]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         kubectl apply --filename=deployment.yaml --record=true	#V1
2         kubectl apply --filename=deployment.yaml --record=true	#V3
3         kubectl apply --filename=deployment.yaml --record=true	#V2

当前是V2版本回滚到指定V1的版本
kubectl rollout undo deployment/nginx-deployment --to-revision=1  

可以使用 --revision参数指定某个历史版本 
[root@k8s-master test]# kubectl rollout history deployment/nginx-deployment
deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
2         kubectl apply --filename=deployment.yaml --record=true
3         kubectl apply --filename=deployment.yaml --record=true
4         kubectl apply --filename=deployment.yaml --record=true

[root@k8s-master test]# kubectl get pods -o wide
NAME                               READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE   READINESS GATES
nginx-deployment-c5b4b46cc-9hz75   1/1     Running   0          38s   10.20.36.83   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-ggdhm   1/1     Running   0          40s   10.20.36.84   192.168.10.82   <none>           <none>
nginx-deployment-c5b4b46cc-j2ncz   1/1     Running   0          39s   10.20.36.85   192.168.10.82   <none>           <none>
[root@k8s-master test]# curl  10.20.36.83 
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>

暂时deployment的更新
kubectl rollout pause deployment/nginx-deployment

小技巧

您可以用 kubectl rollout status 命令查看 Deployment 是否完成。如果 rollout 成功完成， kubectl rollout status 将返回一个0值的 Exit Code

$ kubectl rollout status deploy/nginx 
Waiting for rollout to finish: 2 of 3 updated replicas are available... 
deployment "nginx" successfully rolled out 
$ echo $? 
0

Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）
Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ）
未来的 Kuberentes 版本中，将从1-1变成25%-25%（25%一个阀值，可以在资源清单中进行修改，默认是25%）

kubectl describe deployments

清理 Policy
您可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision；如果将该项设置为0，Deployment 就不允许回退了（默认会保留所有历史版本，可以设置仅保留几次版本）

小结

1、deployment控制RS，RS控制PODS
2、升级和回滚操作，回滚指定某个版本
3、根据性能指标，扩容和缩容
4、使用deployment先定义好标签，规划好
5、创建deployment时，加上--record ，这样查看版本标签不会为空
6、计划任务

job执行一次
cronjob 周期性计划任务
cronjob创建POD进行管理
job状态会判断
cronjob会定期创建job，但不会状态判断(简单来说cronjob创建job)

幕等，多次执行结果还是一样
metadata.name == spec.selector.matchLabels.name