全栈工程师开发手册（作者：栾鹏）
架构系列文章

nodeSelector

1.分配pod到node的方法

通过node label selector实现约束pod运行到指定节点,有两种方法 nodeSelector 以及affinity

2.nodeSelector 是k8s早起提供的节点选择器实现

1）首先为nodes打对应的label
kubectl label nodes master disktype=ssd
2)创建yaml文件，nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:name: nginxlabels:env: test
spec:containers:- name: nginximage: nginx

创建pod

kubectl create -f nginx-pod.yaml
节点默认的label
kubectl get nodes -o yaml 可以看到默认节点的label,也可以使用这些label进行约束

alpha.kubernetes.io/fluentd-ds-ready: "true"
beta.kubernetes.io/arch: amd64
beta.kubernetes.io/os: linux
disktype: ssd
kubeadm.alpha.kubernetes.io/role: master
kubernetes.io/hostname: master

亲和性和反亲和性

根据类型有

nodeAffinity（主机亲和性），
podAffinity（POD亲和性）
podAntiAffinity（POD反亲和性）。

三种亲和性和反亲和性策略的比较如下表所示：

策略名称	匹配目标	支持的操作符	支持拓扑域	设计目标
nodeAffinity	主机标签	In，NotIn，Exists，DoesNotExist，Gt，Lt	不支持	决定Pod可以部署在哪些主机上
podAffinity	Pod标签	In，NotIn，Exists，DoesNotExist	支持	决定Pod可以和哪些Pod部署在同一拓扑域
PodAntiAffinity	Pod标签	In，NotIn，Exists，DoesNotExist	支持	决定Pod不可以和哪些Pod部署在同一拓扑域

对于亲和性和反亲和性，每种都有三种规则可以设置：

RequiredDuringSchedulingRequiredDuringExecution ：在调度期间要求满足亲和性或者反亲和性规则，如果不能满足规则，则POD不能被调度到对应的主机上。在之后的运行过程中，如果因为某些原因（比如修改label）导致规则不能满足，系统会尝试把POD从主机上删除（现在版本还不支持）。

RequiredDuringSchedulingIgnoredDuringExecution ：在调度期间要求满足亲和性或者反亲和性规则，如果不能满足规则，则POD不能被调度到对应的主机上。在之后的运行过程中，系统不会再检查这些规则是否满足。

PreferredDuringSchedulingIgnoredDuringExecution ：在调度期间尽量满足亲和性或者反亲和性规则，如果不能满足规则，POD也有可能被调度到对应的主机上。在之后的运行过程中，系统不会再检查这些规则是否满足。

使用场景介绍

nodeAffinity使用场景：

将S1服务的所有Pod部署到指定的符合标签规则的主机上。
将S1服务的所有Pod部署到除部分主机外的其他主机上。

podAffinity使用场景：

将某一特定服务的pod部署在同一拓扑域中，不用指定具体的拓扑域。
如果S1服务使用S2服务，为了减少它们之间的网络延迟（或其它原因），把S1服务的POD和S2服务的pod部署在同一拓扑域中。

podAntiAffinity使用场景：

将一个服务的POD分散在不同的主机或者拓扑域中，提高服务本身的稳定性。
给POD对于一个节点的独占访问权限来保证资源隔离，保证不会有其它pod来分享节点资源。
把可能会相互影响的服务的POD分散在不同的主机上。

NodeAffinity

参考：https://k8smeetup.github.io/docs/concepts/configuration/assign-pod-node/#node-%E4%BA%B2%E5%92%8C%E6%80%A7beta-%E7%89%B9%E6%80%A7

requiredDuringSchedulingIgnoredDuringExecution的示例

下面这个例子使用nodeAffinity把POD部署到主机mesos-slave1和mesos-slave2上面

apiVersion: v1
kind: Pod
metadata:name: with-node-affinityannotations:scheduler.alpha.kubernetes.io/affinity: >{"nodeAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": {"nodeSelectorTerms": [{"matchExpressions": [{"key": "kubernetes.io/hostname","operator": "In","values": [“mesos-slave1″,”mesos-slave2”]}]}]}}}another-annotation-key: another-annotation-value
spec:containers:- name: with-node-affinityimage: gcr.io/google_containers/pause:2.0

我们可以看到NodeSelectorTerms可以有多个，之间是或的关系，满足任意一个既满足，，MatchExpressions也可以有多个，他们之间是且的关系必须都满足。

preferredDuringSchedulingIgnoredDuringExecution 例子

apiVersion: v1
kind: Pod
metadata:name: with-labelsannotations:scheduler.alpha.kubernetes.io/affinity: >{"nodeAffinity": {"preferredDuringSchedulingIgnoredDuringExecution": [{"weight" : 1,"preference": {"matchExpressions": [{"key": "disktype","operator": "In","values": ["ssd"]}]}}]}}another-annotation-key: another-annotation-value
spec:containers:- name: test-affinityenv:- name: MYSQL_ROOT_PASSWORDvalue: passimage: mysql

