摘要:换句话说,亲和性选择节点仅在调度时起作用。先创建集群反亲和性打散各个副本再部署服务,需要打散并且与服务共存,配置如下注意需要进行大量处理,所以会明显减慢大型集群的调度时间,不建议在大于几百个节点的集群中使用该功能。
一、概述
前一篇文章 Kubernetes 调度器浅析,大致讲述了调度器的工作原理及相关调度策略。这一章会继续深入调度器,介绍下“亲和性调度”。
Kubernetes 支持限制 Pod 在指定的 Node 上运行,或者指定更倾向于在某些特定 Node 上运行。
有几种方式可以实现这个功能:
NodeName: 最简单的节点选择方式,直接指定节点,跳过调度器。
NodeSelector: 早期的简单控制方式,直接通过键—值对将 Pod 调度到具有特定 label 的 Node 上。
NodeAffinity: NodeSelector 的升级版,支持更丰富的配置规则,使用更灵活。(NodeSelector 将被淘汰.)
PodAffinity: 根据已在节点上运行的 Pod 标签来约束 Pod 可以调度到哪些节点,而不是根据 node label。
二、NodeNamenodeName 是 PodSpec 的一个字段,用于直接指定调度节点,并运行该 pod。调度器在工作时,实际选择的是 nodeName 为空的 pod 并进行调度然后再回填该 nodeName,所以直接指定 nodeName 实际是直接跳过了调度器。换句话说,指定 nodeName 的方式是优于其他节点选择方法。
方法很简单,直接来个官方示例:
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx nodeName: kube-01
当然如果选择的节点不存在,或者资源不足,那该 pod 必然就会运行失败。
三、NodeSelectornodeSelector 也是 PodSpec 中的一个字段,指定键—值对的映射。
如果想要将 pod 运行到对应的 node 上,需要先给这些 node 打上 label,然后在 podSpec.NodeSelector 指定对应 node labels 即可。
步骤如下:
设置标签到 node 上:
kubectl label nodes kubernetes-node type=gpu
pod 配置添加 nodeSelector 字段:
apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx nodeSelector: type: gpu内置 Node 标签
Kubernetes 内置了一些节点标签:
kubernetes.io/hostname
beta.kubernetes.io/instance-type
beta.kubernetes.io/os
beta.kubernetes.io/arch
failure-domain.beta.kubernetes.io/zone
failure-domain.beta.kubernetes.io/region
有些标签是对云提供商使用。
还有些表示 node role 的 labels(可以指定 master、lb 等):
kubernetes.io/role
node-role.kubernetes.io
四、NodeAffinitynodeSelector 通过 k-v 的方式非常简单的支持了 pod 调度限制到具有特定标签的节点上。而 nodeAffinity 根据亲和力 & 反亲和力极大地扩展了能够表达的约束信息。
nodeAffinity 特性的设计初衷就是为了替代 nodeSelector。
nodeAffinity 当前支持的匹配符号包括:In、NotIn、Exists、DoesNotExists、Gt、Lt 。
nodeAffinity 当前支持两种调度模式:
requiredDuringSchedulingIgnoredDuringExecution: 一定要满足的条件,如果没有找到满足条件的节点,则 Pod 创建失败。所有也称为hard 模式。
preferredDuringSchedulingIgnoredDuringExecution: 优先选择满足条件的节点,如果没有找到满足条件的节点,则在其他节点中择优创建 Pod。所有也称为 soft 模式。
两种模式的名字特长,这是 k8s 的命名风格。其中IgnoredDuringExecution的意义就跟 nodeSelector 的实现一样,即使 node label 发生变更,也不会影响之前已经部署且又不满足 affinity rules 的 pods,这些 pods 还会继续在该 node 上运行。换句话说,亲和性选择节点仅在调度 Pod 时起作用。
k8s 社区正在计划提供 requiredDuringSchedulingRequiredDuringExecution 模式,便于驱逐 node 上不满足 affinity rules 的 pods。
来个官方示例,看下怎么玩:
apiVersion: v1 kind: Pod metadata: name: with-node-affinity spec: affinity: nodeAffinity: # 必须选择 node label key 为 kubernetes.io/e2e-az-name, # value 为 e2e-az1 或 e2e-az2. requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 - e2e-az2 # 过滤掉上面的必选项后,再优先选择 node label key 为 another-node-label-key # value 为 another-node-label-value. preferredDuringSchedulingIgnoredDuringExecution: # 如果满足节点亲和,积分加权重(优选算法,会对 nodes 打分) # weight: 0 - 100 - 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
简单看下 NodeAffinity 的结构体,下面介绍注意事项时会涉及:
type NodeAffinity struct { RequiredDuringSchedulingIgnoredDuringExecution *NodeSelector PreferredDuringSchedulingIgnoredDuringExecution []PreferredSchedulingTerm } type NodeSelector struct { NodeSelectorTerms []NodeSelectorTerm } type NodeSelectorTerm struct { MatchExpressions []NodeSelectorRequirement MatchFields []NodeSelectorRequirement }
配置相关的注意点:
如果 nodeSelector 和 nodeAffinity 两者都指定,那 node 需要两个条件都满足,pod 才能调度。
如果指定了多个 NodeSelectorTerms,那 node 只要满足其中一个条件,pod 就可以进行调度。
如果指定了多个 MatchExpressions,那必须要满足所有条件,才能将 pod 调度到该 node。
五、PodAffinitynodeSelector & nodeAffinity 都是基于 node label 进行调度。而有时候我们希望调度的时候能考虑 pod 之间的关系,而不只是 pod 和 node 的关系。
举个例子,会有需求希望服务 A 和 B 部署在同一个机房、机架或机器上,因为这些服务可能会对网路延迟比较敏感,需要低延时;再比如,希望服务 C 和 D 又希望尽量分开部署,即使一台主机甚至一个机房出了问题,也不会导致两个服务一起挂而影响服务可用性,提升故障容灾的能力。
podAffinity 会基于节点上已经运行的 pod label 来约束新 pod 的调度。
其规则就是“如果 X 已经运行了一个或者多个符合规则 Y 的 Pod,那么这个 Pod 应该(如果是反亲和性,则是不应该)调度到 X 上”。
这里的 Y 是关联 namespace 的 labelSelector,当然 namespace 也可以是 all。和 node 不同,pod 是隶属于 namespace 下的资源,所以基于 pod labelSelector 必须指定具体的 namespace;而 X 则可以理解为一个拓扑域,类似于 node、rack、zone、cloud region 等等,就是前面提到的 内置 Node 标签 ,当然也可以自定义。
看下 pod affinity 涉及的结构体,便于进行功能介绍:
type Affinity struct { // NodeAffinity 前面介绍了 NodeAffinity *NodeAffinity // pod 亲和性 PodAffinity *PodAffinity // pod 反亲和性 PodAntiAffinity *PodAntiAffinity } type PodAffinity struct { // hard 模式, 必选项 RequiredDuringSchedulingIgnoredDuringExecution []PodAffinityTerm // soft 模式, 进行 node 优先 PreferredDuringSchedulingIgnoredDuringExecution []WeightedPodAffinityTerm } type PodAffinityTerm struct { LabelSelector *metav1.LabelSelector Namespaces []string TopologyKey string } type WeightedPodAffinityTerm struct { Weight int32 PodAffinityTerm PodAffinityTerm }
podAffinity 和 nodeAffinity 有相似的地方,使用了 labelSelector 进行匹配,支持的匹配符号包括:In、NotIn、Exists、DoesNotExists;
也支持两种调度模式 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution, 功能和 nodeAffinity 一样,这里就不在累述。
podAffinity 和 nodeAffinity 也有较大的差异,前面讲了 pod 是 namespace 资源,所以必然会需要配置 namespaces,支持配置多个 namespace。如果省略的话,默认为待调度 pod 所属的 namespace;如果定义了但是值为空,则表示使用 “all” namespaces。
还有一个较大的差别 TopologyKey, 便于理解进行多带带介绍。
TopologyKeyTopologyKey 用于定义 in the same place,前面也介绍了是拓扑域的概念。
看下面的图,这两个 pod 到底该如何算在一个拓扑域?
如果我们使用k8s.io/hostname,in the same place 则意味着在同一个 node,那下图的 pods 就不在一个 place:
如果我们使用failure-domain.k8s.io/zone 来表示一个 place,那下图的 pods 就表示在一个 zone:
当然我们也可以自定义 node labels 作为 TopologyKey。比如我们可以给一组 node 打上 rack 标签,那下图的 pods 表示在同一个 place:
原则上,topologyKey 可以是任何合法的 label key。但是出于性能和安全考虑,topologyKey 存在一些限制:
对于亲和性和反亲和性的 requiredDuringSchedulingIgnoredDuringExecution 模式,topologyKey 不能为空
pod 反亲和性 requiredDuringSchedulingIgnoredDuringExecution 模式下,LimitPodHardAntiAffinityTopology 权限控制器会限制 topologyKey 只能设置为 kubernetes.io/hostname。当然如果你想要使用自定义 topology,那可以简单禁用即可。
pod 反亲和性 preferredDuringSchedulingIgnoredDuringExecution 模式下,topologyKey 为空则表示所有的拓扑域。截止 v1.12 版本,所有的拓扑域还只能是 kubernetes.io/hostname, failure-domain.beta.kubernetes.io/zone 和 failure-domain.beta.kubernetes.io/region 的组合。
除此之外,topologyKey 可以是任何合法的 label key。
示例来个官方示例,有三节点集群,需要分别部署 3 份 web 和 redis 服务。希望 web 与 redis 服务共存,但需要保证各个服务的副本分散部署。
先创建 redis 集群:
apiVersion: apps/v1 kind: Deployment metadata: name: redis-cache spec: selector: matchLabels: app: store replicas: 3 template: metadata: labels: app: store spec: affinity: // pod 反亲和性, 打散 redis 各个副本 podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "kubernetes.io/hostname" containers: - name: redis-server image: redis:3.2-alpine
再部署 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
注意1: pod affinity 需要进行大量处理,所以会明显减慢大型集群的调度时间,不建议在大于几百个节点的集群中使用该功能。六、参考资料 官方
注意2: pod antiAffinity 要求对节点进行一致标志,即集群中的所有节点都必须具有适当的标签用于配置给 topologyKey,如果节点缺少指定的 topologyKey 指定的标签,则可能会导致意外行为。
Assigning Pods to Nodes - Kubernetes
node affinity
pod affinity
性能优化: Improve performance of affinity/anti-affinity predicate by 20x in large clusters by bsalamat
blogK8S 的调度 (一) 抽象优雅的 Affinity
Scheduling in Kubernetes, Part 2: Pod Affinity – Koki – Medium
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/32907.html
摘要:的调度机制组件调度器会将调度到资源满足要求并且评分最高的上。这个特性的设计初衷是为了替代,并扩展更强大的调度策略。和完全相同,以进行强制的约束。软规则除了,,还有一条软规则配置后,没有相关污点策略的会尽量避免调度到该上。 k8s的调度机制 scheduler组件 k8s调度器会将pod调度到资源满足要求并且评分最高的node上。我们可以使用多种规则比如:1.设置cpu、内存的使用要求;...
摘要:下面通过该文章来简述的基础信息并详述的生命周期。声明周期钩子函数为容器提供了两种生命周期钩子于容器创建完成之后立即运行的钩子程序。向容器指定发起请求,响应码为或者是为成功,否则失败。 简述 Kubernetes 是一种用于在一组主机上运行和协同容器化应用程序的系统,提供应用部署、规划、更新维护的机制。应用运行在 kubernetes 集群之上,实现服务的扩容、缩容,执行滚动更新以及在不...
摘要:与已运行相关的过滤规则负责检查待调度与上已有之间的亲和性关系。并且每个打分函数都可以配置对应的权重值,下面介绍调度器策略配置时,也会涉及权重值的配置。默认权重值是,如果觉得某个打分函数特别重要,便可以加大该权重值。 一、概述 Kubernetes 是 Google 开源的容器集群管理系统(谷歌内部:Borg),而今天要介绍的 kube-scheduler 是 k8s 系统的核心组件之一...
摘要:作为一个开源的分布式数据库产品,具有多副本强一致性的同时能够根据业务需求非常方便的进行弹性伸缩,并且扩缩容期间对上层业务无感知。另外本身维护了数据多副本,这点和分布式文件系统的多副本是有重复的。 作者:邓栓来源:细说云计算 作为一款定位在 Cloud-native 的数据库,现如今 TiDB 在云整合上已取得了阶段性的进展。日前 Cloud TiDB 产品在 UCloud 平台正式开启...
摘要:在这种情况下,以防干扰其他集群租户,调度器可能会考虑将作为驱逐的候选对象。其结果是负载均衡和调度之间交互作用。 每当谈及Kubernetes,我们经常听到诸如资源管理、调度和负载均衡等术语。虽然Kubernetes提供了许多功能,但更关键的还是要了解这些概念,只有这样才能更好地理解如何放置、管理并恢复工作负载。在这篇文章中,我提供了每个功能的概述,并解释了它们是如何在Kubernete...
阅读 857·2021-10-27 14:19
阅读 1085·2021-10-15 09:42
阅读 1492·2021-09-14 18:02
阅读 722·2019-08-30 13:09
阅读 2970·2019-08-29 15:08
阅读 2063·2019-08-28 18:05
阅读 929·2019-08-26 10:25
阅读 2758·2019-08-23 16:28