Kubernetes核心之——控制器

前言:控制器:又称之为工作负载,分别包含以下类型控制器
1:Deployment
2:StatefulSet
3:DaemonSet
4:Job
5:CronJob

文章目录

  • 一、Pod与控制器之间的关系
  • 二、无状态应用与有状态应用
  • 三、Deployment
    • 1.概述
    • 2.作用
    • 3.示例
  • 四、Satefulset
    • 1.解释
    • 2.注意事项
    • 3.作用
    • 4.无头服务
    • 5.示例
      • 1)创建资源
      • 2)验证dns解析
  • 五、DaemonSet
    • 1.解释
    • 2.作用
    • 3.示例
  • 六、Job
    • 1.解释
    • 2.Job Controller
    • 3.Job Spec格式
    • 4.Bare Pods
    • 5.示例
  • 七、CronJob
    • 1.解释
    • 2.CronJob Spec
    • 3.示例
    • 总结

一、Pod与控制器之间的关系

  • controllers:在集群上管理和运行容器的对象通过label-selector相关联
  • Pod通过控制器实现应用的运维,如伸缩,升级等
    Kubernetes核心之——控制器_第1张图片

二、无状态应用与有状态应用

  • 无状态:任意一个Web请求端提出请求时,请求本身包含了响应端为响应这一请求所需的全部信息(认证信息等)

  • 有状态:Web请求端的请求必须被提交到保存有其相关状态信息(比如session)的服务器上,否则这些请求可能无法被理解,这也就意味着在此模式下服务器端无法对用户请求进行自由调度

  • 再说直白一点就是状态(公共交互)信息是由请求方还是响应方负责保存,请求方保存就是无状态,响应方保存就是有状态

  • 无状态应用不关心响应方是谁,需不需要同步各个响应方之间的信息,响应服务可随时被删除也不会影响别人,容错性高,分布式服务的负载均衡失效不会丢数据,无内存消耗,直接部署上线即可使用

  • 有状态应用需要及时同步数据,可能存在数据同步不玩丢失数据,消耗内存资源保存数据等

  • 简单的说:

    • 无状态
      • 1)deployment 认为所有的pod都是一样的
      • 2)不用考虑顺序的要求
      • 3)不用考虑在哪个node节点上运行
      • 4)可以随意扩容和缩容
    • 有状态
      • 1)实例之间有差别,每个实例都有自己的独特性,元数据不同,例如etcd,zookeeper
      • 2)实例之间不对等的关系,以及依靠外部存储的应用

三、Deployment

  • Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括:
    • 定义Deployment来创建Pod和ReplicaSet
    • 滚动升级和回滚应用
    • 扩容和缩容
    • 暂停和继续Deployment

1.概述

  • Deployment为Pod和Replica Set(下一代Replication Controller)提供声明式更新

  • 你只需要在Deployment中描述你想要的目标状态是什么,Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment,也可以创建一个新的替换旧的Deployment

  • 一个典型的用例如下:

    • 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态,看它是成功还是失败
    • 然后,通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet,Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中
    • 如果当前状态不稳定,回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision
    • 扩容Deployment以满足更高的负载
    • 暂停Deployment来应用PodTemplateSpec的多个修复,然后恢复上线
    • 根据Deployment 的状态判断上线是否hang住了
    • 清除旧的不必要的ReplicaSet

2.作用

  • 部署无状态应用
  • 管理Pod和ReplicaSet
  • 具有上线部署、副本设定、滚动升级、回滚等功能
  • 提供声明式更新,例如只更新一个新的Image

应用场景:web服务

3.示例

  • 创建一个控制器类型为Deployment的资源
[root@master01 demo]# cat nginx-deployment.yaml 
apiVersion: apps/v1
kind: Deployment         类型为deployment控制器
metadata:
  name: nginx-deployment
  labels:
    app: nginx      //标签要一致
spec:
  replicas: 3    //Replicaset 是控制版本,副本数,回滚就是通过此来实现
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
[root@master01 demo]# kubectl create -f nginx-deployment.yaml  //创建
deployment.apps/nginx-deployment created
[root@master01 demo]# kubectl get pods,deploy,rs    //查看pod资源,控制器资源,副本集资源
NAME                                  READY   STATUS    RESTARTS   AGE
pod/nginx-deployment-d55b94fd-2lmwz   1/1     Running   0          29s
pod/nginx-deployment-d55b94fd-9fn5w   1/1     Running   0          29s
pod/nginx-deployment-d55b94fd-wmr5n   1/1     Running   0          29s

