文章目录


引言：
睡觉，不写了

一、基础概念

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

k8s操作pod对象的所有业务逻辑 都是由各种控制器来完成的

k8s的所有控制器都存储在pkg/controller目录下 这个目录下的每个控制器都以自己的方式负责某种编排功能

它们都遵循着一种通用的编排模式 控制循环(control loop)= 调谐循环 = 同步循环

通过在一个无限循环中 比较某个编排对象的两种状态 使对象的实际状态无限的等于对象的期望状态

1.期望状态来源 用户提交的YAML文件 保存在etcd中

2.实际状态来源 集群中的动态信息

二、控制器定义

被控制对象的定义,则来自于一个"模板".比如,Deployment里的template 字段.可以看到,Deployment 这个template字段里的内容,跟一个标准的Pod对象的API定义,丝毫不差.而所有被这个Deployment 管理的Pod实例,其实都是根据这个template字段的内容创建出来的.

像 Deployment 定义的 template 字段,在Kubernetes项目中有一个专有的名字,叫作 PodTemplate(Pod 模板).大多数控制器,都会使用PodTemplate来统一定义它所要管理的Pod.还有其他类型的对象模板,比如Volume 的模板.

在所有API对象的 Metadata里,都有一个字段叫作 ownerReference,用于保存创建当前这个 API(Pod) 对象的拥有者(Owner)的信息
在这里插入图片描述

三、控制循环编排原理

这些控制循环最后的执行结果,要么就是创建,更新一些 Pod(或者其他的API对象,资源),要么就是删除一些已经存在的Pod(或者其他的API对象,资源)

正是在这个统一的编排框架下,不同的控制器可以在具体执行过程中,设计不同的业务逻辑,从而达到不同的编排效果

这个实现思路,正是 Kubernetes 项目进行容器编排的核心原理

"控制器模式"和"事件驱动"的区别

事件往往是一次性的,如果操作失败比较难处理,但是控制器是循环一直在尝试的,更符合kubernetes申明式API,最终达到与申明一致

四、控制器分类

在这里插入图片描述
控制器架构
在这里插入图片描述
先来看看控制器在整个K8S架构中的作用，首先客户端通过API Server把资源信息存储到etcd中，并将变化通知给相关组件；scheduler监听到未绑定的pod对象，于是挑选node进行部署；controller manager是一个单独的守护进程，内部包含众多控制器，如statefuleset、deployment等；每个控制器根据自己的规则监控资源状态，如果不满足目标需求，则进行调控。

在这里插入图片描述

总的说来，控制器相当于一个第三方的管理者，时刻关注每个pod的状态，当不符合自己的预期状态时，自动进行新增或删除pod以达到预期状态。

一般控制器都会包含三个主要部分：标签选择器、期望的副本数量、pod模板，其中模板与正常使用pod的配置无异。

4.1.自主式 Pod

Pod 退出后不会被创建

4.2.控制器管理的 Pod

在控制器的生命周期里，始终要维持 Pod 的副本数目

4.3.控制器类型

Replication Controller和ReplicaSet Deployment DaemonSet StatefulSet Job CronJob HPA全称Horizontal Pod Autoscaler Replication Controller和ReplicaSet ReplicaSet (RS)是下一代的 Replication Controller(RC)，官方推荐使用ReplicaSet。

ReplicaSet 和 Replication Controller 的唯一区别是选择器的支持，ReplicaSet 支持新的基于集合的选择器需求。

ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。

虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制。

4.3.1 Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法。

.典型的应用场景：

用来创建Pod和ReplicaSet 滚动更新和回滚 扩容和缩容 暂停与恢复

4.3.2 DaemonSet

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

DaemonSet 的典型用法：

在每个节点上运行集群存储 DaemonSet，例如 glusterd、ceph。 在每个节点上运行日志收集 DaemonSet，例如 fluentd、logstash。 在每个节点上运行监控 DaemonSet，例如 Prometheus Node Exporter、zabbix agent等 一个简单的用法是在所有的节点上都启动一个 DaemonSet，将被作为每种类型的 daemon 使用。

