kubernetes 核心技术-controller

Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等，pod和controller之间通过yaml文件中的selector与label标签建立关系。

为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等。

ReplicaSet

实现了 Pod 的多副本管理，目的是在任何时候都维持一组稳定的pod副本，常用来确保指定数量的pod副本可用。

使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet，而是通过Deployment去使用ReplicaSet，这样的话我们就不需要担心和其他机制的冲突（如：ReplicaSet不支持滚动更新，但是Deployment支持）。

一个ReplicaSet的示例：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

ReplicaSet中.spec.template.metadata.labels必须跟spec.selector 相同，不然会被API拒绝。

使用kubectl delete可以删除ReplicaSet及其pod，Garbage collection默认会删除所有相关pod。若只想删除ReplicaSet而不删除pod，需要指定--cascade=false。删除ReplicaSet后，可以创建具有相同selector的ReplicaSet来管理原先的pod，但不会使用新ReplicaSet的podTemplate来更新原先的pod。若想自动更新pod，使用Deployment。

总之，不建议直接使用 ReplicaSet，而是通过Deployment去使用ReplicaSet。

Deployment

这是在使用kubernetes时候，大家部署系统或者是服务经常使用的一种controller类型。因为我们可以通过它来使用ReplicaSet来为我们部署的应用进行副本的创建。
一般在实际的运用中，大家用 Deployment 做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元。

使用deployment部署应用（基于yaml方式）

1.编写或生成yaml文件：kubectl create deployment nginx --image=nginx:1.8 --dry-run -o yaml > nginx.yaml

[root@master ~]# kubectl create deployment nginx --image=nginx:1.8 --dry-run -o yaml > nginx.yaml
W0413 03:47:05.133957   72422 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.
[root@master ~]# ll
-rw-r--r--  1 root root  388 Apr 13 03:47 nginx.yaml

注意，上一步的目的是快速的生成一个yaml模板，方便修改后使用，当然也可以自己直接写yaml文件。

在生成的yaml文件中，可以看到selector与label的匹配关系：

2.使用已生成的yaml文件部署应用：kubectl apply -f nginx.yaml

[root@master ~]# kubectl apply -f nginx.yaml 
deployment.apps/nginx created
[root@master ~]# kubectl get pod 
NAME                     READY   STATUS              RESTARTS   AGE
nginx-7c96855774-7h7bq   0/1     ContainerCreating   0          9s

3.对外发布（暴露对外端口），并重新生成yaml文件：kubectl expose deployment nginx --port=80 --type=NodePort --target-port=80 --name=nginx-server -o yaml > nginx-server.yaml

[root@master ~]# kubectl expose deployment nginx --port=80 --type=NodePort --target-port=80 --name=nginx-server -o yaml > nginx-server.yaml 
[root@master ~]# kubectl get pod,svc
NAME                         READY   STATUS    RESTARTS   AGE
pod/nginx-7c96855774-7h7bq   1/1     Running   0          10m

NAME                   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
service/kubernetes     ClusterIP   10.96.0.1       <none>        443/TCP        27d
service/nginx-server   NodePort    10.111.125.48   <none>        80:31491/TCP   26s
[root@master ~]# ll
total 32
-rw-r--r--  1 root root 1074 Apr 14 00:39 nginx-server.yaml
-rw-r--r--  1 root root  388 Apr 13 03:47 nginx.yaml

 这里两个yaml文件，nginx.yaml是pod的，nginx-server.yaml是service的（真实服务）。

应用升级与回滚（以nginx的pod为例）

1.新建版本为1.8 nginx的pod

yaml文件为：其中副本数为2

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.8
        name: nginx
        resources: {}
status: {}

使用yaml文件部署应用：由于yaml文件中副本数为2，会有2个pod

[root@master ~]# kubectl apply -f nginx.yaml 
deployment.apps/nginx created
[root@master ~]# kubectl get pods 
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7c96855774-jg8hm   1/1     Running   0          36s
nginx-7c96855774-ntwlw   1/1     Running   0          36s

2.升级nginx版本1.8至1.9：kubectl set image deployment nginx nginx=nginx:1.9

