在 k8s 中，我们会轻轻松松的部署几十上百个微服务，这些微服务的版本，副本数的不同进而会带出更多的 pod
这么多的 pod ，如何才能高效的将他们组织起来的，如果组织不好便会让管理微服务变得混乱不堪，杂乱无章
因此，就有了标签 Label
标签 Label
标签是一种简单的却功能强大的 K8S 的其中一个特性，可以组织 K8S 中的资源，包括 pod 资源
标签是可以被附加到资源的任意键值对的，用来选择具有该确切标签的资源
也就是说，咱们的标签的 key 在资源内部是任意的，可以自己定义，只要是资源内唯一就可以
举个例子
我们可以将上述混乱的多个 pod，定义 2 个标签来进行组织
- app
标识这个 pod 是属于什么应用
- rel
标识这个 pod 中运行的应用版本，例如可以设置如下版本
-
- stable
- beta
- canary
可以这样来组织
通过上述标签的方式来组织微服务，我们可以很轻易的就可以通过 pod 标签来查看我们期望看到的 pod 状态
写个 demo
就用之前的 xmt-kubia,yaml 文件改改，命名为 xmt-kubia-labels.yaml
加上 2 个自定义的标签：
- xmt_create: auto
- rel: stable
apiVersion: v1
kind: Pod
metadata:
name: xmt-kubia-labels
labels:
xmt_create: auto
rel: stable
spec:
containers:
- image: xiaomotong888/xmtkubia
name: xmtkubia-labels
ports:
- containerPort: 8080
protocol: TCP
通过 kubectl create -f xmt-kubia-labels.yaml 将 pod 运行起来
查看实际的标签情况
查看标签
kubectl get pod --show-labels
查看指定的标签
kubectl get po -L rel,xmt_create
修改 pod 的标签
kubectl label pod xmt-kubia-labels key=value
修改已有标签
kubectl label pod xmt-kubia-labels rel=dev --overwrite
标签选择器
就通过上面的案例，发现标签好像用处也不大，其实标签是要和标签选择器结合起来用的
标签选择器可以让我们根据特定的标签查出对应的 pod 集合，并且可以对这些 pod 集合做操作
标签选择器就是一种准则，用于过滤包含具有特定值的特定标签的资源，筛选条件如下：
- 包含或者不包含使用特定键的标签
- 包含具有特定键值的标签
- 包含具有特定键值的标签，但是对应的值和我们指定的不同
使用标签选择器
列出 pod
kubectl get po -l key=value
kubectl get po -l rel=dev
列出包含某个标签的 pod
kubectl get po -l rel
列出不包含某个标签的 pod，需要使用单引号将条件包起来
kubectl get po -l '!rel'
使用感叹号，这个条件可以写成 !rel 表示不包含这个 rel 标签，因为 bash shell 会解析感叹号，所以我们使用 ! ，可以使用单引号 ‘’ 来进行包含和处理
也可以是 在 -l 后面添加 key=value
或者 key != value,
使用 in ，kubectl get po -l 'rel in (dev,prod)'
使用 notin ，kubectl get po -l 'rel notin (dev,prod)'
标签选择器中使用多个条件
kubectl get pod -l 条件1,条件2...
标签选择器可以帮助我们列出筛选后的 pod，我们还可以对于一个子集中的所有 pod 都执行某一类操作，例如删除某个子集内的所有 pod ，就可以是这样写kubectl delete pod -l xx=xx
标签可以用于工作节点的分类
当我们创建 pod 的时候，会有这样的需求，创建的某些 pod 对于 CPU 的计算性能要求比较高，那么我就需要将这类 pod 部署到 性能好的节点上面去，这样的话其实是将 程序和基础架构强耦合了
但是对于 K8S 的思想就不对等了，K8S 中的思想是应用程序隐藏实际的基础架构，在 K8S 中，创建出来的 pod 都是随机分配到不同的 节点上的，
那么，我们需要实现如上的需求，我们可以通过 标签来完成
给 node 加上标签
前面我们说过标签不仅仅是可以加在 pod 上面，实际上可以加上 K8S 中的所有资源上
例如，我们可以给我们的 node 加上一个标签，如： gpu=true，就指定这个 node 的 gpu 比较好，暂时使用 minikube 来演示
将 pod 调度到指定的 node 上面
继续上面的 demo，新建 xmt-kubia-gpu.yaml 文件，在 Spec 下面添加一个 node 选择器， nodeSlector，指定选择 gpu: ”true” 的 node
使用kubectl create -f xmt-kubia-gpu.yaml 即可将创建的 pod 放到 标签为gpu: ”true” 的 node 上进行调度
我们应该通过标签选择器考虑符合特定标准的逻辑节点组 来调度 pod
顺带说一下：
我们若是真想指定 pod 被调度到一个指定的节点上也是可以做的，我们可以通过 kubectl get node --show-labels 查看 node 的标签
能够看到有一个键为 kubernetes.io/hostname 的标签，对应的值是该节点的主机名，因此我们可以利用这个标签来将我们的 pod 调度到指定的节点上面
这种做法会有一个风险，若我们指定的这个节点处于离线状态，那么我们创建的 pod 是不可调度的，这种方式技术上可行，但是不建议这么玩
注解
注解 annotations
注解和标签类似，但是和标签不同，注解不能像标签一个用于对对象的分组
注解能够容纳更多的信息，帮助我们对于资源的作用理解的更加顺畅，注解也是一个键值对的形式
添加和修改注解
kubectl annotate pod podName 具体的键值对
命名空间
命名空间 namespace
不同命名空间内可以有相同的资源名
查看命名空间
kubectl get ns
查看指定命名空间的 pod
kubectl get pod --namespace xxx
创建一个命名空间
- 使用命令的方式
kubectl create namespace xxx
- 使用 yaml 的方式
编写 yaml 文件，使用 kubectl create 创建即可
apiVersion: v1
kind: Namespace
metadata:
name: test_ns
删除命名空间
kubectl delete ns xxx
删除命名空间的 pod，但是保留 命名空间
kubectl delete pod --all
如果 命名空间中有 RC，那么删除的 pod，还会被重新创建出来，RC 会去检测 pod 的副本数量，如果小于设定的副本数量，那么就会动态的创建
删除命名空间中的所有资源
kubectl delete all --all
今天就到这里，学习所得，若有偏差，还请斧正
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是阿兵云原生，欢迎点赞关注收藏，下次见~
更多的可以查看 零声每晚八点直播：https://ke.qq.com/course/417774
