11.标签和亲和力

1.标签-Label

1.1.什么是标签

标签（Labels） 是附加到 Kubernetes对象（比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。

1.2.标签的语法

标签是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（/）分隔。 名称段是必需的，必须小于等于 63 个字符，以字母数字字符（[a-z0-9A-Z]）开头和结尾， 带有破折号（-），下划线（_），点（ .）和之间的字母数字。 前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（.）分隔的一系列 DNS 标签，总共不超过 253 个字符， 后跟斜杠（/）。

如果省略前缀，则假定标签键对用户是私有的。 向最终用户对象添加标签的自动系统组件（例如 kube-scheduler、kube-controller-manager、 kube-apiserver、kubectl 或其他第三方自动化工具）必须指定前缀。

kubernetes.io/ 和 k8s.io/ 前缀是为 Kubernetes 核心组件保留的。

有效标签值：

• 必须为 63 个字符或更少（可以为空）
• 除非标签值为空，必须以字母数字字符（[a-z0-9A-Z]）开头和结尾
• 包含破折号（-）、下划线（_）、点（.）和字母或数字

例如，以下是一个清单 (manifest)，适用于具有 environment: production 和 app: nginx 这两个标签的 Pod：

1.3.标签的作用是什么

标签就是为了节点标明属性，用于区分不同的节点。

1.4.标签如何使用

关于标签的使用，大概分为四方面:增、删、改、查。

1.4.1.增

修改node节点k8s-node02的label为region=subnet7

oot@k8s-master01:~/hhh# kubectl label nodes node-02 region=subnet7
node/node-02 labeled

1.4.2.删

单个去除node节点k8s-node02的label：region=subnet7

root@k8s-master01:~/hhh# kubectl label nodes node-02  region-
node/node-02 unlabeled

批量删除符合标签选择器条件的所有节点的标签

root@k8s-master01:~/hhh# kubectl label node -l region region-

1.4.3.改

单个修改node节点k8s-node02的label：region=subnet120

root@k8s-master01:~/hhh# kubectl label node node-02 region=subnet120 --overwrite
node/node-02 labeled

批量修改符合标签选择器条件的所有节点的标签

root@k8s-master01:~/hhh# kubectl label node -l region region=subnet100

1.4.4.查

查看单个节点的标签

查看所有节点的标签

筛选节点标签含region的节点

选择匹配 region 为subnet100 的 node

1.5.标签如何结合标签选择器使用

nodeSelector 是节点选择约束的最简单推荐形式。你可以将 nodeSelector 字段添加到 Pod 的规约中设置你希望目标节点所具有的节点标签。 Kubernetes 只会将 Pod 调度到拥有你所指定的每个标签的节点上。

下面以一个具体的示例进行演示:

1.修改node节点node-02的label为region=subnet7

root@k8s-master01:~/hhh# kubectl label nodes node-02 region=subnet7 --overwrite
node/node-02 labeled

2.筛选标签为region=subnet7的节点

3.在 Deployment 控制器添加标签指定将 Pod 部署到带标签的节点上

4.查看pod部署节点，观察到都已部署到node-02节点上

2.亲和力-Affinity

2.1.什么是亲和力

亲和力（Affinity）是 Kubernetes 中的一种机制，用于指定 Pod 与其他资源（如节点、Pod 或标签）之间的关联性和偏好。

亲和力定义了 Pod 对其他资源的偏好和互动方式，以便在调度过程中进行合适的匹配。通过使用亲和力规则，可以将 Pod 调度到满足特定条件的节点上，或者将 Pod 与其他相关的 Pod 进行关联，以实现特定的调度需求和业务需求。

nodeSelector 提供了一种最简单的方法来将 Pod 约束到具有特定标签的节点上。 亲和性和反亲和性扩展了你可以定义的约束类型。使用亲和性与反亲和性的一些好处有：

• 亲和性、反亲和性语言的表达能力更强。nodeSelector 只能选择拥有所有指定标签的节点。 亲和性、反亲和性为你提供对选择逻辑的更强控制能力。
• 你可以标明某规则是“软需求”或者“偏好”，这样调度器在无法找到匹配节点时仍然调度该 Pod。
• 你可以使用节点上（或其他拓扑域中）运行的其他 Pod 的标签来实施调度约束， 而不是只能使用节点本身的标签。这个能力让你能够定义规则允许哪些 Pod 可以被放置在一起。

亲和性功能由两种类型的亲和性组成：

• 节点亲和性功能类似于 nodeSelector 字段，但它的表达能力更强，并且允许你指定软规则。
• Pod 间亲和性/反亲和性允许你根据其他 Pod 的标签来约束 Pod。

2.2.亲和力出现背景

我们可以使用Taint让节点不能随便部署Pod，也通过NodeSelector+Toleration实现了将Pod部署到指定的节点上。但是NodeSelector对节点的选择是强制性的，假如配置了NodeSelector为ssd=true，那么如果集群中没有匹配的节点，这个Pod将一直处于Pending状态。而在生产环境中可能会有这样的需求：

