关于后端:Label-2

【k8s 系列】k8s 学习十六，Label2

在 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

明天就到这里，学习所得，若有偏差，还请斧正

欢送点赞，关注，珍藏

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

我是 阿兵云原生，欢送点赞关注珍藏，下次见~