一个稍微复杂的用法是单独对每种 daemon 类型使用多个 DaemonSet，但具有不同的标志， 并且对不同硬件类型具有不同的内存、CPU 要求。

4.3.3 StatefulSet

StatefulSet 是用来管理有状态应用的工作负载 API 对象。实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，称为“有状态应用”

StatefulSet 用来管理 Deployment 和扩展一组 Pod，并且能为这些 Pod 提供序号和唯一性保证。

StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值：

稳定的、唯一的网络标识符。 稳定的、持久的存储。 有序的、优雅的部署和缩放。 有序的、自动的滚动更新。 Job 执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束。

4.3.4 CronJob

Cron Job 创建基于时间调度的 Jobs。

一个 CronJob 对象就像 crontab (cron table) 文件中的一行，它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。

HPA 根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放。

五、pod控制器使用示例

5.1 ReplicaSet举例

在这里插入图片描述
k8s早期版本使用ReplicationController简称RC，后来替换成ReplicaSet，主要增加了基于集合的标签选择器以及滚动更新的机制，其他的功能基本与RC一致。那么就着重介绍下ReplicaSet，简称RS：它主要用来管控pod对象的副本数在任一时刻都满足期望的数量。相比于手动管理pod，RS支持精确的控制pod数量，确保pod健康运行，弹性伸缩等特性，还可以通过HPA 来针对资源动态伸缩。

一般在实践中不会直接使用RS，而是通过更高层次的控制器基于RS来管理pod。

5.1.1 编辑以下的yaml文件：

[root@k8s-master k8s]# vim rs.yaml
[root@k8s-master k8s]# cat rs.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: replicaset-example
spec:
  replicas: 2           #启动pod的副本数
  selector:             #定义选择器为标签选择器。
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx              #定义容器的标签
    spec:                       #定义容器
      containers:
      - name: nginx
        image: nginx

5.1.2 运行

以上使用的控制器的RS，RS控制器通过pod的标签（matchLabels）来控制pod的数量，使用apply命令可以实现创建，更新pod，而create命令创建后若需要更新只能删除之后再创建，因此建议使用apply：

[root@node16 k8s]# kubectl apply -f rs.yaml 
replicaset.apps/replicaset-example created
[root@node16 k8s]# kubectl apply -f rs.yaml 
replicaset.apps/replicaset-example unchanged

5.1.3 查看状态

查看状态：

[root@server1 ~]# kubectl get pod
NAME                       				READY   		STATUS    	RESTARTS   	AGE
replicaset-example-p6sv6   	1/1     			Running   	0          			34s
replicaset-example-s5jps   		1/1     			Running   	0          			34s
[root@server1 ~]# kubectl get rs            #获取rs的信息
NAME                 				DESIRED   	CURRENT   READY   	AGE
replicaset-example  		 2         		2        			 2       			36s
[root@server1 ~]# kubectl get pod -o wide
NAME                                    READY   STATUS        RESTARTS    AGE   IP            	NODE      	NOMINATED NODE   	READINESS GATES
replicaset-example-p6sv6     1/1           Running        0                     38s   10.244.1.14   server2  		 <none>          			 		<none>
replicaset-example-s5jps      1/1           Running        0                     38s   10.244.2.21   server3  		 <none>          				  	<none>

可以看出一且正常，接下来进行pod的拉伸与压缩：

5.1.4 拉伸副本数：

[root@server1 ~]# vim rs.yaml 
[root@server1 ~]# cat rs.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: replicaset-example
spec:
  replicas: 4       #拉伸为4个
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

[root@server1 ~]# kubectl apply -f rs.yaml 
replicaset.apps/replicaset-example configured

5.1.5 查看pod数：

