<svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <path stroke-linecap="round" d="M5,0 0,2.5 5,5z" id="raphael-marker-block" style="-webkit-tap-highlight-color: rgba(0, 0, 0, 0);"></path> </svg> 

1.给node节点打上标签

讯享网

2.通过nodeSelectro 调度pod

• nodeSelectro为硬限制，必须要满足的条件有：指定标签和值。

• Affinity [əˈfɪnəti]/anti-affinity node 相对于nodeSelector机制更加的灵活和丰富
  • 表达的语法：支持In,NotIn,Exists,DoesNotExist,Gt,Lt．匹配标签的方式
  • 支持soft(preference)和hard(requirement),

    讯享网<ul><li>hard表示pod sheduler到某个node上时必须满足的亲和性设置&#xff0e;</li><li>soft表示scheduler的时候&#xff0c;当无法满足节点的时候&#xff0c;会选择非 nodeSelector 匹配的节点&#xff0e;</li><li>requiredDuringSchedulingIgnoredDuringExecution 硬亲和性 必须满足亲和性</li><li>preferredDuringSchedulingIgnoredDuringExecution 软亲和性 能满足最好&#xff0c;不满足也没关系。</li></ul> </li><li>nodeAffinity 的基础上添加多个 nodeSelectorTerms 字段&#xff0c;调度的时候 Node 只需要 nodeSelectorTerms 中的某一个符合条件就符合 nodeAffinity 的规则&#xff0e;在nodeSelectorTerms 中添加 matchExpressions&#xff0c;需要可以调度的Node是满足 matchExpressions 中表示的所有规则&#xff0e;</li></ul> </li><li>需要注意的是preferredDuringSchedulingIgnoredDuringExecution和requiredDuringSchedulingIgnoredDuringExecution名字中后半段字符串IgnoredDuringExecution表示的是&#xff0c;在Pod资源基于节点亲和性规则调度到某个节点之后&#xff0c;如果节点的标签发生了改变&#xff0c;调度器不会将Pod对象从该节点上移除&#xff0c;因为该规则仅对新建的Pod对象有效。</li></ul> 

    1.硬亲和性

    • 硬亲和性是强制性的规则，Pod调度时必须满足的规则。
    • 如果存在满足硬亲和性规则的节点，Pod将被调度至该节点；否则，Pod将无法正常调度，处于Pending状态。

    2.软亲和性

    • 软亲和性允许Pod对象定义针对一组可以调度于其上的节点的偏好，调度器会尽量满足此需求，但在无法满足调度需求时，它会退而求其次地选择一个不匹配规则的节点。
    • 优化Pod的调度，以便将Pod调度到满足特定条件的节点上，从而实现更高效的资源利用、提高容错性和性能等方面的需求。

    讯享网

    3.软硬亲和性同时存在

    • 当软硬亲和性同时存在时，硬亲和性具有更高的优先级。调度器会首先检查硬亲和性规则，如果找到满足条件的节点，则将该Pod调度到该节点上。
    • 如果找不到满足硬亲和性规则的节点，Pod将处于Pending状态，直到找到满足条件的节点或超时。

    基于已经运行在 Node 上 pod 的 labels 来决定需要新创建的Pods是否可以调度到node节点上，配置的时候可以指定那个namespace中的pod需要满足pod的亲和性．可以通过 topologyKey 来指定 topology domain, 可以指定为 node／cloud provider zone 的范围．

    • 表达的语法：支持In, NotIn, Exists, DoesNotExist
    • Pod的亲和性和反亲和性可以分成
      • requiredDuringSchedulingIgnoredDuringExecution　 # 硬要求
      • preferredDuringSchedulingIgnoredDuringExecution　＃软要求
    • labelSelector : 选择跟那组Pod亲和
    • namespaces : 选择哪个命名空间

      
      讯享网

    • topologyKey : 指定节点上的哪个键，可以设置成如下几种类型(节点标签) 1、标签是不是存在（硬性），2、节点key的值相同的情况下只启动一个 ， 应用场景 ，高可用 上海，北京， 广州 zone=beijing 多个node1-10 zone=shanghai 多个node11-20 zone=guangzhou 多个node21-30 rediis 3个节点 夸区高可用部署
      • kubernetes.io/hostname　　＃Node
      • failure-domain.beta.kubernetes.io/zone　＃Zone
      • 可以设置node上的label的值来表示node的name,zone,region等信息，pod的规则中指定topologykey的值表示指定topology 范围内的 node 上运行的 pod 满足指定规则

    1.pod亲和性

    • Pod反亲和性场景，当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。

    讯享网

    2.pod反亲和性

    • Pod反亲和性场景，当应用服务A和数据库服务B要求尽量不要在同一台节点上的时候。

    3.pod亲和性和反亲和性

    讯享网

    1)、podAffinity 亲和性要求满足

    • node上具有 kubernetes.io/hostname区域，并且 node 上运行有一个pod 包含标签 label为securtity=S1.

    2)、podAntiAffinity 反亲和性要求满足

    • 不会调度 pod 到运行包含有 security=S2 的 pod 的 node上．
    • 如果这里将topologyKey＝ kubernetes.io/hostname，那么 pod 将不会调度到 node
    • 满足的条件是：node上具有 kubernetes.io/hostname 相同的 value,并且这些相同 zone下的 node 上运行有 security=S2 的 pod

    3)、对于topologyKey字段具有如下约束 第一步 要配置有key (节点标签名)， 第二步这个标签相同值的节点只能启动一个pod zone=cd

    • topologyKey 定义pod亲和性调度和反亲和性调度中需要各个相关的pod对象是否运行于“同一位置”，指定“同一位置” 是通过 topologyKey 来定义的，topologyKey 对应的值是 node 上的一个标签名称
    • 如果topologyKey指定区域已经在运行一个或多个满足LabelSelector规则的Pod，则该Pod应该（或者在非亲和性的情况下不应该）在 topologyKey 中运行
    • 对于亲和性和 反亲和性 requiredDuringSchedulingIgnoredDuringExecution （硬亲和），topologyKey 不能为空。
    • 对于 反亲和 性 requiredDuringSchedulingIgnoredDuringExecution（硬亲和） ，引入 LimitPodHardAntiAffinityTopology 准入控制器来限制 topologyKey 只能是 kubernetes.io/hostname。如果要使用自定义拓扑域，则需要修改准入控制器，或者直接禁用它。
    • 对于反亲和性 preferredDuringSchedulingIgnoredDuringExecution （软亲和），空的 topologyKey 表示所有拓扑域，没有限制。
    • topologyKey 除上述情况外，可以是 node 任何合法的标签 key。规则中可以指定匹配pod所在namespace,如果定义了但是为空，它表示所有namespace范围内的pod.
    • 所有关联requiredDuringSchedulingIgnoredDuringExecution（硬亲和）的matchExpressions全都满足之后，系统才能将pod调度到某个node上。

    4.topologKey 调度

    需求：当前有两个机房（ beijing，shanghai），需要部署一个nginx产品，副本为两个，为了保证机房容灾高可用场景，需要在两个机房分别部署一个服务器

    1.pod反亲和性调度

    创建了一个Deployment,副本数为３，指定了反亲和规则如上所示，pod的label为app:store,那么pod调度的时候将不会调度到node上已经运行了label为app:store的pod了，这样就会使得Deployment的三副本分别部署在不同的host的node上

    讯享网

    2.pod亲和性调度

    在一个例子中基础之上，要求pod的亲和性满足 requiredDuringSchedulingIgnoredDuringExecution 中topologyKey=”kubernetes.io/hostname”,并且 node上需要运行有 app=store 的label.

    

    3.pod亲和性调度

    在一些应用中，pod副本之间需要共享cache,需要将pod运行在一个节点之上

    讯享网

    污点（Taints）和污点容忍（Tolerations）是 Kubernetes（k8s）中用于节点调度的另一种重要机制。以下是对污点容忍调度的详细解释：

    1、污点（Taints）

    污点是定义在节点上的键值型属性数据，用于让节点拒绝将 Pod 调度运行于其上，除非 Pod 有接纳节点污点的容忍度。污点可以使节点能够排斥一类特定的 Pod，避免 Pod 调度到特定节点上。

    污点的格式：

    2、污点容忍（Tolerations）

    污点容忍是定义在 Pod 上的键值型属性数据，用于配置 Pod 可容忍的污点。调度器只能将 Pod 调度到该 Pod 能够容忍的污点的节点上。

    讯享网

    3.污点与容忍度匹配规则

    1. 当Pod的容忍度与节点的污点在键、值（当操作符为Equal时）和效应上完全匹配时，Pod可以被调度到该节点上。
    2. 如果Pod的容忍度使用Exists操作符，则只需匹配键和效应，无需匹配值。
    3. Pod可以具有多个容忍度，以匹配节点上的多个污点。

    4.操作实例

    5.设置容忍时间

    • 污点容忍时间，主要涉及的是当节点被设置了NoExecute类型的污点时，Pod如果没有相应的容忍度，则会被驱逐出该节点。然而，如果Pod具有对应的容忍度，并且容忍度中设置了tolerationSeconds字段，那么Pod在被驱逐前还可以在节点上继续运行一段时间。tolerationSeconds字段指定了Pod在节点上可以继续运行的时间（单位为秒），这相当于给Pod一个宽限期，让其有时间完成必要的清理工作或等待其他操作完成。

    讯享网

    6.污点驱逐

    边我们提到了污点的effect可以设置为 NoExecute，它会影响节点上已经运行的pod，如下所示：

    • 立即将没有配置容忍的pod逐出。
    • 设置容忍但是没有指定 tolerationSeconds 参数的，那么该容忍永久生效。
    • 设置容忍但是有指定 tolerationSeconds 参数的，那么在指定的时间内，容忍有效，超出指定时间后将被剔除。

    此外，当某些条件为true时，节点控制器会自动污染节点。也就是k8s的内置污点：

    • node.kubernetes.io/not-ready： 节点尚未准备好。这对应于NodeCondition Ready为false。
    • node.kubernetes.io/unreachable： 无法从节点控制器访问节点。这对应于NodeCondition Ready 为Unknown。
    • node.kubernetes.io/out-of-disk： 节点磁盘不足。
    • node.kubernetes.io/memory-pressure： 节点有内存压力。
    • node.kubernetes.io/disk-pressure： 节点有磁盘压力。
    • node.kubernetes.io/network-unavailable： 节点的网络不可用。
    • node.kubernetes.io/unschedulable： 节点不可调度。
    • node.cloudprovider.kubernetes.io/uninitialized： 当kubelet从 “外部” 云提供程序开始时，此污点在节点上设置为将其标记为不可用。来自cloud-controller-manager的控制器初始化此节点后，kubelet删除此污点。