K8S调度之节点亲和性

Node Affinity

Affinity 翻译成中文是“亲和性”,它对应的是 Anti-Affinity,我们翻译成“互斥”。这两个词比较形象,可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥,不同的是除了简单的正负极之外,pod 和 node 的吸引和互斥是可以灵活配置的。

Affinity的优点:

  • 匹配有更多的逻辑组合,不只是字符串的完全相等
  • 调度分成软策略(soft)和硬策略(hard),在软策略下,如果没有满足调度条件的节点,pod会忽略这条规则,继续完成调度。

目前主要的node affinity:

  • requiredDuringSchedulingIgnoredDuringExecution

    表示pod必须部署到满足条件的节点上,如果没有满足条件的节点,就不停重试。其中IgnoreDuringExecution表示pod部署之后运行的时候,如果节点标签发生了变化,不再满足pod指定的条件,pod也会继续运行。

  • requiredDuringSchedulingRequiredDuringExecution

    表示pod必须部署到满足条件的节点上,如果没有满足条件的节点,就不停重试。其中RequiredDuringExecution表示pod部署之后运行的时候,如果节点标签发生了变化,不再满足pod指定的条件,则重新选择符合要求的节点。

  • preferredDuringSchedulingIgnoredDuringExecution

    表示优先部署到满足条件的节点上,如果没有满足条件的节点,就忽略这些条件,按照正常逻辑部署。

  • preferredDuringSchedulingRequiredDuringExecution

    表示优先部署到满足条件的节点上,如果没有满足条件的节点,就忽略这些条件,按照正常逻辑部署。其中RequiredDuringExecution表示如果后面节点标签发生了变化,满足了条件,则重新调度到满足条件的节点。

软策略和硬策略的区分是有用处的,硬策略适用于 pod 必须运行在某种节点,否则会出现问题的情况,比如集群中节点的架构不同,而运行的服务必须依赖某种架构提供的功能;软策略不同,它适用于满不满足条件都能工作,但是满足条件更好的情况,比如服务最好运行在某个区域,减少网络传输等。这种区分是用户的具体需求决定的,并没有绝对的技术依赖。

下面是一个官方的示例:

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: gcr.io/google_containers/pause:2.0

这个 pod 同时定义了 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution 两种 nodeAffinity。第一个要求 pod 运行在特定 AZ 的节点上,第二个希望节点最好有对应的 another-node-label-key:another-node-label-value 标签。

这里的匹配逻辑是label在某个列表中,可选的操作符有:

  • In: label的值在某个列表中
  • NotIn:label的值不在某个列表中
  • Exists:某个label存在
  • DoesNotExist:某个label不存在
  • Gt:label的值大于某个值(字符串比较)
  • Lt:label的值小于某个值(字符串比较)

如果nodeAffinity中nodeSelector有多个选项,节点满足任何一个条件即可;如果matchExpressions有多个选项,则节点必须同时满足这些选项才能运行pod 。

需要说明的是,node并没有anti-affinity这种东西,因为NotIn和DoesNotExist能提供类似的功能。

原文地址:https://www.cnblogs.com/breezey/p/9101666.html

时间: 2024-11-01 09:26:52

K8S调度之节点亲和性的相关文章

K8S调度之pod亲和性

[toc] Pod Affinity 通过<K8S调度之节点亲和性>,我们知道怎么在调度的时候让pod灵活的选择node,但有些时候我们希望调度能够考虑pod之间的关系,而不只是pod与node的关系.于是在kubernetes 1.4的时候引入了pod affinity. 为什么有这样的需求呢?举个例子,我们系统服务 A 和服务 B 尽量部署在同个主机.机房.城市,因为它们网络沟通比较多:再比如,我们系统数据服务 C 和数据服务 D 尽量分开,因为如果它们分配到一起,然后主机或者机房出了问题

7.k8s.调度器scheduler 亲和性、污点

