K8S 亲和性与反亲和性

介绍

在 Kubernetes 中,亲和性(Affinity)是一种用于控制 Pod 调度的机制,它允许你指定 Pod 如何与节点进行互动,以便将 Pod 调度到合适的节点上。亲和性可以分为两种类型:节点亲和性(Node Affinity)和 Pod 亲和性(Pod Affinity)。

节点亲和性(Node Affinity)

开始之前需要先给节点打标签,不知道怎样打标签可以看这篇文章

bash 复制代码
## 先查看所有节点的标签
kubectl get nodes --show-labels

## 给其中一个节点打标签
kubectl label nodes node01 disktype=ssd

节点亲和性有两种

硬亲和性 requiredDuringSchedulingIgnoredDuringExecution

指定了 Pod 必须调度到具有指定特征的节点上,如果没有满足条件的节点则 Pod 不会被调度。

举例:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution: # 硬亲和性
        nodeSelectorTerms:
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd            
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

这个Pod正常会部署到node01上面。

字段解释:

  • affinity: 这是 Pod 配置中的一个字段,用于定义亲和性规则。
  • nodeAffinity: 指定了节点亲和性规则。
  • requiredDuringSchedulingIgnoredDuringExecution: 这是一个硬亲和性规则,表示 Pod 必须被调度到满足条件的节点上,否则将无法调度。
  • nodeSelectorTerms: 用于指定匹配条件的节点选择器条款。
  • matchExpressions: 定义了节点选择器的匹配表达式。
  • key: disktype: 指定了匹配条件的键,这里是磁盘类型(disktype)。
  • operator: In: 指定了匹配操作符,这里是 "In",表示匹配键的值在指定的值列表中。
  • values: - ssd: 指定了匹配条件的值列表,这里只有一个值 "ssd",表示磁盘类型为 SSD 的节点符合条件。

operator 参数解释:

下面是你可以在上述 nodeAffinity 和 podAffinity 的 operator 字段中可以使用的所有逻辑运算符。

  • In 标签值存在于提供的字符串集中
  • NotIn 标签值不包含在提供的字符串集中
  • Exists 对象上存在具有此键的标签
  • DoesNotExist 对象上不存在具有此键的标签

以下操作符只能与 nodeAffinity 一起使用:

  • Gt 提供的值将被解析为整数,并且该整数小于通过解析此选择算符命名的标签的值所得到的整数
  • Lt 提供的值将被解析为整数,并且该整数大于通过解析此选择算符命名的标签的值所得到的整数

软亲和性 preferredDuringSchedulingIgnoredDuringExecution

指定了 Pod 倾向于调度到具有指定特征的节点上,但如果没有满足条件的节点也可以被调度。

举例:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution: # 软亲和性
      - weight: 1
        preference:
          matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd          
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

字段解释:

  • weight: 1 表示这个节点亲和性规则的权重为 1。这意味着这个规则相对于其他规则来说是具有相对较低的优先级的。

说明

  • 如果你同时指定了 nodeSelector 和 nodeAffinity,两者必须都要满足, 才能将 Pod 调度到候选节点上。(这个不在举例比较容易理解)

  • 如果你在与 nodeAffinity 类型关联的 nodeSelectorTerms 中指定多个条件, 只要其中一个 nodeSelectorTerms 满足(各个条件按逻辑或操作组合)的话,Pod 就可以被调度到节点上。

  • 如果你在与 nodeSelectorTerms 中的条件相关联的单个 matchExpressions 字段中指定多个表达式, 则只有当所有表达式都满足(各表达式按逻辑与操作组合)时,Pod 才能被调度到节点上。

节点亲和性权重

可以为 preferredDuringSchedulingIgnoredDuringExecution 亲和性类型的每个实例设置 weight 字段,其取值范围是 1 到 100。

举例:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: with-nginx
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: label-1
            operator: In
            values:
            - key-1
      - weight: 50
        preference:
          matchExpressions:
          - key: label-2
            operator: In
            values:
            - key-2
  containers:
  - name: with-node-nginx
    image: nginx

部署成功以后根据亲和度会调度到 节点标签为 kubernetes.io/os=linux,label-2=key-2 的节点上面。

Pod 亲和性(Pod Affinity)