NAME                                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/nginx-deployment   3         3         3            3           29s

NAME                                              DESIRED   CURRENT   READY   AGE
replicaset.extensions/nginx-deployment-d55b94fd   3         3         3       29s
  • 使用edit编辑,可以查看控制器
[root@master01 demo]# kubectl edit deployment/nginx-deployment
。。。省略部分内容
spec:
  progressDeadlineSeconds: 600
  replicas: 3            //副本集为3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx
  strategy:                  //滚动更新策略
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.15.4
        imagePullPolicy: IfNotPresent         //镜像拉取策略
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
        resources: {}
。。。省略部分内容
//查看历史版本
[root@master01 demo]# kubectl rollout history deployment/nginx-deployment
deployment.extensions/nginx-deployment 
REVISION  CHANGE-CAUSE
1               //当前版本已保存

四、Satefulset

1.解释

  • StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计),其应用场景包括

    • 稳定的持久化存储,即Pod重新调度后还是能访问到相同的持久化数据,基于PVC来实现
    • 稳定的网络标志,即Pod重新调度后其PodName和HostName不变,基于Headless Service(即没有Cluster IP的Service)来实现
    • 有序部署,有序扩展,即Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态),基于init containers来实现
      有序收缩,有序删除(即从N-1到0)
  • 从上面的应用场景可以发现,StatefulSet由以下几个部分组成:

    • 用于定义网络标志(DNS domain)的Headless Service
    • 用于创建PersistentVolumes的volumeClaimTemplates
    • 定义具体应用的StatefulSet
  • StatefulSet中每个Pod的DNS格式为statefulSetName-{0…N-1}.serviceName.namespace.svc.cluster.local,其中

    • serviceName为Headless Service的名字
    • 0…N-1为Pod所在的序号,从0开始到N-1
    • statefulSetName为StatefulSet的名字
    • namespace为服务所在的namespace,Headless Servic和StatefulSet必须在相同的namespace
    • .cluster.local为Cluster Domain,

2.注意事项

  • 还在beta状态,需要kubernetes v1.5版本以上才支持
  • 所有Pod的Volume必须使用PersistentVolume或者是管理员事先创建好
  • 为了保证数据安全,删除StatefulSet时不会删除Volume
  • StatefulSet需要一个Headless Service来定义DNS domain,需要在StatefulSet之前创建好
  • 目前StatefulSet还没有feature complete,比如更新操作还需要手动patch

3.作用

  • 部署有状态应用
  • 解决Pod独立生命周期,保持Pod启动顺序和唯一性
  • 稳定,唯一的网络标识符,持久存储(例如:etcd配置文件,节点地址发生变化,将无法使用)
  • 有序,优雅的部署和扩展、删除和终止(例如:mysql主从关系,先启动主,再启动从)
  • 有序,滚动更新

应用场景:数据库
官方资源:https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

4.无头服务

  • 常规service和无头服务区别
    • service:一组Pod访问策略,提供cluster-IP群集之间通讯,还提供负载均衡和服务发现
    • Headless service 无头服务,不需要cluster-IP,直接绑定具体的Pod的IP

5.示例

1)创建资源

  • 创建一个service资源
[root@master01 demo]# cat nginx-service.yaml 
apiVersion: v1  
kind: Service  
metadata:
  name: nginx-service
  labels:
    app: nginx  
spec:
  type: NodePort  
  ports:
  - port: 80
    targetPort: 80  
  selector:
    app: nginx
[root@master01 demo]# kubectl create -f nginx-service.yaml   //创建
service/nginx-service created
[root@master01 demo]# kubectl get svc    //查看service
NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.0.0.1             443/TCP        25d
nginx-service   NodePort    10.0.0.98            80:30249/TCP   5s

  • 重启node节点的网络以及docker,验证群集间的通讯
//重启网络以及docker
[root@node1 ~]# systemctl restart flanneld.service 
[root@node1 ~]# systemctl restart docker

//查看群集间通讯
[root@node1 ~]# curl 10.0.0.98



Welcome to nginx!



Welcome to nginx!