[root@server1 ~]# kubectl get pod
NAME                      				 READY   	STATUS    	RESTARTS   	AGE
replicaset-example-p6sv6   	1/1     			Running   	0          			97s
replicaset-example-s5jps   		1/1    			Running  	 	0          			97s
replicaset-example-wzclz   		1/1     			Running   	0          			21s
replicaset-example-zk4mb   	1/1     			Running   	0          			21s

已经被拉伸成了4个。

5.1.6 缩减：

[root@server1 ~]# vim rs.yaml 
[root@server1 ~]# cat rs.yaml 
apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: replicaset-example
spec:
  replicas: 2           #缩减为2个
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

[root@server1 ~]# kubectl apply -f rs.yaml 
replicaset.apps/replicaset-example configured
[root@server1 ~]# kubectl get pod
NAME                       				READY   	STATUS        	RESTARTS   	AGE
replicaset-example-p6sv6   	1/1     		Running       	0          			2m6s
replicaset-example-s5jps   		1/1     		Running       	0          			2m6s

可以看出删除的是刚刚创建的那两个pod。

5.1.7 更改一个pod的标签

[root@server1 ~]# kubectl label pod replicaset-example-s5jps app=myapp --overwrite      #将标签强制更改为myapp
pod/replicaset-example-s5jps labeled
[root@server1 ~]# kubectl get pod --show-labels
NAME                       				READY   	STATUS    	RESTARTS   	AGE     		LABELS
replicaset-example-p6sv6   	1/1     		Running   	0          			3m56s   		app=nginx
replicaset-example-s5jps   		1/1     		Running   	0          			3m56s   		app=myapp
replicaset-example-w98nk   	1/1     		Running   	0          			26s     			app=nginx

可以看出现在有3个pod，两个标签为nginx一个为myapp，RS控制器的工作原理就是维持标签为nginx的pod个数有2个，因此当我们更改一个pod的标签后，RS又会给我们创建一个标签为nginx的pod，而当我们将标签为myapp的pod删除后RS控制器不会有操作：

[root@server1 ~]# kubectl delete pod replicaset-example-s5jps
pod "replicaset-example-s5jps" deleted
[root@server1 ~]# kubectl get pod --show-labels
NAME                       				READY   	STATUS    	RESTARTS   	AGE    	LABELS
replicaset-example-p6sv6  		1/1     		Running   	0          			5m8s   	app=nginx
replicaset-example-w98nk   	1/1     		Running   	0          			98s    		app=nginx

5.1.8 再更改验证

[root@server1 ~]# kubectl label pod replicaset-example-p6sv6 app=myapp --overwrite      #首先保证3个pod
pod/replicaset-example-p6sv6 labeled
[root@server1 ~]# kubectl get pod --show-labels
NAME                       				READY   		STATUS    	RESTARTS   	AGE     	LABELS
replicaset-example-p6sv6   	1/1     			Running   	0          			6m4s    	app=myapp
replicaset-example-w98nk   	1/1     			Running   	0          			2m34s   	app=nginx
replicaset-example-x2lq9   		1/1     			Running   	0          			26s     		app=nginx

[root@server1 ~]# kubectl label pod replicaset-example-p6sv6 app=nginx --overwrite
pod/replicaset-example-p6sv6 labeled
[root@server1 ~]# kubectl get pod --show-labels
NAME                       				READY   		STATUS        	RESTARTS   	AGE     	LABELS
replicaset-example-p6sv6   	1/1     			Running       	0          			6m23s   	app=nginx
replicaset-example-w98nk   	1/1     			Running       	0          			2m53s   	app=nginx
replicaset-example-x2lq9   		0/1     			Terminating   	0          			45s     		app=nginx
[root@server1 ~]# kubectl get pod --show-labels
NAME                       				READY   		STATUS    	RESTARTS   	AGE     		LABELS
replicaset-example-p6sv6   	1/1     			Running   	0          			6m25s   		app=nginx
replicaset-example-w98nk   	1/1     			Running   	0          			2m55s   		app=nginx

