亲和性与反亲和性
亲和调度的前置概念（重要）
-
label在K8S中是非常重要的概念，不管是什么场景，只要和选择、筛选相关的，基本是用label字段来匹配的。
-
亲和性和反亲和性的调度，筛选的条件依旧用的是Node的label字段。
-
不管是Node亲和性调度，还是Pod亲和性调度，被调度的主体都是Pod。都是讲的Pod根据亲和规则调度到某个节点，或者Pod跟随别的Pod调到到某个节点（比如Pod1跟随Pod2，Pod2被调度到B节点，那么Pod1也被调度到B节点）。
-
Node亲和性调度 和 Pod亲和性调度 的配置都是写在 编排Pod的yaml里。因为被调度的主体是Pod。
-
Node亲和性调度是指Pod和Node的亲密关系。
-
Pod亲和性调度是指Pod和Pod的亲密关系。
-
硬亲和：亲和规则只有一种，必须符合该规则。
-
软亲和：规则有多种，每个权重不同，根据权重优先级去选择一个规则。
-
Node亲和性调度的图示如下，Pod亲和性调用和Pod反亲和性调用也类似。
两种亲和表达式
-
RequiredDuringSchedulingIgnoredDuringExecution：硬亲和，硬性、强制
必须满足指定的规则才可以把Pod调度到该Node上。这里注意Required这个词，中文意思必须的。
-
PreferredDuringSchedulingIgnoredDuringExecution：软亲和，优先
强调优先满足某个规则，然后根据优先的规则，将Pod调度到节点上。这里注意Preferred这个词，中文意思是首选，用来说明选择规则的优先级，确实比较合适。
-
nodeAffinity：Node亲和
-
podAffinity：Pod亲和
-
nodeAntiAffinity：Node反亲和
-
podAntiAffinity：Pod反亲和
表达式中的操作符
亲和性表达方式需要用到如下几个可选的操作符operator：
-
In：标签的值在某个列表中（这个常用，下面都不常用）
-
NotIn：标签的值不在某个列表中
-
Exists：存在某个标签
-
DoesNotExist：不存在某个标签
-
Gt：标签的值大于某个值（字符串比较）
-
Lt：标签的值小于某个值（字符串比较）
作用域topologyKey
topologyKey很多地方解释为拓扑建，很是费解。实际上就是个作用域的概念。
topologyKey配置了一个label的key，那么存在这个key对应的label的所有Node就在同一个作用域里。
Node亲和调度
1.硬亲和
vim 03-required-affinity.yaml
apiVersion: v1
kind: Pod
metadata:
name: webapp
#namespace: mynamespace
labels:
app: webapp
spec:
containers:
- name: webapp
image: 192.168.57.200:8099/library/nginx:1.21
ports:
- containerPort: 80
affinity: #定义 Pod 的节点亲和性配置
nodeAffinity: #指定节点亲和性规则
requiredDuringSchedulingIgnoredDuringExecution: # 定义硬性要求，如果找不到满足条件的节点，Pod 不会被调度
nodeSelectorTerms: # 定义一个或多个必须满足的条件
- matchExpressions: # 定义一系列的关键值对条件
- key: app # 要匹配的标签键
operator: In # 操作符，In 表示标签值必须在给定的列表中
values: # 列出允许的标签值
- backend
# 给node2节点增加标签
kubectl label node node2 app=backend
# 应用然后发现Pod被部署到了node2节点
kubectl apply -f 03-required-affinity.yaml
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
webapp 1/1 Running 0 19s 10.244.3.249 node2 <none> <none>
2.软亲和
# 比硬亲和多了一些配置，多了个权重，表现情况一致
vim 04-preferred-affinity.yaml
apiVersion: v1
kind: Pod
metadata:
name: webapp
labels:
app: webapp
spec:
containers:
- name: webapp
image: 192.168.57.200:8099/library/nginx:1.21
ports:
- containerPort: 80
affinity:
nodeAffinity: # 定义节点亲和性规则，用于控制 Pod 调度到哪些节点上
preferredDuringSchedulingIgnoredDuringExecution: # 定义在调度时优先考虑的规则，但在运行时不强制执行
- weight: 80 # 权重为 80，表示这个规则的优先级较高
preference: # 定义匹配规则
matchExpressions: # 使用表达式来匹配节点标签
- key: app2 # 检查节点标签中是否存在key为 "app2" 的标签
operator: Exists # 使用 "Exists" 操作符，表示只要节点有这个标签就满足条件
- weight: 20 # 权重为 20，表示这个规则的优先级较低
preference: # 定义匹配规则
matchExpressions: # 使用表达式来匹配节点标签
- key: app # 检查节点标签中是否存在key为 "app" 的标签
operator: In # 使用"In"操作符，表示节点的标签值必须在给定的值列表中
values: # 定义允许的标签值列表
- backend2 # 节点标签的值必须是 "backend2"
3.Pod亲和调度和反亲和
# Pod亲和的硬亲和
vim 06-pod-required-affinity.yaml
apiVersion: v1
kind: Pod
metadata:
name: webapp-1
labels:
app: webapp-1
spec:
containers:
- name: webapp
image: 192.168.57.200:8099/library/nginx:1.21
ports:
- containerPort: 80
affinity: # 定义 Pod 的亲和性配置
podAffinity: # 定义 Pod 与其它 Pod 之间的亲和性规则
requiredDuringSchedulingIgnoredDuringExecution: #定义硬性要求，Pod 必须调度到满足条件的节点上
- topologyKey: kubernetes.io/hostname # 定义拓扑域，例如 "kubernetes.io/hostname" 表示主机名
labelSelector: # 选择具有特定标签的 Pod
matchExpressions: # 定义标签选择器的表达式
- key: app # 要匹配的标签键
operator: In # 操作符，In 表示标签值必须在给定的列表中
values: # 列出允许的标签值
- webapp # 通过这些注释，可以清楚地理解这个配置要求当前 Pod 必须与具有 app=webapp 标签的 Pod 调度到相同的节点上（因为 topologyKey 是 kubernetes.io/hostname，表示同一主机）。
# 这种配置通常用于确保相关服务位于同一节点，以减少网络延迟或满足其它部署需求。
kubectl apply -f 06-pod-required-affinity.yaml
pod/webapp-1 created
# 这个Pod-1会因为亲和度跟着之前的Pod一起被调度到node2节点
kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
webapp 1/1 Running 0 13m 10.244.3.249 node2 <none> <none>
webapp-1 1/1 Running 0 14s 10.244.3.250 node2 <none> <none>
# Pod反亲和的硬亲和
vim 08-pod-required-antiaffinity.yaml
apiVersion: v1
kind: Pod
metadata:
name: webapp-2
labels:
app: webapp-2
spec:
containers:
- name: webapp
image: 192.168.57.200:8099/library/nginx:1.21
ports:
- containerPort: 80
affinity: # 定义 Pod 的亲和性配置
podAntiAffinity: # 定义 Pod 与其它 Pod 之间的反亲和性规则
requiredDuringSchedulingIgnoredDuringExecution: #定义硬性要求，Pod 必须调度到满足条件的节点上
- topologyKey: kubernetes.io/hostname # 定义拓扑域，例如 "kubernetes.io/hostname" 表示主机名
labelSelector: # 选择具有特定标签的 Pod
matchExpressions: # 定义标签选择器的表达式
- key: app # 要匹配的标签键
operator: In # 操作符，In 表示标签值必须在给定的列表中
values: # 列出允许的标签值
- webapp # 通过这些注释，可以清楚地理解这个配置要求当前 Pod 必须与具有 app=webapp 标签的 Pod 避免调度到相同的节点上（因为使用了 podAntiAffinity）。
# 这种配置通常用于确保高可用性，避免将多个副本调度到同一节点，从而减少单点故障的风险。
# 这个Pod-2会因为反亲和度不和Pod在一起，调度到node1节点
kubectl apply -f 08-pod-required-antiaffinity.yaml
kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
webapp 1/1 Running 0 18m 10.244.3.249 node2 <none> <none>
webapp-1 1/1 Running 0 4m44s 10.244.3.250 node2 <none> <none>
webapp-2 1/1 Running 0 13s 10.244.1.35 node1 <none> <none>
总结：
-
亲和性 和 反亲和性的调度，筛选的条件使用的是Node（Pod）的label字段。
-
亲和性调度：就好像Node（Pod）和Pod是关系很好的闺蜜，Pod说，“只要符合这种label的Node（Pod）都是我的好闺蜜，闺蜜在哪儿我就去哪儿”。
-
反亲和性调度：就好像2个Pod是赌气的2个孩子，互相对着干，一个往东，另一随便去哪个方向就是不往东，他们不会去到同一个地方。
Pod的资源控制器类型
-
Pod类型：
-
自主运行的Pod（静态Pod）
-
管理器运行的Pod（动态Pod）
-
控制器类型：
1.ReplicationController（RC）/ReplicaSet（RS）
-
副本控制器：动态的控制Pod的数量
-
RS和RC功能一致，增加selector集合选择器
-
很少独立使用，而是被其他管理器调用
2.Deployment
-
实现业务的部署，部署无状态服务
-
控制副本数量，实现扩容和缩容
-
控制容器的镜像版本，实现升级和回滚
3.DaemonSet
-
在每个Node节点上自动部署Pod
-
例如：K8s监控、网络插件
4.StateFulSet（StS）
-
用户部署有状态服务
-
Pod的名称唯一且有序
-
适合部署数据库一类的容器
5.Job与cronJob
-
Job是一次性任务，控制Pod运行成功后自动销毁
-
cronJob：crontab语法“分时日月周”设置周期执行Pod
6.Horizontal Pod Autoscaling
-
水平Pod自动扩缩容管理器，简称HPA
-
根据CPU占有率来决定是否扩缩容
-
设置阈值：Pod的最大值和最小值
扫一扫
1309
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