#k8s. 调度器scheduler 亲和性.污点 默认调度过程:预选 Predicates (过滤节点) --> 优选 Priorities(优先级排序) --> 优先级最高节点 实际使用,根据需求控制Pod调度,需要用到如下: 指定节点.nodeAffinity(节点亲和性).podAffinity(pod 亲和性). podAntiAffinity(pod 反亲和性) #指定调度节点 # Pod.spec.nodeName 强制匹配,直接指定Node 节点,跳过 Scheduler 调度

k8s调度器之亲和性和反亲和性/节点选择器

容器在节点(物理机)上是如何部署的 是由调度器scheduler进行调度的 调度策略 随机 通过节点选择器选择某些节点 通过节点亲和性和pod的亲和性及反亲和性实现更细粒度的控制 参考 https://www.jianshu.com/p/61725f179223 https://blog.csdn.net/qq_39295735/article/details/88565425 https://www.cnblogs.com/tylerzhou/p/11023188.html 原文地址:http

K8S调度之标签选择器

Kubernetes 调度简介 除了让 kubernetes 集群调度器自动为 pod 资源选择某个节点(默认调度考虑的是资源足够,并且 load 尽量平均),有些情况我们希望能更多地控制 pod 应该如何调度.比如,集群中有些机器的配置更好( SSD,更好的内存等),我们希望比较核心的服务(比如说数据库)运行在上面:或者某两个服务的网络传输很频繁,我们希望它们最好在同一台机器上,或者同一个机房.有一些特殊的应用,我们就希望它们能运行在我们指定的节点上,还有些情况下,我们希望某个应用在所有的节点

从零开始入门 K8s | 调度器的调度流程和算法介绍

导读:Kubernetes 作为当下最流行的容器自动化运维平台,以声明式实现了灵活的容器编排,本文以 v1.16 版本为基础详细介绍了 K8s 的基本调度框架.流程,以及主要的过滤器.Score 算法实现等,并介绍了两种方式用于实现自定义调度能力. 调度流程 调度流程概览 Kubernetes 作为当下最主流的容器自动化运维平台,作为 K8s 的容器编排的核心组件 kube-scheduler 将是我今天介绍的主角,如下介绍的版本都是以 release-1.16 为基础,下图是 kube-sch

k8s部署---node节点组件部署(四)

kubelet组件简介 kubernetes 是一个分布式的集群管理系统,在每个节点(node)上都要运行一个 worker 对容器进行生命周期的管理,这个 worker 程序就是 kubelet kubelet 的主要功能就是定时从某个地方获取节点上 pod/container 的期望状态(运行什么容器.运行的副本数量.网络或者存储如何配置等等),并调用对应的容器平台接口达到这个状态. kubelet组件特性 定时汇报当前节点的状态给 apiserver,以供调度的时候使用 镜像和容器的清理工

k8s中node节点资源不足

节点资源耗尽状态 1.查看节点组件的状态 2.查看节点上pod的状态 查看日志内容发现如下内容: 1.Node emay-CMPP01 status is now: NodeHasDiskPressure 2.Warning: "EvictionThresholdMet Attempting to reclaim nodefs" 从以上内容大致可以判断出node3处于磁盘空间不足的状态下,并且该node上的kubelet daemon判断达到了Eviction阀值,试图回收磁盘空间(通

k8s调度器优先级和抢占机制

优先级(Priority)和抢占(Preemption)机制 优先级和抢占机制,解决的是Pod调度失败时该怎么办的问题 正常情况下,当一个Pod调度失败后,它就会被暂时“搁置”起来,直到Pod被更新,或者集群状态发生变化,调度器才会对这个Pod进行重新调度 特殊要求的场景: 当一个高优先级的Pod调度失败后,该Pod并不会被“搁置”,而是会“挤走”某个Node上的一些低优先级的Pod.这样就保证这个高优先级Pod的调度成功 优先级的实现 需要在Kubernetes里提交一个PriorityCla

K8s完整单节点二进制部署(实战必备!)

搭建步骤: 1:自签ETCD证书 2:ETCD部署 3:Node安装docker 4:Flannel部署(先写入子网到etcd)---------master----------5:自签APIServer证书 6:部署APIServer组件(token,csv)7:部署controller-manager(指定apiserver证书)和scheduler组件----------node----------8:生成kubeconfig(bootstrap,kubeconfig和kube-proxy