以上实验可以看出，当集群里有3个标签是nginx的pod的时候，RS控制器又会帮我们将最后创建的pod删除。

实验后删除：

[root@server1 ~]# kubectl delete -f rs.yaml 
replicaset.apps "replicaset-example" deleted

5.2 Deployment控制器示例

5.2.1 编辑yaml文件

Deployment控制器示例 编辑yaml文件：

[root@server1 ~]# vim deployment.yaml 
[root@server1 ~]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: ikubernetes/myapp:v1
        ports:
        - containerPort: 80

5.2.2 创建pod

[root@server1 ~]# kubectl apply -f deployment.yaml 
deployment.apps/deployment-nginx created
[root@server1 ~]# kubectl get pod
NAME                                							READY   		STATUS    	RESTARTS   	AGE
deployment-nginx-56d786cd98-kx5pw   	1/1     			Running   	0          			23s
deployment-nginx-56d786cd98-qgcjl   		1/1     			Running   	0          			23s

[root@server1 ~]# kubectl get rs
NAME                          					DESIRED   		CURRENT   	READY   		AGE
deployment-nginx-56d786cd98   	2         				2         				2       			28s
[root@server1 ~]# kubectl get deployments.apps      #查看deployments
NAME               			READY   UP-TO-DATE   	AVAILABLE   	AGE
deployment-nginx   		2/2     		2            				2           			32s

以上运行结果可以看出deployments底层也是由RS实现的，接下来

5.2.3 进行拉伸

[root@server1 ~]# vim deployment.yaml 
[root@server1 ~]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
  labels:
    app: nginx
spec:
  replicas: 4           #拉伸为4个
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: ikubernetes/myapp:v1
        ports:
        - containerPort: 80
[root@server1 ~]# kubectl apply -f deployment.yaml 
deployment.apps/deployment-nginx configured
[root@server1 ~]# kubectl get pod
NAME                                							READY   	STATUS    	RESTARTS   	AGE
deployment-nginx-56d786cd98-942dh   	1/1     		Running   	0          			26s
deployment-nginx-56d786cd98-kx5pw   	1/1     		Running   	0          			108s
deployment-nginx-56d786cd98-qgcjl   		1/1     		Running   	0          			108s
deployment-nginx-56d786cd98-zb8s8   		1/1     		Running   	0          			26s

可以看出已经拉伸为4个。接下来进行

5.2.4 滚动更新：

[root@server1 ~]# vim deployment.yaml 
[root@server1 ~]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: ikubernetes/myapp:v2     #更新到v2
        ports:
        - containerPort: 80
[root@server1 ~]# kubectl apply -f deployment.yaml 
deployment.apps/deployment-nginx configured
[root@server1 ~]# kubectl get pod -o wide
NAME                                					   READY   STATUS    RESTARTS   AGE     IP            NODE      NOMINATED NODE   READINESS GATES
deployment-nginx-868855d887-2zh45   1/1          Running    0                    2m39s   10.244.2.26   server3     <none>           <none>
deployment-nginx-868855d887-87m22   1/1         Running    0                    2m34s   10.244.1.20   server2     <none>           <none>
deployment-nginx-868855d887-hb6mv   1/1         Running    0                    2m39s   10.244.1.19   server2     <none>           <none>
deployment-nginx-868855d887-v8ndt   	1/1         Running     0                    2m33s   10.244.2.27   server3     <none>           <none>
[root@server1 ~]# curl 10.244.2.26
Hello MyApp | Version: v2 | Pod Name

可以看出更新时控制器新建一个rs，然后再新建4个pod，原来的rs依然存在，为了方便我们

5.2.5 进行回滚：

[root@server1 ~]# vim deployment.yaml 
[root@server1 ~]# cat deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-nginx
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: ikubernetes/myapp:v1
        ports:
        - containerPort: 80