preferredDuringSchedulingIgnoredDuringExecution值为列表，根据权重决定顺序
MatchExpressions 值为列表关系为且，必须都满足

Inter-pod affinity and anti-affinity

Inter-pod affinity 是根据通过已运行在节点上的pod的标签而不是node的标签来决定被调度pod的运行节点，因为pod运行在指定的namespace所以需要自己指定运行pod的namesapce

anti-affinity 和Inter-pod affinity相反

在下面这个例子中，定义了一个Pod亲和性和一个Pod反亲和性规则。其中Pod亲和性规则是一定要满足的，Pod反亲和性规则是参考满足的。

Pod亲和性规则的含义是：Pod必须部署在一个节点上，这个节点上至少有一个正在运行的Pod，这个Pod的security属性取值是“S1”，并且要求部署的节点同正在运行的Pod所在节点都在相同的云服务区域中，也就是“topologyKey:failure-domain.beta.kubernetes.io/zone”。换言之，一旦某个区域出了问题，我们希望这些 Pod 能够再次迁移到同一个区域。

Pod反亲和性规则的含义是，Pod不能部署在一个节点上，这个节点上正在运行的Pod中security属性取值是“S2”，并且新部署的Pod不能同security属性取值是“S2”的Pod在相同的主机上，也就是“topologyKey: kubernetes.io/hostname”。

matchExpressions中operator的取值包括In、NotIn、Exists、DoesNotExist、Gt和Lt。

DoesNotExist实现反亲密的示例

 affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: erroroperator: DoesNotExist

topologyKey的取值包括：

  kubernetes.io/hostname       同一个主机

  failure-domain.beta.kubernetes.io/zone      同一个云服务区

  failure-domain.beta.kubernetes.io/region    同一个区域

apiVersion: v1
kind: Pod
metadata:name: with-pod-affinityannotations:scheduler.alpha.kubernetes.io/affinity: >{"podAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": [{"labelSelector": {"matchExpressions": [{"key": "security","operator": "In","values": ["S1"]}]},"topologyKey": "failure-domain.beta.kubernetes.io/zone"}]},"podAntiAffinity": {"requiredDuringSchedulingIgnoredDuringExecution": [{"labelSelector": {"matchExpressions": [{"key": "security","operator": "In","values": ["S2"]}]},"topologyKey": "kubernetes.io/hostname"}]}}
spec:containers:- name: with-pod-affinityimage: gcr.io/google_containers/pause:2.0

k8s nodeSelector和affinity相关推荐

微服务架构系列文章、精品教程
python工具 python相关工具使用技巧(pip) virtualenv虚拟独立python环境使用 Python下APScheduler的快速指南 python文件夹,文件监听工具(pyino ...
Kubernetes K8S节点选择(nodeName、nodeSelector、nodeAffinity、podAffinity、Taints以及Tolerations用法)
感谢以下文章的支持: 容器编排系统K8s之Pod Affinity - Linux-1874 - 博客园容器编排系统K8s之节点污点和pod容忍度 - Linux-1874 - 博客园 Kubern ...
K8S之HELM详细介绍
文章目录一.基本概念二. 组件架构三 .工作原理 3.1 .Chart install 3.2 .Chart update 3.3 .Chart Rollback 3.4.Chart处理依赖四 ...
k8s学习(二十) helm的基本使用
1.创建仓库查看仓库 [root@k8s-node1 test]# helm repo list NAME URL stable https://kubernetes-charts.storage. ...
K8S安装Jumpserver
目录一.Jumpserver介绍二.安装Jumpserver K8S安装Jumpserver 源码安装Jumpserver 一.Jumpserver介绍 JumpServer 是全球首款开源的堡垒 ...
玩K8S不得不会的HELM
一基本概念 helm 类似于Linux系统下的包管理器,如yum/apt等,可以方便快捷的将之前打包好的yaml文件快速部署进kubernetes内,方便管理维护. helm:一个命令行下客户端工具 ...
k8s 部署zookeeper-kafka集群 —— 筑梦之路
规划:三个zookeeper 三个kafka添加亲和性规则#直接上yaml#zookeeper-deploy.yamlapiVersion: apps/v1 kind: StatefulSet met ...
资源调度(nodeSelector、nodeAffinity、taint、tolrations)
资源调度 Kubernetes中的调度策略主要分为全局调度与运行时调度2种.其中全局调度策略在调度器启动时配置,而运行时调度策略主要包括选择节点(nodeSelector),节点亲和性(nodeAff ...
一篇文章搞定大规模容器平台生产落地十大实践
Kubernetes已经成为企业容器平台的标配,在大部分企业,小规模容器平台已经试用了一段时间,然而当容器平台规模大了之后,尤其是用于生产,可能会遇到各种各样的问题,这里我们总结十大问题. 第零节,K ...

k8s nodeSelector和affinity