[root@master ~]# kubectl set image deployment nginx nginx=nginx:1.9
deployment.apps/nginx image updated
[root@master ~]# kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
nginx-77766dd89-fcm9r    0/1     ContainerCreating   0          16s
nginx-7c96855774-jg8hm   1/1     Running             0          16m
nginx-7c96855774-ntwlw   1/1     Running             0          16m

在这个过程中，可以使用命令来查看升级的状态：kubectl rollout status deployment nginx

[root@master ~]# kubectl rollout status deployment nginx
Waiting for deployment "nginx" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 out of 2 new replicas have been updated...
Waiting for deployment "nginx" rollout to finish: 1 old replicas are pending termination...
Waiting for deployment "nginx" rollout to finish: 1 old replicas are pending termination...
deployment "nginx" successfully rolled out

等到升级成功完毕后，再去查看pods：

[root@master ~]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
nginx-77766dd89-fcm9r   1/1     Running   0          5m20s
nginx-77766dd89-rld2x   1/1     Running   0          4m51s

可以发现，在升级的过程中，并不是直接kill掉原来的两个pod，而是启动玩新版本的pod后，再去kill掉老的，这种替换的机制保证了服务提供不间断。

另一方面，在node节点上也会发现已经有新版本的nginx镜像被下载：

[root@node1 ~]# docker images nginx*
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               1.9                 c8c29d842c09        4 years ago         183MB
nginx               1.8                 0d493297b409        5 years ago         133MB

3.回滚版本

每次rollout都会创建revision，默认系统会保存deployment的rollout，可通过指定revision来rollback deployment。

首先可以查看历史升级的版本： kubectl rollout history deployment nginx

[root@master ~]# kubectl rollout history deployment nginx
deployment.apps/nginx 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

其中第一个版本就是1.8，第二个版本都是1.9

如果是回滚到上一个版本：kubectl rollout undo deployment nginx

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

如果是回滚到指定版本：kubectl rollout undo deployment nginx --to-revision=2，其中--to-revision就是上述通过rollout history查询出来的版本号

[root@master ~]# kubectl rollout undo deployment nginx --to-revision=2
deployment.apps/nginx rolled back

最后可以通过查看deployment的详细信息来验证当前的版本：kubectl describe deployment nginx

[root@master ~]# kubectl describe deployment nginx
Name:                   nginx
Namespace:              default
CreationTimestamp:      Wed, 14 Apr 2021 05:50:54 +0800
Labels:                 app=nginx
Annotations:            deployment.kubernetes.io/revision: 4
Selector:               app=nginx
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.9

。。。。。。。。

应用弹性伸缩

当前只有2个pod，复制为10个：kubectl scale deployment nginx --replicas=10

[root@master ~]# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7c96855774-8m6q9   1/1     Running   0          7m31s
nginx-7c96855774-nzvld   1/1     Running   0          7m30s
[root@master ~]# kubectl scale deployment nginx --replicas=10
deployment.apps/nginx scaled
[root@master ~]# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7c96855774-2dk89   1/1     Running   0          9s
nginx-7c96855774-2ttfw   1/1     Running   0          9s
nginx-7c96855774-8m6q9   1/1     Running   0          8m41s
nginx-7c96855774-cn6vr   1/1     Running   0          9s
nginx-7c96855774-gfzrq   1/1     Running   0          9s
nginx-7c96855774-nzvld   1/1     Running   0          8m40s
nginx-7c96855774-r4sdt   1/1     Running   0          9s
nginx-7c96855774-rtdrb   1/1     Running   0          9s
nginx-7c96855774-vjzg2   1/1     Running   0          9s
nginx-7c96855774-vrqck   1/1     Running   0          9s

若cluster启动HPA(horizontal Pod autoscaling)，还可以设置deployment的autoscaler：

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

表示数量在10-15之间，cpu使用率为80%。

DaemonSet

用于每个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的，DaemonSet 通常用于运行 daemon（守护程序）。当有Node加入集群时，也会为他们新增一个Pod，当有Node从集群中移除时，这个Pod同时也会回收。在删除DaemonSet的时候，会删除他创建的所有Pod。