[root@server1 ~]# kubectl apply -f deployment.yaml 
deployment.apps/deployment-nginx configured
[root@server1 ~]# kubectl get pod
NAME                                							READY   	STATUS              		RESTARTS   	AGE
deployment-nginx-56d786cd98-78m7z   	0/1     		ContainerCreating   	0          			4s
deployment-nginx-56d786cd98-8hnns   		1/1     		Running             			0          			9s
deployment-nginx-56d786cd98-lcvzw   		1/1     		Running             			0          			9s
deployment-nginx-56d786cd98-xkjhq   		0/1     		ContainerCreating   	0          			3s
deployment-nginx-868855d887-2zh45   	1/1     		Running             			0          			3m22s
deployment-nginx-868855d887-hb6mv   	1/1     		Terminating         		0          			3m22s
deployment-nginx-868855d887-v8ndt   		1/1     		Terminating         		0          			3m16s

[root@server1 ~]# kubectl get pod
NAME                                							READY   		STATUS    	RESTARTS   	AGE
deployment-nginx-56d786cd98-78m7z   	1/1     			Running   	0          			26s
deployment-nginx-56d786cd98-8hnns   		1/1     			Running   	0          			31s
deployment-nginx-56d786cd98-lcvzw   		1/1     			Running   	0          			31s
deployment-nginx-56d786cd98-xkjhq   		1/1    			Running   	0          			25s

可以看出原来v1版本的rs被重新启用，再原来的rs下面新建4个pod。当然我门也可以使用kubectl delete rs --all命令删除不用的rs（注意：正在使用的rs不会删除）：

[root@server1 ~]# kubectl delete rs --all
replicaset.apps "deployment-nginx-56d786cd98" deleted
replicaset.apps "deployment-nginx-868855d887" deleted
[root@server1 ~]# kubectl get pod
NAME                                							READY   	STATUS    	RESTARTS   	AGE
deployment-nginx-56d786cd98-6r589   		1/1     		Running   	0          			21s
deployment-nginx-56d786cd98-hvz24   		1/1     		Running   	0          			21s
deployment-nginx-56d786cd98-k62lj   		1/1     		Running   	0          			21s
deployment-nginx-56d786cd98-ss97z   		1/1     		Running   	0          			21s
[root@server1 ~]# kubectl get rs
NAME                          					DESIRED   	CURRENT   	READY   	AGE
deployment-nginx-56d786cd98   	4         			4         				4       		24s       #正在使用的RS不会删除

实验后删除：

[root@server1 ~]# kubectl delete -f deployment.yaml 
deployment.apps "deployment-nginx" deleted

5.3 DaemonSet举例

5.3.1 编辑yaml

DaemonSet控制器保证每个节点上都运行一个pod：

[root@server1 ~]# vim daemonset.yaml 
[root@server1 ~]# cat daemonset.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: daemonset-example
  labels:
    app: zabbix-agent
spec:
  selector:
    matchLabels:
      name: zabbix-agent
  template:
    metadata:
      labels:
        name: zabbix-agent
    spec:
      containers:
      - name: zabbix-agent
        image: zabbix/zabbix-agent

5.3.2 创建pod

[root@server1 ~]# kubectl delete pod daemonset-example-ctbgh
pod "daemonset-example-ctbgh" deleted
[root@server1 ~]# kubectl get pod -o wide
NAME                      READY   STATUS              RESTARTS   AGE     IP            NODE      NOMINATED NODE   READINESS GATES
daemonset-example-998ck   0/1     ContainerCreating   0          8s      <none>        server3   <none>           <none>
daemonset-example-mdqzk   1/1     Running             0          8m22s   10.244.1.25   server2   <none>           <none>
[root@server1 ~]# kubectl get pod -o wide
NAME                      READY   STATUS    RESTARTS   AGE     IP            NODE      NOMINATED NODE   READINESS GATES
daemonset-example-998ck   1/1     Running   0          24s     10.244.2.33   server3   <none>           <none>
daemonset-example-mdqzk   1/1     Running   0          8m38s   10.244.1.25   server2   <none>           <none>