If you see this page, the nginx web server is successfully installed and working. Further configuration is required.

For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.

Thank you for using nginx.

//访问有效,说明服务已经提供出来
  • headless方式,因为pod动态ip地址,所有常用于绑定dns访问
[root@master01 ~]# vim headless.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None    //群集地址设置为none,即无头服务
  selector:
    app: nginx
[root@master01 ~]# kubectl apply -f headless.yaml 
service/nginx created
[root@master01 ~]# kubectl get svc
NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.0.0.1             443/TCP        25d
nginx           ClusterIP   None                 80/TCP         13s     //无头服务创建成功,群集地址为None
  • 于是需要用到dns域名服务,这里将准备好的yaml文件创建出来
[root@master01 demo]# ls
coredns.yaml   //dnsyaml文件
[root@master01 demo]# kubectl create -f coredns.yaml   //提供域名解析功能的资源
serviceaccount/coredns created
clusterrole.rbac.authorization.k8s.io/system:coredns created
clusterrolebinding.rbac.authorization.k8s.io/system:coredns created
configmap/coredns created
deployment.extensions/coredns created
service/kube-dns created
[root@master01 demo]# kubectl get pods -n kube-system
NAME                                    READY   STATUS    RESTARTS   AGE
coredns-56684f94d6-crx4j                1/1     Running   0          29s
[root@master01 demo]# vim pod3.yaml   //创建一个dns资源
apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4     //镜像为busybox
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never

[root@master01 demo]# kubectl apply -f pod3.yaml 
pod/dns-test created
[root@master01 demo]# kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
dns-test                          1/1     Running   0          26s
[root@master01 demo]# kubectl get svc 
NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.0.0.1             443/TCP        25d
nginx           ClusterIP   None                 80/TCP         11m
nginx-service   NodePort    10.0.0.98            80:30249/TCP   3h15m
  • 无头服务就是绑定pod的ip而不是clusterIP,clusterIP做的是负载均衡,但是pod的IP是随时会去变的,所以要通过域名访问

2)验证dns解析

  • 进入容器解析kubernetes和nginx-service名称
[root@master01 demo]# kubectl exec -it dns-test sh
/ # nslookup kubernetes
Server:    10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local

/ # nslookup nginx-service
Server:    10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local

Name:      nginx-service
Address 1: 10.0.0.98 nginx-service.default.svc.cluster.local

  • 解析出来的地址就是pod资源的地址
[root@master01 ~]# kubectl get ep
NAME            ENDPOINTS                                      AGE
kubernetes      192.168.170.128:6443,192.168.170.129:6443      25d
nginx-service   172.17.12.2:80,172.17.12.3:80,172.17.86.2:80   170m
  • 创建一个完整的资源用来验证无头服务
[root@master01 demo]# vim sts.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1beta1  
kind: StatefulSet  
metadata:
  name: nginx-statefulset  
  namespace: default
spec:
  serviceName: nginx  
  replicas: 3  
  selector:
    matchLabels:  
       app: nginx
  template:  
    metadata:
      labels:
        app: nginx  
    spec:
      containers:
      - name: nginx
        image: nginx:latest  
        ports:
        - containerPort: 80  

//清理所有的pod后创建
[root@master01 demo]# kubectl create -f sts.yaml 
service/nginx created
statefulset.apps/nginx-statefulset created
[root@master01 demo]# kubectl get pods   //三个资源创建成功用于验证
NAME                  READY   STATUS    RESTARTS   AGE
nginx-statefulset-0   1/1     Running   0          23m
nginx-statefulset-1   1/1     Running   0          23m
nginx-statefulset-2   1/1     Running   0          22m
[root@master01 demo]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.0.0.1             443/TCP   25d
nginx        ClusterIP   None                 80/TCP    24m 
[root@master01 demo]# kubectl apply -f pod3.yaml   //部署一个dns测试的资源
pod/dns-test created
//解析pod的唯一域名和自身的ip
[root@master01 demo]# kubectl exec -it dns-test sh
/ # nslookup nginx-statefulset-0.nginx
Server:    10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local

Name:      nginx-statefulset-0.nginx
Address 1: 172.17.86.4 nginx-statefulset-0.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-1.nginx
Server:    10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local

