系列目录

部署pod时,大多数情况下kubernetes的调度程序能将pod调度到集群中合适的节点上。但有些情况下用户需要对pod调度到哪个节点上施加更多控制,比如将特定pod部署到拥有SSD存储节点、将同一个服务的多个后端部署在不同的机器上提高安全性、将通信频繁的服务部署在同一个可用区域降低通信链路长度。用户对pod部署的节点施加控制都与"label selector"有关。

nodeSelector(节点选择器)

nodeSelector也是标签选择器,是最简单、最直接控制pod部署node的方法,在daemonset用nodeSelector过滤可部署节点,以下是其普通的应用示例。

步骤1:为节点添加标签

  • kubectl get nodes,返回集群中所有node。

  • kubectl node label =,为node选定的node添加标签。如kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd

  • 为pod configuration添加节点选择器:

apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd

当运行kubectl create -f https://k8s.io/examples/pods/pod-nginx.yaml命令创建pod时,节点选择器选中有上述节点,如果没有符合条件的node则调度失败,为pod输出调度失败事件并指明失败原因。pod一直处于pending状态,直到找到合适的节点。

运行kubectl get pods -o wide查看调度程序为pod选定的节点。

Interlude: built-in node labels(插曲:内置节点标签)

上例中使用用户自定义标签,也可以使用系统自动生成的内置节点标签。不同kubernetes版本、不同的基础设备供应商,默认添加的内置节点标签可能不同,需查询相关文档确认,以下是kubernetes1.4的内置节点标签:

  • kubernetes.io/hostname
  • failure-domain.beta.kubernetes.io/zone
  • failure-domain.beta.kubernetes.io/region
  • beta.kubernetes.io/instance-type
  • beta.kubernetes.io/os
  • beta.kubernetes.io/arch

亲和与反亲和(Affinity and anti-affinity)

nodeSelector只能基于节点标签控制pod部署node,并且选择器只支持“与”逻辑操作。亲和与反亲和特性目前处于测试阶段,相比于节点选择器,其更灵活,功能更强大,体现在以下三点:

  1. 不仅仅是“与”,支持更多的逻辑表达式。

  2. nodeSelector是硬性要求,亲和与反亲和支持软硬两种要求。

  3. 除了节点标签,亲和与反亲和支持根据节点上已经部署的pod进行节点选择,这一点很重要。比如不想将两种计算密集类型的pod部署在同一节点上,后部署pod可选择过滤。

细分成两种类型的选择器:"节点亲和"与"内部pod亲和、反亲和"。节点亲和与nodeSelector相似,具备上述1、2两条优点。内部pod亲和依赖的是节点上已有pod的标签而不是节点标签,兼俱上述三个优点。因为节点亲和能完成nodeSelector所工作并且具备额外的优点,因此nodeSelector虽然还能用,但已经不再维护,并且将来可能删除。

节点亲和(测试特性)

节点亲和与nodeSelector工作原理相同,都是其于node标签选择节点。有两点不同,第一是节点亲和支持软硬两种节点选择requiredDuringSchedulingIgnoredDuringExecution、preferredDuringSchedulingIgnoredDuringExecution。前者是硬性条件必需满足,后者是软性条件,属于偏好部署。第二点是在选择节点时,节点亲和比nodeSelector支持更多更灵活的表达式,示例如下:

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: k8s.gcr.io/pause:2.0

符合条件的节点必需满足requiredDuringSchedulingIgnoredDuringExecution的条件,在此基础上,如果有节点满足

preferredDuringSchedulingIgnoredDuringExecution的条件,则更倾向部署在后者上。查询表达式中可以使用的操作符有:

In, NotIn, Exists, DoesNotExist, Gt, Lt等。

在requiredDuringSchedulingIgnoredDuringExecution中的matchExpressions可以包含多条选择表达式,相互之间是"逻辑与"的关系,必需同时满足。preferredDuringSchedulingIgnoredDuringExecution中的matchExpressions也可以有多条,因为它是软性条件,因为并非一定要全匹配,匹配的条目越多越符合条件。另外还可以为偏好中的表达式赋予不同的权重weight,可取的值在0-100之间,最后通过计算权重和决定那个节点更符合条件。

