电子网站开发技术包括wordpress实现动态功能
一、前言
上一篇文章初步探讨了 Kubernetes 的节点亲和性，了解到它在 Pod 调度上比传统方式更灵活高效。今天我们继续讨论亲和性同时Kubernetes 的调度机制。
二、Pod亲和性
上一篇文章中我们介绍了节点亲和性，今天我们讲解一下Pod亲和性。首先我们先看下Pod亲和性的。使用命令 kubectl explain pods.spec.affinity.podAffinity
解释：
（1）Pod亲和性是Pod调度的规则，类例如将一类的Pod调度到相同的节点，和节点亲和性一样，Pod亲和性也是由一组调度规则组成。
（2）和节点亲和性类似，Pod亲和性也分为软亲和性和硬亲和性
三、软亲和性详解
1、鉴于在上一篇文章中对节点软亲和性做了一些介绍，但是介绍的相对简单，所以本文打算深入的讲解一下软亲和性。
preferredDuringSchedulingIgnoredDuringExecution：软亲和性，从名字中就可以看出
preferred DuringScheduling：优先调度
IgnoredDuringExecution：运行期间忽略
所谓软亲和性是一种建议，建议调度器在调度Pod的时候遵守一定的规则去进行调度，如果没有符合条件的节点，则忽略异常。按照一定的规则（比如负载均衡等等）挑选一个节点部署。同时如果节点变更了导致不符合条件也不会将Pod驱逐。
2、继续深入这个字段，使用命令
kubectl explain pods.spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution
描述：调度器会倾向于将 Pod 调度到满足该字段所指定的亲和性表达式的节点上，但它也可能会选择一个违反了一个或多个表达式的节点。最受青睐的节点是权重总和最大的那个节点。
简单来说：我们可以定义一系列的规则并且为每个规则设定一定的权重，例如
| 规则 | 权重 |
|---|---|
| rule1 | 1 |
| rule2 | 2 |
| rule3 | 3 |
假设我们先2个节点 node1和node2，其中node1符合规则1和2，node2符合规则1、3且不符合规则2。如下表格
| 节点 | 满足条件 | 违反规则 | 权重得分 |
|---|---|---|---|
| node1 | rule1、rule2 | 无 | 3 |
| node2 | rule1、rule3 | rule2 | 4 |
虽然node2节点违反了rule1，但是由权重得分最高，pod也会被调度到node2。这就是软亲和性，一句话来说软亲和性是一种优先调度策略。
调度规则
我们继续查看如何编写调度规则，使用命令kubectl explain 查看podAffinityTerm字段，命令如下
kubectl explain pods.spec.affinity.podAffinity.preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm
FIELDS:labelSelector <LabelSelector>.....篇幅限制，这里删除了描述，下同matchLabelKeys <[]string>mismatchLabelKeys <[]string>namespaceSelector <LabelSelector>namespaces <[]string>topologyKey <string> -required-（1）labelSelector：是一个标签选择器，用于筛选出满足特定标签条件的 Pod。案例：
labelSelector:matchLabels:app: web-server
##筛选出 label中包含 app=web-server 的节点
（2）matchLabelKeys：标签key的选择器，输入一直数组。案例：
matchLabelKeys:- test##筛选出包含label key 包含 test的节点
（3）mismatchLabelKeys：和matchLabelKeys刚好相反，不包含
（4）namespaceSelector：命名空间标签选择器，这里是通过命名空间包含的标签来做选择的
namespaceSelector:matchLabels:purpose: production#筛选出命名空间包含 标签 purpose=product的节点
（5）namespaces：命名空间选择器，选择包含指定命名空间的节点
namespaces:- dev- staging#筛选出包含命名空间 dev、staging的节点
（6）topologyKey（必填）：是一个必需字段，它指定了节点标签的键。Kubernetes 根据这个标签键来确定节点的拓扑域，例如节点的主机名、可用区、机架等
topologyKey: kubernetes.io/hostname
权重：weight
权重就很好理解了，就是为规则设置权重（1-100），k8s匹配规则的时候会计算权重，对于软亲和性来说，权重最高的节点将会被选择。
四、硬亲和性详解
与软亲和性对应的是硬亲和性，requiredDuringSchedulingIgnoredDuringExecution
requiredDuringScheduling：调度期间必须满足
IgnoredDuringExecution：执行期间忽略
结合就是：调度期间必须满足条件，但是执行期间忽略。即当节点变更后导致不符合条件也不会把Pod驱逐
调度规则
查看描述使用命令
kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution
labelSelector <LabelSelector>matchLabelKeys <[]string>mismatchLabelKeys <[]string>namespaceSelector <LabelSelector>namespaces <[]string>topologyKey <string> -required-字段和上面一样，有一点不同的就是没有权重字段，这里不再赘述。硬亲和性要求是必须满足条件，否则无法调度，pod会一直处于Pending状态。如下图
五、总结：
总的来说，Kubernetes 中的 Pod 亲和性为我们提供了极为强大的 Pod 调度控制能力。软亲和性的灵活性与硬亲和性的严格性相互补充，让我们能够根据不同的业务场景和应用需求，精准地规划 Pod 在节点上的分布。这不仅优化了资源利用效率，还增强了系统的稳定性和容错性。希望对你有所帮助