可以看出删除后DaemonSet控制器又会帮我们创建pod，以保证每个节点运行一个pod。

实验后删除：

[root@server1 ~]# kubectl delete -f daemonset.yaml 
daemonset.apps "daemonset-example" deleted

5.4 job 控制器举例

5.4.1 编辑yaml

Job控制器只运行一次

[root@server1 ~]# vim job.yaml 
[root@server1 ~]# cat job.yaml 
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl             #利用perl计算圆周率
        command: ["perl",  "-Mbignum=bpi", "-wle", "print      bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4           #容器启动失败重启4次之后不再重启。

5.4.2 创建

kubectl apply -f job.yaml

由于Job只运行一次，因此运行完后状态为Completed，我们可以查看日志获取结果：

可以看出计算成功。

实验后删除：

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

5.5 CronJob 控制器举例

CronJob控制器用于定时执行任务：

[root@server1 ~]# vim cronjob.yaml 
[root@server1 ~]# cat cronjob.yaml 
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-example
spec:
  schedule: "* * * * "
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cronjob
            image: busybox
            args:
             - /bin/sh
             - -c
             - date; echo Hello from k8s cluster #输出信息
          restartPolicy: OnFailure

Crontab

其中schedule字段与crontab里面的写法相同，" * * "表示每分钟执行任务。

5.5.1 创建pod：

[root@server1 ~]# kubectl apply -f cronjob.yaml 
cronjob.batch/cronjob-example created
root@server1 ~]# kubectl get pod
NAME                               						READY   		STATUS              		RESTARTS   	AGE
cronjob-example-1587387120-ngt6n   	0/1     			ContainerCreating   	0          			16s
[root@server1 ~]# kubectl get pod       #等待一分钟
NAME                               						READY   	STATUS              	RESTARTS   	AGE
cronjob-example-1587387120-ngt6n   	0/1     		Completed          		0          			60s
cronjob-example-1587387180-hbwzb   	0/1     		ContainerCreating   0          			9s

可以看出每分钟运行一个pod，查看日志获取输出信息：

[root@server1 ~]# kubectl logs cronjob-example-1587387120-ngt6n
Mon Apr 20 12:52:30 UTC 2022
Hello from k8s cluster
[root@server1 ~]# kubectl logs cronjob-example-1587387180-hbwzb
Mon Apr 20 12:53:35 UTC 2022
Hello from k8s cluster

可以看出输出也是每分钟输出一次，也可以使用以下命令查看cronjob的信息：

[root@server1 ~]# kubectl get cronjobs
NAME              		SCHEDULE    	SUSPEND   	ACTIVE   	LAST SCHEDULE   	AGE
cronjob-example   	* * * * *   				False     			1        			16s             					3m10s

[root@server1 ~]# kubectl get job -w        #查看job信息并且持续输出
NAME                         						COMPLETIONS  	 	DURATION   	AGE
cronjob-example-1587387120   		1/1           					20s        			2m23s
cronjob-example-1587387180   		1/1           					35s        			92s
cronjob-example-1587387240   		1/1           					20s        			32s

实验后删除

[root@server1 ~]# kubectl delete -f cronjob.yaml 
cronjob.batch "cronjob-example" deleted
总结：

控制器是个好东西，要学会选择适合的控制器，以达到生产需求

# kubernetes # java # docker
Logo
K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 |  韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号​前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。​长夜有穷，真水无香。领略过了 K8s“身在江

avatar K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub

avatar K8S/Kubernetes

k8s 火了！

2020，上云之年，产品云端化成为一种趋势。在一线城市，很多公司都已经构建了自己的私有云环境，比如阿里云、网易云、华为云等。而Kubernetes 作为基于容器编排领域的王者，具备扩展...

avatar K8S/Kubernetes