如果同时使用了nodeSelector与nodeAffinity,那么目标节点必需同时满足这两个选择器。

内部pod亲和与反亲和(测试特性)

内部pod亲和与反亲和特性由kubernetes1.4版本初次引入,其基于节点上已部署pod的标签计算亲和与反亲和,如实现将两种通信频繁pod部署在相同节点,将两种计算密集型pod部署在不同节点等。

提示:实现内部亲和与反亲和需要数量可观的计算步骤,会明显降低pod调度的速度,集群规模越大、节点越多降速越明显,呈指数级增长,需要在使用此特性时考虑对调度速度的影响。

在配置时,内部pod亲和用podAffinity字段表示,内部pod反亲和用podAntiAffinity字段表示,其它与节点亲和一样,也有软硬两种选择器,每种选择器可以多个过滤条件。

内部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: k8s.gcr.io/pause:2.0

上例中的topologyKey用来缩小节点选择范围,其值可以是任何合法的节点标签,在大规模集群中,为此字段不指定或者指定错误值,可能引发巨大的性能、安全问题。因此,对其使用有如下限制:

  • 对于亲和与硬性反亲和,topologyKey字段值不能为空。

  • 对于硬性反亲和,topoloygKey只能是kubernetes.io/hostname,除非禁止LimitPodHardAntiAffinityTopology允入控制器或者修改其实现。

  • 对于软件反亲和,允许topoloygKey为空,表示对节点拓扑没有限制。

  • 以上情况外,topologyKey可以是任何合法标签。

示例1:用反亲和特性实现pod位置协商

假设集群有五个工作节点,部署一个web应用,假设其用redis作内存缓存,共需要三个副本,通过反亲和将三个redis副本分别部署在三个不同的节点上,提高可用性,Deployment配置如下:

apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-cache
spec:
selector:
matchLabels:
app: store
replicas: 3
template:
metadata:
labels:
app: store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: redis-server
image: redis:3.2-alpine

反亲和会阻止同相的redis副本部署在同一节点上。

现在部署三个nginx web前端,要求三个副本不对分别部署在不同的节点上,通过与上列相似的反亲和实现。同时需要将三个web前端部署在其上已经部署redis的节点上,降低通信成本,通过亲和实现,配置如下:

apiVersion: apps/v1
kind: Deployment
metadata:
name: web-server
spec:
selector:
matchLabels:
app: web-store
replicas: 3
template:
metadata:
labels:
app: web-store
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-store
topologyKey: "kubernetes.io/hostname"
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- store
topologyKey: "kubernetes.io/hostname"
containers:
- name: web-app
image: nginx:1.12-alpine

参考