使用DaemonSet的一些例子：
1.在每个node上运行一个集群存储服务，例如glusterd，ceph（分布式文件系统）；
2.在每个node上运行一个日志收集服务，例如fluentd、logstash；
3.在每个node上运行一个节点监控服务，例如Prometheus Node Exporter。

DaemonSet的描述文件和Deployment非常相似，只需要修改Kind，并去掉副本数量的配置即可：

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.9
        ports:
        - containerPort: 80

查看Pod在Node上的分布：一个node上一个pod

[root@master service-daemonset]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
nginx-daemonset-fl44w   1/1     Running   0          20s   10.244.1.28   node1   <none>           <none>
nginx-daemonset-wgkbv   1/1     Running   0          20s   10.244.2.30   node2   <none>           <none>

删除一个pod，会自动重新创建一个，保持一个node上一个pod：

[root@master service-daemonset]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
nginx-daemonset-fl44w   1/1     Running   0          20s   10.244.1.28   node1   <none>           <none>
nginx-daemonset-wgkbv   1/1     Running   0          20s   10.244.2.30   node2   <none>           <none>
[root@master service-daemonset]# kubectl delete pod nginx-daemonset-fl44w
pod "nginx-daemonset-fl44w" deleted
[root@master service-daemonset]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP            NODE    NOMINATED NODE   READINESS GATES
nginx-daemonset-8q4sn   1/1     Running   0          3s    10.244.1.29   node1   <none>           <none>
nginx-daemonset-wgkbv   1/1     Running   0          10m   10.244.2.30   node2   <none>           <none>

StatefulSets

RC、Deployment、DaemonSet都是面向无状态的服务，它们所管理的Pod的IP、名字，启停顺序等都是随机的。

跟Deployment一样，StatefulSet也用来管理Pod，但不同的是，StatefulSet管理所有有状态的服务。

StatefulSet特点：

Pod一致性：包含次序（启动、停止次序）、网络一致性。此一致性与Pod相关，与被调度到哪个node节点无关；
稳定的次序：对于N个副本的StatefulSet，每个Pod都在[0，N)的范围内分配一个数字序号，且是唯一的；
稳定的网络：Pod的hostname模式为 (statefulset名称)−(序号)；
稳定的存储：通过VolumeClaimTemplate为每个Pod创建一个PV。删除、减少副本，不会删除相关的卷。

StatefulSet本质上是Deployment的一种变体，在v1.9版本中已成为GA版本，它为了解决有状态服务的问题，它所管理的Pod拥有固定的Pod名称，启停顺序，在StatefulSet中，Pod名字称为网络标识(hostname)，还必须要用到持久存储。

使用的场景有：MySQL集群、MongoDB集群、Akka集群、ZooKeeper集群等。

任何可以提供实际请求处理能力的pod最终都要封装成统一的service才能对外提供服务。在Deployment中，与之对应的服务是service，而在StatefulSet中与之对应的headless service，即无头服务，与service的区别就是它没有Cluster IP，解析它的名称时将返回该Headless Service对应的全部Pod的Endpoint列表，即当访问该service时，将直接获得Pod的IP，进行直接访问。

除此之外，StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod副本创建了一个DNS域名，这个域名的格式为：
$(podname).(headless server name)
FQDN（全限定域名）：$(podname).(headless server name).namespace.svc.cluster.local

一个StatefulSet控制器的组成：

Headless Service：用来定义Pod的唯一网络标识( DNS domain)；
volumeClaimTemplates ：存储卷申请模板，创建PVC，指定pvc名称大小，将自动创建pvc，且pvc必须由存储类供应；
StatefulSet ：定义具体应用，比如名为Nginx，有三个Pod副本，并为每个Pod定义了一个域名部署statefulset。

为什么需要 headless service 无头服务？
在用Deployment时，每一个Pod名称是没有顺序的，是随机字符串，因此是Pod名称是无序的，但是在statefulset中要求必须是有序 ，每一个pod不能被随意取代，pod重建后pod名称还是一样的。而pod IP是变化的，所以是以Pod名称来识别。pod名称是pod唯一性的标识符，必须持久稳定有效。这时候要用到无头服务，它可以给每个Pod一个唯一的名称 。