• 某些Pod优先选择有ssd=true标签的节点，如果没有再考虑部署到其他节点。
• 某些Pod需要部署在ssd=true和type=physical的节点上，但是优先部署在ssd=true的节点上。
• 同一类应用的Pod尽量不要部署或不允许部署在同一个节点或者符合某个标签的一类节点上。
• 相互依赖的两个Pod尽量或必须部署在同一个节点上。

诸如此类的需求单单使用NodeSelector、NodeName、Taint和Toleration是无法实现的，所以Kubernetes引用了Affinity（亲和力）的概念，用于满足生产环境中更复杂的需求。

2.3.亲和力分类

Affinity根据功能的不同分为节点亲和力（Node Affinity）和Pod亲和力（Pod Affinity），每种亲和力还有两种不同的“实现方法”，即必须和尽量，所以亲和力又分为软亲和力（非强制性）和硬亲和力（强制性）。还可以看出Pod之间可以相互排斥，也可以相互吸引，所以Pod亲和力又分为PodAffinity（Pod亲和力）和PodAntiAffinity（Pod反亲和力），每种亲和力均可以使用软亲和力和硬亲和力。

• Affinity:亲和力
• Node Affinity:节点亲和力
• Pod Affinity:Pod亲和力
• PodAntiAffinity:Pod反亲和力
• 硬亲和力:requiredDuringSchedulinglgnoredDuringExecution
• 软亲和力:preferredDuringSchedulinglgnoredDuringExecution

2.4.亲和力使用场景

2.4.1.场景一:同一个应用部署至不同宿主机

在使用Kubernetes时，一般都会有很多节点运行容器，此时可以使用Pod反亲和力将同一个应用部署到不同的节点上，达到更高的可用率，以免同一个应用部署到相同的宿主机带来的风险。

1.查看节点污点情况

2.定义一个名为podAntiAffinity01的yaml文件

3.开始部署

root@k8s-master01:~/hhh# kubectl create -f podAntiAffinity01.yaml 
deployment.apps/must-be-diff-nodes created

4.查看pod状态，观察到pod被部署到不同节点

5.扩容副本数为4个

[root@k8s-master01 Affinity]# kubectl scale deployment must-be-diff-nodes --replicas=4 -n kube-public
deployment.apps/must-be-diff-nodes scaled

6.再次查看Pod状态，发现有一个节点处于Pending

7.详细查看Pod处于Pending原因，这是因为我们设置的是硬亲和力，必须部署在不同宿主机上，节点只有5个，而副本数设置为6个，所以导致一直处于Pending

2.4.2.场景二:Pod只能部署在Node节点上

方式一:同一个topology设置Pod反亲和力使Pod只能部署在Node节点上

1.查看节点污点情况

2.给node节点打上标签

root@k8s-master01:~/hhh# kubectl label nodes node-01 node-02 app=must-be-diff-nodes

3.定义一个名为podAntiAffinity02的yaml文件

4.开始部署

root@k8s-master01:~/hhh# kubectl create -f podAntiAffinity02.yaml 
deployment.apps/must-be-diff-nodes created

5.查看pod状态，观察到pod被部署到不同节点

方式二:设置节点亲和力使Pod只能部署在Node0102节点上

1.查看节点污点情况

2.给node01、node02节点打上app=must-be-diff-nodes标签

root@k8s-master01:~/hhh# kubectl label node  node-03 app=must-be-diff-nodes
node/node-03 labeled

3.定义一个名为podAntiAffinity04的yaml文件

4.开始部署

[root@k8s-master01 Affinity]# kubectl create -f podAntiAffinity04.yaml 
deployment.apps/must-be-diff-nodes created

5.查看pod状态，观察到pod被部署到node节点

2.4.3.场景三:尽量调度到高配置服务器

1.给node-01节点打上ssh=true的标签，node-02打上ssh=true和gpu=true的标签，k8s-node03节点打上type=physical的标签方便演示

2.观察以上操作是否完成

3.定义一个yaml文件

4.开始部署

root@k8s-master01:~/hhh# kubectl create -f podAntiAffinity05.yaml 
deployment.apps/prefer-ssd created

5.结果查看，观察到Pod节点部署到node-01上

6.把k8s-node01节点上的ssd=true标签去除，再次进行创建

7.结果查看，观察到Pod节点部署到node-03上。这是因为node-02节点有gpu限制，所以会次优部署到node-03上。

2.4.4.场景四:同一个应用不同副本的固定节点

有时候公司会有一些有状态的服务需要部署在Kubernetes集群中，我们并不需要该服务所在节点宕机时自动漂移Pod，因为可能会带来数据上的丢失，所以需要固定节点去运行，而我们同时也不想每个副本出现部署在同一台宿主机的情况，此时可以使用NodeSelector（NodeAffinity也可以）+PodAntiAffinity实现这一需求。

1.查看节点污点情况

2.给node-03 node-02节点打上app=must-be-diff-nodes标签

root@k8s-master01:~/hhh# kubectl label nodes node-02 node-03 app=must-be-diff-nodes

3.定义一个名为podAntiAffinity06的yaml文件

4.开始部署