Kubernetes调度之亲和与反亲和的更多相关文章

  1. Centos7中kubernetes-1.11.2基于配置亲和与反亲和

    1.题目 通过命令行,创建两个个deployment. – 需要集群中有2个节点 – 第1个deployment名称为<hwcka-002-app1>,使用nginx镜像,用有2个pod, ...

  2. Kubernetes中的亲和性与反亲和性

    通常情况下,Pod分配到哪些Node是不需要管理员操心的,这个过程会由scheduler自动实现.但有时,我们需要指定一些调度的限制,例如某些应用应该跑在具有SSD存储的节点上,有些应用应该跑在同一个 ...

  3. kubernetes调度之pod优先级和资源抢占

    系列目录 Pod可以拥有优先级.优先意味着相对于其它pod某个pod更为重要.如果重要的pod不能被调度,则kubernetes调度器会优先于(驱离)低优先级的pod来让处于pending状态的高优先 ...

  4. 从零开始入门 K8s | Kubernetes 调度和资源管理

    作者 | 子誉  蚂蚁金服高级技术专家 关注"阿里巴巴云原生"公众号,回复关键词"入门",即可下载从零入门 K8s 系列文章 PPT. Kubernetes 调 ...

  5. 第18 章 : Kubernetes 调度和资源管理

    Kubernetes 调度和资源管理 这节课主要讲三部分的内容: Kubernetes 的调度过程: Kubernetes 的基础调度能力(资源调度.关系调度): Kubernetes 高级调度能力( ...

  6. kubernetes 调度

    pod 分配给特定的node节点 目的:在一般业务场景,有些pod需要运行在特定的物理节点上,可以通过kubernetes的nodeSelector.nodeName安排pod到指定的节点上运行. # ...

  7. kubernetes 调度器

    调度器 kube-scheduler 是 kubernetes 的核心组件之一,主要负责整个集群资源的调度功能,根据特定的调度算法和策略,将 Pod 调度到最优的工作节点上面去,从而更加合理.更加充分 ...

  8. kubernetes调度之污点(taint)和容忍(toleration)

    系列目录 节点亲和性(affinity),是节点的一种属性,让符合条件的pod亲附于它(倾向于或者硬性要求).污点是一种相反的行为,它会使pod抗拒此节点(即pod调度的时候不被调度到此节点) 污点和 ...

  9. 图解kubernetes调度器ScheduleAlgorithm核心实现学习框架设计

    ScheduleAlgorithm是一个接口负责为pod选择一个合适的node节点,本节主要解析如何实现一个可扩展.可配置的通用算法框架来实现通用调度,如何进行算法的统一注册和构建,如何进行metad ...

随机推荐

  1. BZOJ4819 [Sdoi2017]新生舞会 【01分数规划 + 费用流】

    题目 学校组织了一次新生舞会,Cathy作为经验丰富的老学姐,负责为同学们安排舞伴.有n个男生和n个女生参加舞会 买一个男生和一个女生一起跳舞,互为舞伴.Cathy收集了这些同学之间的关系,比如两个人 ...

  2. mod性质 学习笔记

    mod性质小结 \(a\equiv b(\mod m)\) $ \rightarrow \( \)a-b=k*m,k\in Z$ \(a\equiv b且c\equiv d(\mod m)\) \(\ ...

  3. 百万级日活 App 的屏幕录制功能是如何实现的

    Android 从 4.0 开始就提供了手机录屏方法,但是需要 root 权限,比较麻烦不容易实现.但是从 5.0 开始,系统提供给了 App 录制屏幕的一系列方法,不需要 root 权限,只需要用户 ...

  4. Solr5.2.1+Zookeeper3.4.9分布式集群搭建

    1.选取三台服务器 由于机器比较少,现将zookeeper和solr都部署在以下三台机器上.(以下操作都是在172.16.20.101主节点上进行的哦) 172.16.20.101 主节点 172.1 ...

  5. 通过OpenGL ES在iOS平台实践增强现实(二)

    上一篇讲到如何使用OpenGL ES绘制一个3D场景,这一篇我们会配合使用iOS提供的CoreMotion框架把虚拟世界中的摄像机的位置朝向和设备实际的位置朝向绑定起来.本文还对防抖做了处理. 首先说 ...

  6. 快充 IC BQ25896 如何判斷 手機插著 adapter 充電器時,adapter Iout 大於限制,adapter Vout 小於 限制,導致 battery 不但沒充電且還需放電。

    若電池在 放電時,ICHGR 為0. 若電池在 充電時,ICHGR有變化.   下面有寫到 charge current 所以不是 discharge current   狀況:           ...

  7. Linux 之 LNMP服务器搭建-PHP

    LNMP服务器搭建-PHP 参考教程:[千峰教育] 安装: (1)解压源码包 cd /lnmp/srctar -jxvf php-7.3.2.tar.bz2cd php-7.3.2 (2)配置选项 . ...

  8. git add 错误修改方法

    git add a.txt 报如下错误: fatal: Unable to create 'E:/git/.git/index.lock': File exists. Another git proc ...

  9. tableView刷新中的问题

    在开始之前先上一张效果图 相信大家都看到了“店铺优惠”这一栏,在这里假设这一栏就是单独的一个cell,当无店铺优惠的时候不可点击在有店铺优惠的时候会弹出优惠列表,选中并返回时会刷新数据,所以弹出视图采 ...

  10. TensorFlow——tensorflow指定CPU与GPU运算

    1.指定GPU运算 如果安装的是GPU版本,在运行的过程中TensorFlow能够自动检测.如果检测到GPU,TensorFlow会尽可能的利用找到的第一个GPU来执行操作. 如果机器上有超过一个可用 ...