目录

一、标签选择器来源

二、什么是标签选择器

2.1 标签选择器概述

2.2 标签选择器概述属性

三、标签使用场景

四、标签选择器特点

4.1 基本特点

4.2 核心标签选择器

4.3 补充说明

五、标签选择器常用操作命令

5.1 前置准备

5.2 常用操作命令

5.2.1 查看namespace下的标签

5.2.2 查看 deploy控制器标签

5.2.3 查看node节点标签

5.2.4 给Pod资源打标签

5.2.5 给Pod资源更新标签

5.2.6 使用标签选择器筛选

5.2.7 删除标签

六、标签选择器案例演示

6.1 查看当前k8s集群的节点信息

6.2 给工作节点打上标签

6.3 创建一个yaml文件，使用上面创建的标签选择器

七、写在结尾

一、标签选择器来源

对于k8s中pod来讲，使用pod控制器创建的pod发生故障后，重建后的pod的ip地址和名称是变化的，为了解决pod访问问题，我们可以创建service，通过访问service的ip地址就可以正常访问到pod，那么问题来了，service是怎样去关联pod的呢？

我们知道在k8s中如果使用pod控制创建的pod，pod发生故障后，对应pod会被对应的控制器重启或重建，一个pod重建以后，对应的ip地址和名称都会发生变化，所以靠ip地址和名称关联pod是不行的，那靠什么关联pod呢？

在k8s上是使用的标签和标签选择器的机制实现资源和资源间相互关联的

二、什么是标签选择器

2.1 标签选择器概述

K8S提供了一种机制来为资源进行分类，那就是Label（标签），同一类资源会拥有相同的标签，具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改；

1、可以附加到各种资源对象上，如Node,Pod,Service,RC等,一个资源拥有多个标签，可以实现不同维度的管理；

2、给某个资源对象定义一个Label，就相当于给它打了一个标签，可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，K8S通过这种方式实现了类似SQL的对象查询机制；

2.2 标签选择器概述属性

每个资源都存在多维度属性，比如下面这些标签：

• 版本标签："release" : "stable" , "release" : "canary"...
• 环境标签："environment" : "dev" , "environment" : "production"；
• 架构标签："tier" : "frontend" , "tier" : "backend" , "tier" : "middleware"；
• 分区标签："partition" : "customerA" , "partition" : "customerB"...

不同的场景可以选择具有合适属性功能的标签进行使用

三、标签使用场景

• 未使用标签的时候，集群中pod比较多的情况下，分散难以管理，如果需要部署不同版本的应用到不同的环境中，操作起来比较麻烦；
• 如果给不同的pod打上标签之后，就可以进行集中式管理，方便运维；

四、标签选择器特点

4.1 基本特点

• 是Kubernetes核心的分组机制，通过label selector客户端/用户能够识别一组有共同特征或属性的资源对象；
• 对应的资源打上标签后,可以使用标签选择器过滤指定的标签；

4.2 核心标签选择器

matchLabels

用于定义一组Label , 基于等值关系(等于、不等于) ，类似于ＳＱＬ语句中的＝或！＝

matchExpressions

基于集合关系(属于、不属于、存在) ，类似于SQL语句中的in或 not in；

4.3 补充说明

如果同时设置了matchLabels和matchExpressions，则两组条件为 AND关系，即需要同时满足所有条件才能完成Selector的筛选。

五、标签选择器常用操作命令

5.1 前置准备

在上一篇，通过下面这种方式导出了一个nginx.yaml，然后通过yaml创建了一个pod

kubectl create deployment test-nginx3 --image=nginx:1.23.0 --namespace default -o yaml --dry-run=client > ./nginx.yaml

默认情况下查看pod时不会列出任何标签

5.2 常用操作命令

5.2.1 查看namespace下的标签

kubectl get pod -n default --show-labels

这里显示的标签名称，正是导出的nginx.yaml中的下面这里的配置

5.2.2 查看 deploy控制器标签

kubectl get deploy -n default --show-labels

5.2.3 查看node节点标签

kubectl get node --show-labels

5.2.4 给Pod资源打标签

kubectl label pod pod名称 -n default 标签名称

再次查看标签时：kubectl get pod -n default --show-labels  ，可以看到上述打的标签就有了

5.2.5 给Pod资源更新标签

kubectl label pod pod名称 -n default version=2.0 --overwrite

比如在上面那个pod，已经打上了version=1.0，现在将其标签更新为2.0；

5.2.6 使用标签选择器筛选

kubectl get pod -l "标签名称" -n default --show-labels

比如这里我们筛选一下上面给nginx这个pod打的version=2.0这个标签；

5.2.7 删除标签

kubectl label pod pod名称 -n default version-

删除上面这个version=2.0的标签

六、标签选择器案例演示

在上文谈到，使用标签选择器可以很方便的对pod进行管理，举例来说，k8s集群中有很多个工作(node)节点，运维人员在明确了各工作节点的配置前提下，希望在开启某个pod的时候，这个pod被调度到特定的节点上，而不是使用k8s默认的调度策略，这时候就可以先通过给工作节点打标签，然后在启动pod的时候，使用标签选择器选择这个标签即可达到这个目的；

针对上面这个需求，通过实操演示下；

6.1 查看当前k8s集群的节点信息

目前一个master节点，和一个工作节点

6.2 给工作节点打上标签

kubectl label node izbp1hgw1v5d5y7bpvejtwz env=node1

6.3 创建一个yaml文件，使用上面创建的标签选择器

apiVersion: v1
kind: Pod
metadata:name: test-nginx-label
spec:containers:- name: nginximage: nginx:1.23.0imagePullPolicy: IfNotPresentnodeSelector:env: node1

执行之后，可以看到就成功创建了一个pod，并且使用的是自己创建的这个标签选择器；

七、写在结尾

标签的思想最早在docker容器中比较常见，尤其是在生产环境下，当docker容器的数量非常庞大的时候，为了更好的管理不同环境不同版本下的docker容器时，方便运维更好更快捷的找到对应的docker容器，标签这一概念就显得很实用了，k8s中使用标签的思想也源于此，在日常开发中，也可以适当的考虑将标签这一设计思想进行运用。