guan000 2019-12-29
我们为什么要使用label呢?
当相同类型的资源对象越来越多,为了更好的管理,才按照标签分为一个小组,为的是提升资源的管理效率。
lable是附着到object上(例如pod)的键值对。可以在创建object的时候指定,也可以在object创建后随时指定。Labels的值对系统本身并没有什么含义,只是对用户才有意义。
"labels": { "key1" : "value1", "key2" : "value2" }
语法和字符集
Label key的组成: * 不得超过63个字符 * 可以使用前缀,使用/分隔,前缀必须是DNS子域,不得超过253个字符,系统中的自动化组件创建的label必须指定前缀,kubernetes.io/ 由kubernetes保留。 * 起始必须是字母(大小写都可以)或数字,中间可以有连字符,下划线和点。
Label value的组成: 不得超过63个字符 起始必须是字母(大小写都可以)或数字,中间可以有连字符,下划线和点。
常用的,多维度标签分类:
版本标签(release): stable(稳定版),canary(金丝雀版本),beta(测试版) 环境类(environment): dev(开发),qa(测试),production(生产),op(运维) 应用类(applaction): ui(设计),as(应用软件),pc(电脑端),sc(网络方面) 架构层(tier): frontend(前端),backend(后端),cache(缓存) 分区标签(partition): customerA(客户),customerB 品控级别(track): daily(每天),weekly(每周)
通过以下例子来实践label:
[ yaml]# vim label-pod.yaml apiVersion: v1 kind: Pod metadata: name: label-pod labels: #使用labels字段来定义标签,可以一次定义多个标签,这里定义3个标签 release: stable #版本:稳定版 env: qa #环境:测试 tier: frontend #架构类:前端 spec: containers: - name: testapp image: nginx #部署的是nginx服务 --- kind: Service #关联一个service资源对象 apiVersion: v1 metadata: name: nginx-svc spec: type: NodePort selector: #使用标签选择器 release: stable #只需定义selector字段中的一个标签,字段下的其他标签可全部实现关联。 ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 32134
[ yaml]# kubectl apply -f label-pod.yaml pod/label-pod created service/nginx-svc unchanged
//查看所有pod,并且显示标签key:value: [ yaml]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS label-pod 1/1 Running 0 30m env=qa,release=stable,tier=frontend
//查看指定pod的key:value:
[ yaml]# kubectl get pod label-pod --show-labels NAME READY STATUS RESTARTS AGE LABELS label-pod 1/1 Running 0 40m app=as,env=qa,release=stable,tier=frontend
//只显示标签的value:
[ yaml]# kubectl get pod label-pod -L env,release,tier NAME READY STATUS RESTARTS AGE ENV RELEASE TIER label-pod 1/1 Running 0 41m qa stable frontend
label的其他操作(命令行):添加,修改,删除标签
//通过命令行的方式添加标签:
[ yaml]# kubectl label pod label-pod app=sc pod/label-pod labeled [ yaml]# kubectl get pod -L app NAME READY STATUS RESTARTS AGE APP label-pod 1/1 Running 0 36m sc
//修改标签:
[ yaml]# kubectl label pod label-pod app=as error: ‘app‘ already has a value (sc), and --overwrite is false [ yaml]# kubectl label pod label-pod app=as --overwrite pod/label-pod labeled
可以看到想要修改标签,必须加上--overwrite选项进行重写。
//删除标签:
[ yaml]# kubectl label pod label-pod app- pod/label-pod labeled [ yaml]# kubectl get pod -L app NAME READY STATUS RESTARTS AGE APP label-pod 1/1 Running 0 43m #可以看到该标签以被删除
//我们测试nginx服务是否能够正常运行:
标签选择器:标签的查询过滤条件。
Label不是唯一的,很多object可能有相同的label,通过label selector,客户端/用户可以指定一个object集合,通过label selector对object的集合进行操作
目前kubernetes API支持两种标签选择器:
1)基于等值的关系(matchLables): “=”,“==”,“!=” 2)基于集合的(matchExpressions):in(在这个集合中),notin(不在这个集合中),exists(要么存在,要么不存在)
使用标签选择器的操作逻辑:
1)同时指定的多个选择器之间的逻辑关系为“与”操作
2)使用空值的标签选择器,意味着每个资源对象都将被选择。
3)空的标签选择器将无法选出任何资源。
4)在基于集合的选择器中,使用“in”或者“Notin”操作时,其values不强制为非空字符串列表,而使用exists或DostNoteExists,其values值必须为空。
举例:
selector的操作语法如下:
[ yaml]# vim selector.yaml selector: matchLabels: #基于等值关系的 app: nginx matchExpressions: #基于集合的 - {key: name,operator: In,values: [zhangsan,lisi]} #key,operator,values这三个是固定参数 - {key: age,operator: Exists,values:} #如果指定了Exists,其values值必须为空。
1)什么是Daemonset?
Daemonset 确保集群中的每个node上运行一个pod,且只能运行一个pod。当有node加入集群时,也会为它们新增一个pod。当有node从集群移除时,这些pod也会 被回收。当删除Daemonset时将会删除它创建的所有pod。
2)编写Daemonset需要注意的点:
Daemonset不支持replicas字段,除此之外,与Deployment,RS等资源的写法相同。
3)Daemonset一般的使用场景:
实践Daemonset:
[ yaml]# vim daemonset.yaml kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: nginx-ds spec: template: metadata: labels: app: qa env: dev spec: containers: - name: nginx image: nginx --- kind: Service apiVersion: v1 metadata: name: nginx-dsvc spec: type: NodePort selector: app: qa ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30003
[ yaml]# kubectl apply -f daemonset.yaml daemonset.extensions/nginx-ds created service/nginx-dsvc created
//查看pod的分布情况:
[ yaml]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx-ds-dh429 1/1 Running 0 76s 10.244.2.2 node02 <none> <none> nginx-ds-xz4d8 1/1 Running 0 76s 10.244.1.3 node01 <none> <none>
我集群中只有2个节点,可以看到通过Daemonset实现了每个node上都运行一个pod副本。
与之前的服务类容器不同,之前的资源对象是持续提供服务。job负责批量处理短暂的一次性任务,即仅执行一次的任务,它保证批量处理任务的一个或多个pod成功结束。
1,kubernetes支持以下几种job:
* 非并行job:通常创建一个pod直至其成功结束。 * 固定结束次数的job:设置spec.completions,创建多个pod,直到.spec.completions个pod成功结束。 * 带有工作队列的并行job:设置.spec.Parallelism但不设置.spec.completions,当所有pod结束并且至少一个成功时,job就认为是成功。
2,Job Controller
Job Controller负责根据Job Spec创建pod,并持续监控pod的状态,直至其成功结束,如果失败,则根据restartPolicy(只支持OnFailure和Never,不支持Always)决定是否创建新的pod再次重试任务。
通过以下例子来实践Job:
//创建一个job资源对象:
kind: Job apiVersion: batch/v1 metadata: name: test-job spec: template: metadata: labels: app: job spec: containers: - name: job image: busybox command: ["echo","hello job!"] restartPolicy: Never
[ yaml]# kubectl apply -f job.yaml job.batch/test-job created
如果在生产环境中忘记了字段用法,可以通过kubectl explain 命令工具来提供帮助。
//查看该pod资源对象的状态: [ yaml]# kubectl get pod test-job-dcv6g NAME READY STATUS RESTARTS AGE test-job-dcv6g 0/1 Completed 0 2m8s
我们可以看到job与其他资源对象不同,仅执行一次性任务,默认pod借宿运行后job即结束,状态为Completed。
//通过查看该pod的日志来确保任务是否完成:
[ yaml]# kubectl logs test-job-dcv6g hello job!
任务完成后,如果没有其他要求,我们可以删除该job:
[ yaml]# kubectl delete jobs.batch test-job job.batch "test-job" deleted
2,提高job执行效率的方法
通过在yaml文件中定义字段来实现:
kind: Job apiVersion: batch/v1 metadata: name: test-job spec: #通过spec下的这两个字段来优化 parallelism: 2 #同时运行2个pod completions: 8 #运行pod的总数量8个 template: metadata: labels: app: job spec: containers: - name: job image: busybox command: ["echo","hello job!"] restartPolicy: Never
job 字段解释:
completions:标志Job结束需要成功运行的Pod个数,默认为1
parallelism:标志并行运行的Pod的个数,默认为1
activeDeadlineSeconds:标志失败Pod的重试最大时间,超过这个时间不会继续重试.
//重新运行job后,查看pod状态:
[ yaml]# kubectl get pod NAME READY STATUS RESTARTS AGE test-job-28ww5 0/1 Completed 0 50s test-job-5wt95 0/1 Completed 0 46s test-job-6s4p6 0/1 Completed 0 44s test-job-8s2v7 0/1 Completed 0 50s test-job-bt4ch 0/1 Completed 0 45s test-job-bzjz6 0/1 Completed 0 48s test-job-fhnvc 0/1 Completed 0 44s test-job-kfn9l 0/1 Completed 0 48s [ yaml]# kubectl logs test-job-28ww5 hello job!
可以看到pod总数为8个,且并行2个,时间会有些许差别,但不大。
3,定时运行job任务:
相当我们在linux中crontab计划任务。
[ yaml]# vim cronjob.yaml kind: CronJob #类型为CronJob apiVersion: batch/v1beta1 metadata: name: cronjob spec: #使用spec.schedule字段来定义计划job任务 schedule: "*/1 * * * *" #指定每分钟执行一次任务,格式同linux中的crontab(分,时,日,月,周) jobTemplate: spec: template: spec: containers: - name: cronjob image: busybox command: ["echo","hello job!"] restartPolicy: OnFailure #仅在pod失败时才重启
//执行yaml文件后监控pod的状态:
[ yaml]# kubectl apply -f cronjob.yaml cronjob.batch/cronjob created
可以看到它会每个一分钟执行一次job任务,每执行一次就会生成一个pod。
查看日志,验证任务是否执行:
[ ~]# kubectl logs cronjob-1577505180-4ss84 hello job! [ ~]# kubectl logs cronjob-1577505240-d5gf8 hello job!
扩展: 添加apiVersion
1)查看当前kubernetes集群中对应的API版本:
[ ~]# kubectl api-versions admissionregistration.k8s.io/v1beta1 apiextensions.k8s.io/v1beta1 apiregistration.k8s.io/v1 apiregistration.k8s.io/v1beta1 apps/v1 apps/v1beta1 apps/v1beta2 authentication.k8s.io/v1 authentication.k8s.io/v1beta1 authorization.k8s.io/v1 authorization.k8s.io/v1beta1 autoscaling/v1 autoscaling/v2beta1 autoscaling/v2beta2 batch/v1 batch/v1beta1 certificates.k8s.io/v1beta1 coordination.k8s.io/v1 coordination.k8s.io/v1beta1 events.k8s.io/v1beta1 extensions/v1beta1 networking.k8s.io/v1 networking.k8s.io/v1beta1 node.k8s.io/v1beta1 policy/v1beta1 rbac.authorization.k8s.io/v1 rbac.authorization.k8s.io/v1beta1 scheduling.k8s.io/v1 scheduling.k8s.io/v1beta1 storage.k8s.io/v1 storage.k8s.io/v1beta1 v1
查看发现并没有开发版本,全是测试版本。
添加api版本:
[ ~]# cd /etc/kubernetes/manifests/ [ manifests]# ll total 16 -rw------- 1 root root 1900 Nov 4 16:32 etcd.yaml -rw------- 1 root root 2602 Nov 4 16:32 kube-apiserver.yaml -rw------- 1 root root 2486 Nov 4 16:32 kube-controller-manager.yaml -rw------- 1 root root 990 Nov 4 16:32 kube-scheduler.yaml [ manifests]# vim kube-apiserver.yaml
在该字段下,参照对应的格式进行添加对应的版本,以上添加的是batch开发版本。
//重启kubelet,重新加载: [ manifests]# systemctl restart kubelet.service
//再次查看api版本时,就可以查看到开发版本: