标签:mamicode 否则 系统管 stash iso col 就是 sys 日志
本篇已加入《.NET Core on K8S学习实践系列文章索引》,可以点击查看更多容器化技术相关系列文章。
上一篇《3-1 Deployment》中介绍了Deployment,它可以满足我们大部分时候的应用部署(无状态服务类容器),但是针对一些特殊的场景应用,就可以用到今天介绍的DaemonSet和Job。
Deployment的部署可以指定副本Pod分布在多个Node节点上,且每个Node都可以运行多个Pod副本。而DaemonSet呢,它倔强地保证在每个Node上都只运行一个Pod副本。
回想一下项目经历,有哪些场景满足这个特质呢?是不是一些集群的日志、监控或者其他系统管理应用?
Prometheus Node Exporter Dashboard
在K8S中,就有一些默认的使用DaemonSet方式运行的系统组件,比如我们可以通过下面一句命令查看:
kubectl get daemonset --namespace=kube-system
可以看到,kube-flannel-ds 和 kube-proxy 是K8S以DaemonSet方式运行的系统组件,分别为K8S集群负责提供网络连接支持和代理支持,这里不深入讨论它们的详细情况,只需要了解它们负责什么就可以了。在通过查看Pod副本,看看各个节点的分布情况:
kubectl get pod --namespace=kube-system -o wide
可以看到,它们两分布在各个Node节点上(这里是我的K8S集群中的所有节点了),且每个节点上只有一个Pod副本。
同之前的创建资源方式一样,仍然采用通过YAML配置文件的方式进行创建,只需要指定kind: DaemonSet即可:
apiVersion: apps/v1
kind: DaemonSet
这里我们以Prometheus Node Exporter为例演示一下如何运行我们自己的DaemonSet。
PS:Prometheus是流行的系统监控方案,而Node Exporter负责收集节点上的metrics监控数据,并将数据推送给Prometheus。Prometheus则负责存储这些数据,Grafana最终将这些数据通过网页以图形的形式展现给用户。
下面是yaml配置文件对于DaemonSet资源清单的定义:
apiVersion: apps/v1 kind: DaemonSet metadata: name: node-exporter-daemonset namespace: agent spec: selector: matchLabels: app: prometheus template: metadata: labels: app: prometheus spec: hostNetwork: true containers: - name: node-exporter image: prom/node-exporter imagePullPolicy: IfNotPresent command: - /bin/node_exporter - --path.procfs - /host/proc - --path.sysfs - /host/sys - --collector.filesystem.ignored-mount-points - ^/(sys|proc|dev|host|etc)($|/) volumeMounts: - name: proc mountPath: /host/proc - name: sys mountPath: /host/sys - name: root mountPath: /rootfs volumes: - name: proc hostPath: path: /proc - name: sys hostPath: path: /sys - name: root hostPath: path: /
这里暂且不纠结其中的配置内容,包括Host网络、容器启动命令以及Volume,后面会专题介绍。
同样,通过kubectl创建资源:
kubectl apply -f node-exporter.yaml
然后,通过kubectl查看Pod分布情况:
可以看出,我们的Prometheus Node Exporter部署成功,且分别在两个Node节点都只部署了一个Pod副本。
对于ReplicaSet、Deployment、DaemonSet等类型的控制器而言,它希望Pod保持预期数目并且持久运行下去,除非用户明确删除,否则这些对象一直存在,因此可以说他们说持久服务型任务的。
对于非耐久性任务,比如压缩文件,任务完成后,Pod需要结束运行,不需要Ppod继续保持在系统中,这个时候就要用到Job。因此也可以说,Job是对ReplicaSet、Deployment、DaemonSet等持久性控制器的补充。
同之前的创建资源方式一样,仍然采用通过YAML配置文件的方式进行创建,需要指定apiVersioin: batch 以及 kind: Job即可:
apiVersion: batch/v1
kind: Job
(1)第一个Job
这里我们以一个简单的小Job为例,看看一个简单的Job:当Job启动后,只运行一个Pod,Pod运行结束后整个Job也就立刻结束。
apiVersion: batch/v1 kind: Job metadata: name: edc-job-hello-job namespace: jobs spec: template: metadata: labels: app: edc-job-hello-job spec: containers: - name: hello-job image: busybox imagePullPolicy: IfNotPresent command: ["echo", "hello edison‘s k8s job!"] restartPolicy: Never
这里需要注意的是,对Job而言,其restartPolicy只能为Never或者OnFailure,这也是它与其他控制器的差别(如Deployment控制器还允许设置为Always)。这个Job要执行的任务也很简单,就是输出一段话“hello edison‘s k8s job!”就结束其生命了。
PS:这里用到了一个busybox的镜像,busybox是一个软件工具箱,里边集成了Linux中几百个常用的Linux命令以及工具。如果我们只需要一个小型的Linux运行环境跑命令,完全可以使用这个busybox镜像,而不用拉取一个CentOS镜像。
通过查看Job运行情况可以知道,其运行结束就结束了,如下图所示,变成了Completed状态。
kubectl get pod -n jobs
还可以通过查看Log看看这个Job留下的足迹:
kubectl get pod -n jobs --show-all
kubectl logs edc-job-hello-job-whcts
(2)并行Job
如果希望能够同时并行运行多个Pod以提高Job的执行效率,Job提供了一个贴心的配置:parallesim。例如下面的配置,我们将上面的小Job改为并行运行的Pod数量设置为3。
apiVersion: batch/v1 kind: Job metadata: name: edc-job-hello-job namespace: jobs spec: parallelism: 3 template: metadata: labels: app: edc-job-hello-job spec: containers: - name: hello-job image: busybox imagePullPolicy: IfNotPresent command: ["echo", "hello edison‘s k8s job!"] restartPolicy: OnFailure
PS:默认parallelism值为1
使用上面的配置文件创建了资源后,通过以下命令查看验证:
kubectl get job -n jobs
kubectl get pod -o wide -n jobs
可以看出,Job一共启动了3个Pod,都是同时结束的(可以看到三个Pod的AGE都是相同的)。
此外,Job还提供了一个completions属性使我们可以设置Job完成的Pod总数,还是上面的例子:
apiVersion: batch/v1 kind: Job metadata: name: edc-job-hello-job namespace: jobs spec: parallelism: 3 completions: 6 template: metadata: labels: app: edc-job-hello-job spec: containers: - name: hello-job image: busybox imagePullPolicy: IfNotPresent command: ["echo", "hello edison‘s k8s job!"] restartPolicy: OnFailure
PS:默认completions也为1
上面的配置意思就是:每次运行3个Pod,直到总共有6个Pod就算成功完成。同样通过命令验证一下:
可以看到,状态和AGE都符合预期,第一批3个Pod的AGE为12s,第二批3个Pod的AGE为14s。
我们都知道在Linux中,Cron程序可以定时执行任务,而在K8S中也提供了一个CronJob帮助我们实现定时任务。
继续以上面的例子,我们增加一些配置:
apiVersion: batch/v1beta1 kind: CronJob metadata: name: edc-cron-job namespace: jobs spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: cron-job image: busybox imagePullPolicy: IfNotPresent command: ["echo", "hello edison‘s k8s cron job!"] restartPolicy: OnFailure
上面加粗的配置是CronJob的独有配置,需要注意的是schedule,它的格式和Linux Cron一样,这里的"*/1 * * * *"代表每一分钟启动执行一次。对于CronJob,它需要的是jobTemplate来定义Job的模板。
同样,隔几分钟之后,通过命令来验证一下:
可以看到,在过去的三分钟里,每一分钟都启动了一个Pod,符合预期。
Deployment可以满足我们大部分时候的应用部署(无状态服务类容器),但是针对一些特殊的场景应用,Deployment就无法胜任了。比如日志收集、系统监控等场景,就可以使用今天介绍的DaemonSet。又比如批处理定时任务,则可以使用今天介绍的Job/CronJob。
(1)CloudMan,《每天5分钟玩转Kubernetes》
(2)李振良,《一天入门Kubernets教程》
(3)马哥(马永亮),《Kubernetes快速入门》
(4)阿龙,《Kubernetes系列-07.Pod控制器详解》
(5)elvis,《K8S-Job与CronJob的使用》
(6)五星上炕,《Kubernetes之Job详解》
ASP.NET Core on K8S深入学习(3-2)DaemonSet与Job
标签:mamicode 否则 系统管 stash iso col 就是 sys 日志
原文地址:https://www.cnblogs.com/edisonchou/p/aspnet_core_on_k8s_deepstudy_part3_2.html