K8S调度之pod亲和性

[toc]

Pod Affinity

通过《K8S调度之节点亲和性》,我们知道怎么在调度的时候让pod灵活的选择node,但有些时候我们希望调度能够考虑pod之间的关系,而不只是pod与node的关系。于是在kubernetes 1.4的时候引入了pod affinity。

为什么有这样的需求呢?举个例子,我们系统服务 A 和服务 B 尽量部署在同个主机、机房、城市,因为它们网络沟通比较多;再比如,我们系统数据服务 C 和数据服务 D 尽量分开,因为如果它们分配到一起,然后主机或者机房出了问题,会导致应用完全不可用,如果它们是分开的,应用虽然有影响,但还是可用的。

pod affinity 可以这样理解:调度的时候选择(或者不选择)这样的节点 N ,这些节点上已经运行了满足条件 X。条件 X 是一组 label 选择器,它必须指明作用的 namespace(也可以作用于所有的 namespace),因为 pod 是运行在某个 namespace 中的。

这里的X指的是集群中的节点、机架、区域等概念,通过kubernetes内置节点标签中的key来进行声明。这个key的名字为topologyKey,意为表达节点所属的topology范围:

  • kubernetes.io/hostname
  • failure-domain.beta.kubernetes.io/zone
  • failure-domain.beta.kubernetes.io/region

和 node affinity 相似,pod affinity 也有 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution,意义也和之前一样。如果有使用亲和性,在 affinity 下面添加 podAffinity 字段,如果要使用互斥性,在 affinity 下面添加 podAntiAffinity 字段。

先定义一个参照目标pod:

apiVersion: v1
kind: Pod
metadata:
  name: pod-flag
  labels:
    security: "S1"
    app: "nginx"
spec:
  containers:
  - name: nginx
    image: nginx

Pod亲和性调度

下面是一个亲和性调度的示例

apiVersion: v1
kind: Pod
metadata:
  name: pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: gcr.io/google_containers/pause:2.0

创建后可以看到这个pod与上面那个参照的pod位于同一个node上,另外,如果将这个node上的kubernetes.io/hostname标签干掉,将会发现pod会一直处于pending状态,这是因为找不到满足条件的node了。

pod互斥性调度

下面是一个互斥性调度的示例:

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: "failure-domain.beta.kubernetes.io/zone"
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: gcr.io/google_containers/pause:2.0

这个例子要求这个新pod与security=S1的pod为同一个zone,但是不与security=S2的pod为同一个node。

原则上,topologyKey可以使用任何合法的标签Key赋值,但是出于性能和安全方面的考虑,对topologyKey有如下限制:

  • 在pod亲和性和RequiredDuringScheduling的pod互斥性的定义中,不允许使用空的topologyKey
  • 如果admission controller包含了LimitPodHardAntiAffinityTopology,那么针对RequiredDuringScheduling的pod互斥性定义就被限制为kubernetes.io/hostname,要使用自定义的topologyKey,就要改写或禁用该控制器
  • 在PerferredDuringScheduling类型的Pod互斥性定义中,空的topologyKey会被解释为kubernetes.io/hostname、failure-domain.beta.kubernetes.io/zone及failure-domain.beta.kubernetes.io/region的组合

podAffinity规则设置的注意事项:

  • 在labelSelector和topologyKey同级,还可以定义namespaces列表,表示匹配哪些namespace里面的pod,默认情况下,会匹配定义的pod所在的namespace,如果定义了这个字段,但是它的值为空,则匹配所有的namespaces。
  • 所有关联requiredDuringSchedulingIgnoredDuringExecution的matchExpressions全都满足之后,系统才能将pod调度到某个node上。

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

时间: 2024-10-09 10:54:19

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

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

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

K8S调度之节点亲和性

Node Affinity Affinity 翻译成中文是"亲和性",它对应的是 Anti-Affinity,我们翻译成"互斥".这两个词比较形象,可以把 pod 选择 node 的过程类比成磁铁的吸引和互斥,不同的是除了简单的正负极之外,pod 和 node 的吸引和互斥是可以灵活配置的. Affinity的优点: 匹配有更多的逻辑组合,不只是字符串的完全相等 调度分成软策略(soft)和硬策略(hard),在软策略下,如果没有满足调度条件的节点,pod会忽略这条

k8s学习 - 概念 - Pod

k8s学习 - 概念 - Pod 这篇继续看概念,主要是 Pod 这个概念,这个概念非常重要,是 k8s 集群的最小单位. 怎么才算是理解好 pod 了呢,基本上把 pod 的所有 describe 和配置文件的配置项都能看懂就算是对 pod 比较了解了. Pod 我们通过调用一个kubectl describe pod xxx 可以查看某个 pod 的具体信息. describe 的信息我们用注释的形式来解读. Name: task-pv-pod Namespace: default // 没

K8S调度之标签选择器

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

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

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

从零开始入门 K8s| 详解 Pod 及容器设计模式

作者|张磊 阿里云容器平台高级技术专家,CNCF 官方大使 一.为什么需要 Pod 容器的基本概念 我们知道 Pod 是 Kubernetes 项目里面一个非常重要的概念,也是非常重要的一个原子调度单位,但是为什么我们会需要这样一个概念呢?在使用容器 Docker 的时候,也没有这个说法.其实,如果想要理解 Pod,首先要理解容器,所以来回顾一下容器的概念: 容器的本质实际上是一个进程,是一个视图被隔离,资源受限的进程. 容器里面 PID=1 的进程就是应用本身,这意味着管理虚拟机等于管理基础设

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

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

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中的pod控制器之Deployment、DaemonSet、StatefulSet

pod控制器分类:1.ReplicationController2.ReplicaSet3.Deployment4.StatefulSet5.DaemonSet6.Job,Cronjob7.HPApod控制器:一般包括3部分1.标签选择器2.期望的副本数(DaemonSet控制器不需要)3.pod模板deploy控制器构建于rs控制器之上,新特性包括:1.事件和状态查看2.回滚3.版本记录4.暂停和启动5.支持两种自动更新方案Recreate删除重建RollingUpdate回滚升级(默认方式)