为什么需要volumeClaimTemplate？
对于有状态的副本集都会用到持久存储，对于分布式系统来讲，它的最大特点是数据是不一样的，所以各个节点不能使用同一存储卷，每个节点有自已的专用存储，但是如果在Deployment中的Pod template里定义的存储卷，是所有副本集共用一个存储卷，数据是相同的，因为是基于模板来的 ，而statefulset中每个Pod都要自已的专有存储卷，所以statefulset的存储卷就不能再用Pod模板来创建了，于是statefulSet使用volumeClaimTemplate，称为卷申请模板，它会为每个Pod生成不同的pvc，并绑定pv，从而实现各pod有专用存储。这就是为什么要用volumeClaimTemplate的原因。

部署一个StatefulSet服务：

yaml文件：

#首先需要一个无头service，其中 clusterIP: None
apiVersion: v1
kind: Service
metadata:
  name: nginx-headless
  namespace: default
spec:
  selector:
     run: nginx
  clusterIP: None
  ports:
  - port: 80
    targetPort: 80

---
#StatefulSet控制器，说明3个nginx副本都是有状态服务
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx-statefulset
  namespace: default
spec:
  serviceName: nginx
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx:1.8
        name: nginx
        ports:
        - containerPort: 80

查看pod与svc：

[root@master service-statefulsets]# kubectl get pods
NAME                  READY   STATUS    RESTARTS   AGE
nginx-statefulset-0   1/1     Running   0          7s
nginx-statefulset-1   1/1     Running   0          6s
nginx-statefulset-2   1/1     Running   0          3s
[root@master service-statefulsets]# kubectl get svc
NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes       ClusterIP   10.96.0.1    <none>        443/TCP   37d
nginx-headless   ClusterIP   None         <none>        80/TCP    18s

如果观察pod的创建过程，会发现是有序创建的（如果delete，同样也是有序删除，删除的顺序正好相反，从N-1到0），按照0-1-2的顺序，并且每个 Pod 都拥有一个基于其顺序索引的稳定的主机名。

Pod的hostname由StatefulSet的name以及其ordinal index组成，$(statefulset name)-$(ordinal)。若StatefulSet存在N个pod， ordinal index为0~N-1。示例中创建3个pod,分别名为nginx-statefulset-0，nginx-statefulset-1，nginx-statefulset-2。

如果重启pod会发现，pod中的ip会变化，但是pod的名称不会发生变化；这就是为什么不要在其他应用中使用 StatefulSet 中的 Pod 的 IP 地址进行连接，而应该使用唯一domain进行连接，因为domain是稳定的，这点很重要。

StatefulSet使用headless service来控制pod的domain。Service控制的domain的格式为：$(service name).$(namespace).svc.cluster.local，其中cluster.local为cluster domain。当Pod创建后，获得匹配的DNS subdomain，格式为$(podname).$(governing service domain)，即$(podname).$(service name).$(namespace).svc.cluster.local。如示例中的：nginx-statefulset-0.nginx-headless.default.svc.cluster.local。

另外，StatefulSet一般都会使用VolumeClaimTemplate（本例未使用），比如：

  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

K8s会为每个VolumeClaimTemplate创建一个PersistentVolume，每个pod将获取一个PersistentVolume，其storage class为my-storage-class并具有1GB的存储。当不指定storage class时，将使用默认的storage class。当Pod被schedule到node上时，它的volumeMounts将mount生成的PersistentVolume。

注意：PersistentVolumes在pod或StatefulSet删除后并不会被删除，需要人工删除。

Job

服务类容器通常持续提供服务，需要一直运行，比如 http server，daemon 等；而工作类容器则是一次性任务，比如批处理程序，完成后容器就退出。

Kubernetes 的 Deployment、ReplicaSet 和 DaemonSet 都用于管理服务类容器；对于工作类容器，我们用 Job。

Job创建一个或多个pod并确保指定数量的pod成功终止，当指定数量的pod成功终止后，job结束。