root@k8s-master01:~/hhh# vim podAntiAffinity06.yaml
root@k8s-master01:~/hhh# kubectl create -f  podAntiAffinity06.yaml

5.查看pod状态，观察到pod被部署到不同master节点

6.更改副本数为3

2.4.5.场景五:应用和缓存尽量部署在同一个域内

一种很常见的架构是后端服务器需要请求缓存中间件，而不是直接请求数据库来提高数据加载速度。在实际使用时，缓存中间件可能也是部署在Kubernetes集群中（如上一个示例），所以此时可以利用Pod反亲和力将后端应用尽量和缓存中间件部署在同一个域内的不同节点，用以减少网络上的消耗。

1.查看节点污点情况

2.定义一个名为podAntiAffinity07的yaml文件

4.开始部署

root@k8s-master01:~/hhh# kubectl create -f podAntiAffinity07.yaml
deployment.apps/must-be-diff-nodes created

5.查看pod状态，观察到pod被部署到不同node节点

2.5.亲和力配置详解

2.5.1.节点亲和力配置详解

1.yaml文件展示

上述配置的Pod只能部署在具有label的key为http://kubernetes.io/e2e-az-name、value为e2e-az1或az-2的节点上，但是因为配置了软亲和力，所以在满足上述条件时，会尽量部署在具有another-node-label-key= another-node-label-value的节点上。当然这个条件不是强制要求的，没有该标签的Node不会影响部署。

文件参数说明如下： (1)requiredDuringSchedulingIgnoredDuringExecution：硬亲和力配置

• nodeSelectorTerms：节点选择器配置，可以配置多个matchExpressions（满足其一），每个 matchExpressions下可以配置多个key、value类型的选择器（都需要满足），其中values可以配置多个 （满足其一）

(2)preferredDuringSchedulingIgnoredDuringExecution：软亲和力配置

• weight：软亲和力的权重，权重越高优先级越大，范围1-100
• preference：软亲和力配置项，和weight同级，可以配置多个，matchExpressions和硬亲和力一致

(3)operator：标签匹配的方式

• In：相当于key = value的形式
• NotIn：相当于key != value的形式
• Exists：节点存在label的key为指定的值即可，不能配置values字段
• DoesNotExist：节点不存在label的key为指定的值即可，不能配置values字段
• Gt：大于value指定的值
• Lt：小于value指定的值

注意:如果同时指定了NodeSelector和NodeAffinity，需要两者都满足才能被调度；如果配置了多个NodeSelectorTerms，满足其一即可调度到指定的节点上；如果配置了多个MatchExpressions，需要全部满足才能调度到指定的节点上；如果删除了被调度节点上的标签，Pod不会被删除，也就是说亲和力配置只有在调度的时候才会起作用。

2.5.2.Pod亲和力和反亲和力配置详解

NodeAffinity是根据节点上的标签选择性地调度，可以让Pod部署在指定标签的节点上，或者不部署在指定标签的节点上，调度时是根据节点上的标签进行选择的。而Pod亲和力和反亲和力是根据其他Pod的标签进行匹配的，比如想要A服务的Pod不能和具有service=b标签的Pod部署在同一个节点上，此时可以使用Pod亲和力和反亲和力进行配置，该调度是基于Pod的标签进行选择的。

1.yaml文件展示

文件参数说明如下：

• labelSelector：Pod选择器配置，可以配置多个
• matchExpressions：和节点亲和力配置一致
• operator：配置和节点亲和力一致，但是没有Gt和Lt
• topologyKey：匹配的拓扑域的key，也就是节点上label的key，key和 value相同的为同一个域，可以用于标注不同的机房和地区
• Namespaces: 和哪个命名空间的Pod进行匹配，为空为当前命名空间

上述Pod亲和力配置的是硬亲和力，也就是必须和具有security为S1标签的Pod部署在同一个域内，域的名称为http://failure-domain.beta.kubernetes.io/zone。但同时又配置了Pod反亲和力，尽量不和具有security为S2标签的Pod部署在同一个域内，所以该Pod要求在http://failure-domain.beta.kubernetes.io/zone的域内，要和security为S1部署在一起，尽量不和security为S2部署在一起。

由于Pod的标签是Pod本身的配置，因此它和Pod一样具有隔离性，也就是说在配置Pod亲和力和反亲和力时可以匹配其他Namespace下的Pod的标签。

注意:由于在使用Pod亲和力和Pod反亲和力时，需要进行大量的计算，会降低大规模集群下的调度速率，因此在集群节点超过数百时，并不建议使用过多的Pod亲和力配置。

2.6.拓扑域TopologyKey详解

拓扑域，主要针对宿主机，相当于对宿主机进行区域的划分。用label进行判断，不同的key和不同的value是属于不同的拓扑域.

下面演示同一个应用多区域部署:

1.根据标签区分区域，其中node01为大兴区，node02为朝阳区，node03为XX区

2.查看标签是否已经打上

3.定义一个yaml文件

4.开始部署

root@k8s-master01:~/hhh# kubectl create -f podAntiAffinity03.yaml
deployment.apps/must-be-diff-zone created

5.查看pod节点状态