k8s之Labels,Daemonset,Job资源对象

Label(标签)

我们为什么要使用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:

[[email protected] 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
[[email protected] yaml]# kubectl apply -f  label-pod.yaml
pod/label-pod created
service/nginx-svc unchanged
//查看所有pod,并且显示标签key:value:
[[email protected] 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:

[[email protected] 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:

[[email protected] 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的其他操作(命令行):添加,修改,删除标签
//通过命令行的方式添加标签:

[[email protected] yaml]# kubectl  label  pod label-pod  app=sc
pod/label-pod labeled
[[email protected] yaml]# kubectl  get pod -L app
NAME        READY   STATUS    RESTARTS   AGE   APP
label-pod   1/1     Running   0          36m   sc

//修改标签:

[[email protected] yaml]# kubectl  label pod label-pod app=as
error: ‘app‘ already has a value (sc), and --overwrite is false
[[email protected] yaml]# kubectl  label pod label-pod app=as --overwrite
pod/label-pod labeled

可以看到想要修改标签,必须加上--overwrite选项进行重写。

//删除标签:

[[email protected] yaml]# kubectl  label pod label-pod app-
pod/label-pod labeled
[[email protected] yaml]# kubectl  get pod -L app
NAME        READY   STATUS    RESTARTS   AGE   APP
label-pod   1/1     Running   0          43m                     #可以看到该标签以被删除

//我们测试nginx服务是否能够正常运行:

Label selector

标签选择器:标签的查询过滤条件。
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的操作语法如下:

[[email protected] 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值必须为空。

Daemonset

1)什么是Daemonset?
Daemonset 确保集群中的每个node上运行一个pod,且只能运行一个pod。当有node加入集群时,也会为它们新增一个pod。当有node从集群移除时,这些pod也会 被回收。当删除Daemonset时将会删除它创建的所有pod。

2)编写Daemonset需要注意的点:
Daemonset不支持replicas字段,除此之外,与Deployment,RS等资源的写法相同。

3)Daemonset一般的使用场景:

  • 常用于每个节点的日志收集工作。
  • 监控每个节点的运行状态。

实践Daemonset:

[[email protected] 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
[[email protected] yaml]# kubectl apply -f daemonset.yaml
daemonset.extensions/nginx-ds created
service/nginx-dsvc created

//查看pod的分布情况:

[[email protected] 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资源对象

与之前的服务类容器不同,之前的资源对象是持续提供服务。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
[[email protected] yaml]# kubectl apply -f  job.yaml
job.batch/test-job created

如果在生产环境中忘记了字段用法,可以通过kubectl explain 命令工具来提供帮助。

//查看该pod资源对象的状态:
[[email protected] 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的日志来确保任务是否完成:

[[email protected] yaml]# kubectl  logs  test-job-dcv6g
hello job!

任务完成后,如果没有其他要求,我们可以删除该job:

[[email protected] 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状态:

[[email protected] 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

[[email protected] yaml]# kubectl  logs test-job-28ww5
hello job!

可以看到pod总数为8个,且并行2个,时间会有些许差别,但不大。

3,定时运行job任务:
相当我们在linux中crontab计划任务。

[[email protected] 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的状态:

[[email protected] yaml]# kubectl  apply -f  cronjob.yaml
cronjob.batch/cronjob created

可以看到它会每个一分钟执行一次job任务,每执行一次就会生成一个pod。
查看日志,验证任务是否执行:

[[email protected] ~]# kubectl logs  cronjob-1577505180-4ss84
hello job!
[[email protected] ~]# kubectl logs  cronjob-1577505240-d5gf8
hello job!

扩展: 添加apiVersion
1)查看当前kubernetes集群中对应的API版本:

[[email protected] ~]# 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版本:

[[email protected] ~]# cd /etc/kubernetes/manifests/
[[email protected] 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
[[email protected] manifests]# vim kube-apiserver.yaml 


在该字段下,参照对应的格式进行添加对应的版本,以上添加的是batch开发版本。

//重启kubelet,重新加载:
[[email protected] manifests]# systemctl restart kubelet.service

//再次查看api版本时,就可以查看到开发版本:

原文地址:https://blog.51cto.com/13972012/2462659

时间: 2024-08-01 08:16:05

k8s之Labels,Daemonset,Job资源对象的相关文章

k8s的 Job/CronJob资源对象及添加api版本

Job资源对象 服务类的Pod容器:RC.RS.DS.Deployment 工作类的Pod容器:Job--->执行一次,或者批量执行处理程序,完成之后退出容器. 注意: 如果容器内执行任务有误,会根据容器的重启策略操作容器,不过这里的容器重启策略只能是: Never和 OnFailure. 概念 在有些场景下,是想要运行一些容器执行某种特定的任务,任务一旦执行完成,容器也就没有存在的必要了.在这种场景下,创建pod就显得不那么合适.于是就是了Job,Job指的就是那些一次性任务.通过Job运行一

job资源对象

Job资源对象服务类的Pod容器:RC.RS.DS.Deployment.工作类的Pod容器:Job--->执行一次,或者批量执行处理程序,完成之后推出容器.[[email protected] ~]# cat job.yaml kind: JobapiVersion: batch/v1metadata:name: test-jobspec:template:metadata:name: test-jobspec:containers: name: helloimage: busyboxcomm

k8s核心资源对象& NameSpace(指定版本回滚)

k8s核心的资源对象: Pod:是运行以及调度的原子单位,也就是k8s中最小的资源单位,同一个pod可以同时运行多个container,多个container之间共享:(UTS(主机名和域名),IPC(消息队列和共享内存),NET(网络栈,端口等),namespace(名称空间)),但USR(用户和组),MNT(挂载点),PID(进行编号)是相互隔离的.pod有两种类型的pod:一类是由控制器控制的pod,一类是自主式pod(不受控制器管理,自己管理自己) Deployment:最常见的pod控

Kubernetes 资源对象之DaemonSet

DaemonSet是在Kubernetes1.2 版本新增的一种资源对象 DaemonSet能够让所有(或者一些特定)的Node节点仅运行一份Pod.当节点加入到kubernetes集群中,Pod会被(DaemonSet)调度到该节点上运行,当节点从kubernetes集群中被移除,被(DaemonSet)调度的Pod会被移除,如果删除DaemonSet,所有跟这个DaemonSet相关的pods都会被删除. 在使用kubernetes来运行应用时,很多时候我们需要在一个区域(zone)或者所有

k8s资源对象的升级、回滚、扩容、缩容

一.资源创建的方式之一,命令的方式创建资源,理解命令运行之后的动作,通过查看资源的方式,总结Pod名称的由来. 当我们执行创建资源的命令后,deployment这个控制器会通过replicaset控制器去管理pod,下面通过一个实例来分析,当我们执行创建资源的命令后,k8s都做了些什么(通过其NAME即可发现规律)? 运行一个deployment [[email protected] ~]# kubectl run test01 --image=nginx:latest --replicas=2

K8s资源对象的基本管理(升级、回滚、扩容、缩容)

博文大纲:一.资源创建二.解决客户端无法访问k8s内部pod所运行的服务三.搭建私有仓库,并自定义镜像四.版本扩容.缩容五.服务的升级与回滚 一.资源创建 本次博文主要介绍如何使用命令行的方式创建资源! [[email protected] ~]# kubectl run test --image=nginx:latest --replicas=5 //基于httpd的镜像创建一个deployment类型的控制组,名称为test,并指定副本数量为5 [[email protected] ~]#

Pod资源对象

Deployment,Service,Pod是k8s最核心的3个资源对象. Deployment:最常见的无状态应用的控制器,支持应用的扩缩容,滚动更新等操作. Service:为弹性变动且存在生命周期的Pod对象提供了一个固定的访问接口,用于服务发现和服务访问. Pod:是运行容器以及调度的最小单位.同一个Pod可以同时运行多个容器,这些容器共享NET,UTS,IPC.除此之外还有USER,PID,MOUNT. ReplicationController:用于确保每个Pod副本在任意时刻都能满

Kubernetes 资源对象的理解和定义

Kubernetes里的所有资源对象都可以采用yaml或者JSON格式的文件来定义或描述,下面是一个简单的Pod资源定义文件: apiVersion: v1 kind: Pod metadata: name: myweb labels: name: myweb spec: containers: - name: myweb image: kubeguide/tomcat-app: v1 ports: - containerPort: 8080 env: - name: MYSQL_SERVICE

Kubernetes 资源对象

概述 我将它们简单的分类为以下几种资源对象: 类别 名称 资源对象 Pod.ReplicaSet.ReplicationController.Deployment.StatefulSet.DaemonSet.Job.CronJob.HorizontalPodAutoscaling.Node.Namespace.Service.Ingress.Label.CustomResourceDefinition 存储对象 Volume.PersistentVolume.Secret.ConfigMap 策