Pod 亲和性定义了 Pod 如何与其他 Pod 进行互动,以便将 Pod 调度到与其他 Pod 相关联的节点上。你可以使用 Pod 亲和性来指定 Pod 与其他 Pod 的关系,如必须调度到与特定 Pod 相同的节点上或避免调度到与特定 Pod 相同的节点上。

Pod 的亲和性与反亲和性也有两种类型:

  • requiredDuringSchedulingIgnoredDuringExecution
  • preferredDuringSchedulingIgnoredDuringExecution

使用 requiredDuringSchedulingIgnoredDuringExecution 亲和性来告诉调度器, 将两个服务的 Pod 必须放到同一个节点上。或者使用 preferredDuringSchedulingIgnoredDuringExecution 尽量将两个服务的Pod 部署到同一个节点上。或者配置反亲和性不部署在同一个节点上面。

Pod 亲和性

举例:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-nginx
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  # 硬亲和性
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-nginx
    image: nginx

只有节点属于特定的区域 且该区域中的其他 Pod 已打上 security=S1 标签时,调度器才可以将示例 Pod 调度到此节点上,否则将不会被调度。软亲和性不在演示和上面这个类似。

还可以添加 namespaceSelector 限制条件:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-nginx
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  # 硬亲和性
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone # 这个是K8S节点的标签。表示必须在节点标签是"topology.kubernetes.io/zone" 的基础上满足上面节点亲和力的条件
    namespaceSelector: 
      matchExpressions:
      - key: environment
        operator: In
        values:
        - production
  containers:
  - name: with-nginx
    image: nginx

这个 namespaceSelector 规定了只有具有标签 environment=production 的命名空间中的 Pod 才会受到这个亲和性规则的影响。这样可以将规则限制在特定环境下的命名空间中,避免对整个集群产生影响。

注意:空的 namespaceSelector({})会匹配所有名字空间,而 null 或者空的 namespaces 列表以及 null 值 namespaceSelector 意味着"当前 Pod 的名字空间"。

Pod 反亲和性

举例:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone
  containers:
  - name: with-pod-affinity
    image: registry.k8s.io/pause:2.0

Pod 反亲和性规则要求将具有相同标签 security=S2 的 Pod 尽量调度到不同的节点上,以提高系统的容错性和可用性。

nodeName

nodeName 是比亲和性或者 nodeSelector 更为直接的形式。nodeName 是 Pod 规约中的一个字段。如果 nodeName 字段不为空,调度器会忽略该 Pod, 而指定节点上的 kubelet 会尝试将 Pod 放到该节点上。 使用 nodeName 规则的优先级会高于使用 nodeSelector 或亲和性与非亲和性的规则。

使用 nodeName 来选择节点的方式有一些局限性:

  • 如果所指代的节点不存在,则 Pod 无法运行,而且在某些情况下可能会被自动删除。
  • 如果所指代的节点无法提供用来运行 Pod 所需的资源,Pod 会失败, - 而其失败原因中会给出是否因为内存或 CPU 不足而造成无法运行。
  • 在云环境中的节点名称并不总是可预测的,也不总是稳定的。

举例:

yaml 复制代码
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kube-01

这个Pod 部署成功以后会运行到 kube-01 节点上。

相关推荐
梅见十柒1 小时前
wsl2中kali linux下的docker使用教程(教程总结)
linux·经验分享·docker·云原生
Python私教2 小时前
ubuntu搭建k8s环境详细教程
linux·ubuntu·kubernetes
运维&陈同学3 小时前
【zookeeper01】消息队列与微服务之zookeeper工作原理
运维·分布式·微服务·zookeeper·云原生·架构·消息队列
O&REO3 小时前
单机部署kubernetes环境下Overleaf-基于MicroK8s的Overleaf应用部署指南
云原生·容器·kubernetes
politeboy4 小时前
k8s启动springboot容器的时候,显示找不到application.yml文件
java·spring boot·kubernetes
运维小文4 小时前
K8S资源限制之LimitRange
云原生·容器·kubernetes·k8s资源限制
登云时刻4 小时前
Kubernetes集群外连接redis集群和使用redis-shake工具迁移数据(二)
redis·容器·kubernetes
wuxingge13 小时前
k8s1.30.0高可用集群部署
云原生·容器·kubernetes
志凌海纳SmartX14 小时前
趋势洞察|AI 能否带动裸金属 K8s 强势崛起?
云原生·容器·kubernetes
锅总14 小时前
nacos与k8s service健康检查详解
云原生·容器·kubernetes