Name:      nginx-statefulset-1.nginx
Address 1: 172.17.100.3 nginx-statefulset-1.nginx.default.svc.cluster.local
/ # nslookup nginx-statefulset-2.nginx
Server:    10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local

Name:      nginx-statefulset-2.nginx
Address 1: 172.17.86.3 nginx-statefulset-2.nginx.default.svc.cluster.local
//可以看到每个资源解析出来的地址都是pod资源的地址
[root@master01 demo]# kubectl get ep
NAME         ENDPOINTS                                       AGE
kubernetes   192.168.170.128:6443,192.168.170.129:6443       25d
nginx        172.17.100.3:80,172.17.86.3:80,172.17.86.4:80   56m
  • 总结:
    • StatefulSet与Deployment区别:有身份的
    • 身份三要素:
    • 域名 nginx-statefulset-0.nginx
    • 主机名 nginx-statefulset-0
    • 存储(PVC)

五、DaemonSet

1.解释

  • DaemonSet保证在每个Node上都运行一个容器副本,常用来部署一些集群的日志、监控或者其他系统管理应用。典型的应用包括:
    • 日志收集,比如fluentd,logstash等
    • 系统监控,比如Prometheus Node Exporter,collectd,New Relic agent,Ganglia gmond等
    • 系统程序,比如kube-proxy, kube-dns, glusterd, ceph等

2.作用

  • 在每一个Node上运行一个Pod
  • 新加入的Node也同样会自动运行一个Pod

应用场景:Agent
官方资源:https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
官方案例:(监控)
Kubernetes核心之——控制器_第2张图片

3.示例

  • 创建一个控制器类型为DaemonSet的资源
[root@localhost demo]# vim ds.yaml 
apiVersion: apps/v1 
kind: DaemonSet     //控制器类型为DaemonSet
metadata:
  name: nginx-deployment
  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
[root@master01 demo]# kubectl apply -f ds.yaml 
daemonset.apps/nginx-deployment created
[root@master01 demo]# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
nginx-deployment-4qfwv   1/1     Running   0          31s
nginx-deployment-rgvw4   1/1     Running   0          31s
//DaemonSet会在每个node节点都创建一个Pod
  • 这个pod资源并没有指定副本集,却创建出来了两个pod资源,说明DaemonSet的功能:只要是加入到群集的node节点,都会创建一个pod资源

六、Job

1.解释

  • Job负责批量处理短暂的一次性任务 (short lived one-off tasks),即仅执行一次的任务,它保证批处理任务的一个或多个Pod成功结束
  • Kubernetes支持以下几种Job:
    • 非并行Job:通常创建一个Pod直至其成功结束
    • 固定结束次数的Job:设置.spec.completions,创建多个Pod,直到.spec.completions个Pod成功结束
    • 带有工作队列的并行Job:设置.spec.Parallelism但不设置.spec.completions,当所有Pod结束并且至少一个成功时,Job就认为是成功

应用场景:离线数据处理,视频解码等业务
官方资源:https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/
Kubernetes核心之——控制器_第3张图片

  • 根据.spec.completions和.spec.Parallelism的设置,可以将Job划分为以下几种pattern:
    Kubernetes核心之——控制器_第4张图片

2.Job Controller

  • Job Controller负责根据Job Spec创建Pod,并持续监控Pod的状态,直至其成功结束。如果失败,则根据restartPolicy(只支持OnFailure和Never,不支持Always)决定是否创建新的Pod再次重试任务
    Kubernetes核心之——控制器_第5张图片

3.Job Spec格式

  • spec.template格式同Pod
  • RestartPolicy仅支持Never或OnFailure
  • 单个Pod时,默认Pod成功运行后Job即结束
  • .spec.completions标志Job结束需要成功运行的Pod个数,默认为1
  • .spec.parallelism标志并行运行的Pod的个数,默认为1
  • spec.activeDeadlineSeconds标志失败Pod的重试最大时间,超过这个时间不会继续重试

4.Bare Pods

  • 所谓Bare Pods是指直接用PodSpec来创建的Pod(即不在ReplicaSets或者ReplicationCtroller的管理之下的Pods)。这些Pod在Node重启后不会自动重启,但Job则会创建新的Pod继续任务。所以,推荐使用Job来替代Bare Pods,即便是应用只需要一个Pod

5.示例

  • 创建控制器类型为Job的资源