一个Job示例，计算2000位π：

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

restartPolicy ：是指当前的重启策略。对于 Job，只能设置为 Never （从不）或者 OnFailure（失败时）。对于其他 controller（比如 Deployment）可以设置为 Always 。

backoffLimit ：设置pod失败后的重试次数，默认为6

启动这个job并查看：

[root@master service-job]# kubectl apply -f job.yaml 
job.batch/pi created
[root@master service-job]# kubectl get job
NAME   COMPLETIONS   DURATION   AGE
pi     0/1           14s        14s
[root@master service-job]# kubectl get pods
NAME                    READY   STATUS              RESTARTS   AGE
nginx-daemonset-8q4sn   1/1     Running             0          144m
nginx-daemonset-wgkbv   1/1     Running             0          155m
pi-x5m4s                0/1     ContainerCreating   0          21s

过一会，当completions为 1/1 表示成功运行了这个job，同时pod的状态为的Completed表示这个job已经运行完成：

[root@master service-job]# kubectl get job
NAME   COMPLETIONS   DURATION   AGE
pi     1/1           75s        2m57s
[root@master service-job]# kubectl get pods
NAME                    READY   STATUS      RESTARTS   AGE
nginx-daemonset-8q4sn   1/1     Running     0          146m
nginx-daemonset-wgkbv   1/1     Running     0          157m
pi-x5m4s                0/1     Completed   0          3m

此时通过pod日志来查看job的执行结果：kubectl logs pi-x5m4s

[root@master service-job]# kubectl logs pi-x5m4s 
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901

有时也会同时运行多个pod来提高job的执行效率，此时可以通过设置.spec.completions和.spec.parallelism属性来完成不同的任务。

completions表示成功完成的任务数量，parallelism表示并行任务数量，默认都为1.当parallelism设置为0时，job将被暂停。比如：

当Job complete，将不会创建pod，old pod也不会被删除，这样可以查看log。同时，Job也存在，这样可以查看status。可以通过kubectl delete来人工删除。

[root@master service-job]# kubectl delete -f job.yaml 
job.batch "pi" deleted

或者
[root@master service-job]# kubectl delete job pi
job.batch "pi" deleted

Job终止可能因为失败次数超过.spec.backoffLimit，或者因为job的运行时间炒超过设置的.spec.activeDeadlineSeconds。当Job的运行时间超过activeDeadlineSeconds，所有运行的pod被终止，Job状态变为Failed，reason: DeadlineExceeded。

CronJob

Linux 中有 cron 程序定时执行任务，Kubernetes 的 CronJob 提供了类似的功能，可以定时执行 Job，解决了某些批处理任务需要定时反复执行的问题。

一个CronJob示例：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            command: ["echo","hello k8s job!"]
          restartPolicy: OnFailure

schedule 指定什么时候运行 Job，其格式与 Linux cron 一致。这里 */1 * * * * 的含义是每一分钟启动一次。

等待几分钟，然后通过 kubectl get jobs 查看 Job 的执行情况：

[root@master service-cronjob]# kubectl get cronjob
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0        39s             7m32s
[root@master service-cronjob]# kubectl get job
NAME               COMPLETIONS   DURATION   AGE
hello-1619459040   1/1           16s        2m46s
hello-1619459100   1/1           17s        106s
hello-1619459160   1/1           16s        46s

通过AGE发现 每个job都比之前的多了 60s，即每一分钟执行一次job

使用 kubect get pods 和 kubectl logs 命令查看：

[root@master service-cronjob]# kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
hello-1619459100-gxn27   0/1     Completed   0          2m51s
hello-1619459160-f5p8x   0/1     Completed   0          111s
hello-1619459220-f2k76   0/1     Completed   0          51s
[root@master service-cronjob]# kubectl logs hello-1619459100-gxn27
hello k8s job!

参考：

https://www.pianshen.com/article/80111234551/

https://zhuanlan.zhihu.com/p/88202304

StatefulSet：https://blog.csdn.net/weixin_44729138/article/details/106054025

Job：https://www.cnblogs.com/benjamin77/p/9903280.html