//重试次数默认是6次,修改为4次,当遇到异常时Never状态会重启,所以要设定次数
[root@master01 demo]# vim job.yaml
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
  • 在node节点下载perl镜像,因为镜像比较大所以提前下载好
[root@node1 ~]# docker pull perl
Using default tag: latest
latest: Pulling from library/perl
376057ac6fa1: Pull complete 
5a63a0a859d8: Pull complete 
496548a8c952: Pull complete 
2adae3950d4d: Pull complete 
0ed5a9824906: Pull complete 
24bc7d866f19: Pull complete 
fab10d7383f1: Pull complete 
Digest: sha256:047cbc54c1d8bc602c10fcb27357532be6ee4ee3dd7f438b72e4e60789f7e1bc
Status: Downloaded newer image for perl:latest
docker.io/library/perl:latest
  • 创建资源并查看pod资源
[root@master01 demo]# kubectl apply -f job.yaml 
job.batch/pi created
[root@master01 demo]# kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
pi-g5cs2                 0/1     Completed   0          30s
//状态为comleted说明已经计算完成
  • 将结果输出到控制台
[root@master01 demo]# kubectl logs pi-g5cs2
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901

[root@master01 demo]# kubectl get job
NAME   COMPLETIONS   DURATION   AGE
pi     1/1           21s        1m36s
//清除job资源
[root@master01 demo]# kubectl delete -f job.yaml 
job.batch "pi" deleted

七、CronJob

1.解释

  • CronJob即定时任务,就类似于Linux系统的crontab,在指定的时间周期运行指定的任务。在Kubernetes 1.5,使用CronJob需要开启batch/v2alpha1 API,即–runtime-config=batch/v2alpha1
  • 应用场景:通知,备份

官方资源:https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/
Kubernetes核心之——控制器_第6张图片

2.CronJob Spec

  • .spec.schedule指定任务运行周期,格式同Cron
  • .spec.jobTemplate指定需要运行的任务,格式同Job
  • .spec.startingDeadlineSeconds指定任务开始的截止期限
  • .spec.concurrencyPolicy指定任务的并发策略,支持Allow、Forbid和Replace三个选项

3.示例

  • 创建一个控制器类型为CronJob的资源
[root@master01 demo]# vim 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        //表示只有在异常退出的时候重启容器
[root@master01 demo]# kubectl apply -f cronjob.yaml 
cronjob.batch/hello created
[root@master01 demo]# kubectl get cronjob  //查看设置的计划
NAME    SCHEDULE      SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   */1 * * * *   False     0                  9s

  • 验证
[root@master01 demo]# kubectl get pods   //状态表示已经完成一次计划
NAME                     READY   STATUS      RESTARTS   AGE
hello-1590463740-6tdnw   0/1     Completed   0          24s
[root@master01 demo]# kubectl log hello-1590463740-6tdnw  //查看资源的日志可以验证结果
log is DEPRECATED and will be removed in a future version. Use logs instead.
Tue May 26 03:29:20 UTC 2020
Hello from the Kubernetes cluster

//等待一分钟后又会再执行一次
[root@master01 demo]# kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
hello-1590463740-6tdnw   0/1     Completed   0          94s
hello-1590463800-bxgqn   0/1     Completed   0          34s
//因为设定的每分钟执行一次,所以每过一分钟都会执行一次
[root@master01 demo]# kubectl get pods
NAME                     READY   STATUS      RESTARTS   AGE
hello-1590463800-bxgqn   0/1     Completed   0          2m32s
hello-1590463860-4jjlz   0/1     Completed   0          92s
hello-1590463920-kbv8q   0/1     Completed   0          32s

总结

  • Deployment 无状态化服务,只负责数量
    • 应用场景:web服务
  • StatefulSet 有状态化服务,含有身份标识确保完整独立的生命周期,启动区别也是有序的,通过service区别(无头服务),它不会使用clusterIP,而是PodIP,又因为PodIP是动态的,所以需要域名来访问
    • 应用场景:数据库
  • DaemonSet 有多少个node节点就创建多少个pod
    • 应用场景:Agent
  • Job 一次性执行,执行完毕后资源不再运行
    • 应用场景:离线数据处理,视频解码等业务
  • CronJob 周期性执行
    • 应用场景:通知,备份

你可能感兴趣的:(K8s)