前言
kubernetes中部署的pod默认根据资源使用情况自动调度到某个节点。可在实际项目的使用场景中都会有更细粒度的调度需求，比如：某些pod调度到指定主机、某几个相关的服务的pod最好调度到一个节点上、Master节点不允许某些pod调度等。使用kubernetes中的节点调度、节点亲和性、pod亲和性、污点与容忍可以灵活的完成pod调度，从而满足项目中较为复杂的调度需求。下面用一些项目中的使用场景聊聊pod调度使用法则。
原创作者：钟亮
pod调度主要包含以下内容
- nodeSelector
- nodeAffinity
- podAffinityz
- Taints
指定节点调度
kubectl get nodes #获取当前Kubernetes集群全部节点
NAME STATUS ROLES AGE VERSION
dev-10 Ready <none> 45d v1.8.6
dev-7 Ready master 45d v1.8.6
dev-8 Ready <none> 45d v1.8.6
dev-9 Ready <none> 45d v1.8.6
nodeName
通过主机名指定pod调度到指定节点
spec:
nodeName: dev-8 #设置要调度节点的名称
containers:
- image: nginx
imagePullPolicy: Always
name: my-nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
nodeSelector
kubernetes中常用label来管理集群的资源，nodeSelector可通过标签实现pod调度到指定节点上。
举列：使用nodeSelector将pod调度到dev-9节点上
step1：给dev-9打标签
kubectl label nodes dev-9 test=nginx #设置标签
kubectl get nodes --show-labels |grep test=nginx #查询标签是否设置成功
setp2：nodeSelector设置对应标签
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: my-nginx
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsPolicy: ClusterFirst
nodeSelector: #设置标签
test: nginx
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
terminationGracePeriodSeconds: 30
查询pod已经成功调度到dev-9节点
kcc get pods -o wide -n ns-team-1-env-1|grep my-nginx
my-nginx-556dcc8c5c-27f7k 1/1 Running 0 2m
10.244.2.238 dev-9
nodeAffinity
node 节点 Affinity ，从字面上很容易理解nodeAffinity就是节点亲和性，Anti-Affinity也就是反亲和性。节点亲和性就是控制pod是否调度到指定节点，相对nodeSelector来说更为灵活，可以实现一些简单的逻辑组合。
nodeAffinity策略
preferredDuringSchedulingIgnoredDuringExecution #软策略，尽量满足
requiredDuringSchedulingIgnoredDuringExecution #硬策略，必须满足
根据具体一些常用场景感受下
场景1：必须部署到有 test=nginx 标签的节点
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: test
operator: In
values:
- nginx
场景2：最好部署到有test=nginx 标签的节点
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: test
operator: In
values:
- nginx
场景3：不能部署在dev-7,dev-8节点；最好部署到有test=nginx标签的节点
spec:
containers:
- name: with-node-affinity
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: NotIn
values:
- dev-7
- dev-8
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: test
operator: In
values:
- nginx
通过以上场景可以看出使用节点亲和性可灵活的控制pod调度到节点，实现一些有逻辑组合的调度
Kubernetes中的operator提供了下面几种过滤条件:
- In：label 的值在某个列表中
- NotIn：label 的值不在某个列表中
- Gt：label 的值大于某个值
- Lt：label 的值小于某个值
- Exists：某个 label 存在
- DoesNotExist：某个 label 不存
podAffinity
nodeSelector和nodeAffinity 都是控制pod调度到节点的操作，在实际项目部署场景中，希望根据服务与服务之间的关系进行调度，也就是根据pod之间的关系进行调度，Kubernetes的podAffinity就可以实现这样的场景，podAffinity的调度策略和nodeAffinity类似也有：
requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution
场景：希望my-nginx服务my-busybox服务 最好部署在同一个节点上
my-nginx基本信息
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: my-nginx #标签 app = my-nginx
name: my-nginx
namespace: ns-team-1-env-1
...
...
my-busybox基本信息
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: my-busybox #标签 app = my-busybox
name: my-busybox
namespace: ns-team-1-env-1
...
...
在my-busybox设置pod亲和性
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-busybox
labels:
app: my-busybox
spec:
containers:
- name: my-busybox
image: nginx
affinity:
podAffinity: #my-busybox 添加pod亲和性，与打了标签app = my-nginx的pod靠近
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- my-nginx
topologyKey: kubernetes.io/hostname
以上例子表示，有一个pod在运行，并且这个pod有标签是app=my-nginx，my-busybox这个pod就会
与其调度到同一个节点上，可预见因为上面我们的my-nginx已经调度到dev-9，因此my-nginx和
my-busybox都会在dev-9节点上查询到
Taints & tolerations
Taints：污点，tolerations：容忍。在实际项目实践中有时候不希望某些服务调度到指定节点上，比如master节点只运行Kubernetes 组件，应用服务不希望调度到master上。这种场景只需要在master节点设置一个污点。
#设置污点
kubectl taint nodes dev-7 system=service:NoSchedule
设置了污点就不能调度了么？No 如果设置了污点还是希望某些pod能够调度上去，可以给pod针对污点加容忍。
#添加容忍
tolerations:
- key: "system"
operator: "Equal"
value: "service"
effect: "NoSchedule"
添加了容忍system=service , 这样就可以调度到节点设置了污点：system=service:NoSchedule
的主机上，其他没有添加容忍的服务就不会调度到打了污点的节点上。
effect 有三种设置
- NoSchedule：pod不能调度到标记了taints的节点
- PreferNoSchedule：pod最好不要调度到标记了taints的节点
- NoExecute：设置了污点，马上踢出该节点中没有设置对应污点的Tolerate设置的pod
参考文档
https://kubernetes.io/docs/con ... node/
https://kubernetes.io/docs/con ... tion/
关于睿云智合
深圳睿云智合科技有限公司成立于2012年，总部位于深圳，并分别在成都、深圳设立了研发中心，北京、上海设立了分支机构，核心骨干人员全部为来自金融、科技行业知名企业资深业务专家、技术专家。早期专注于为中国金融保险等大型企业提供创新技术、电子商务、CRM等领域专业咨询服务。
自2016年始，在率先将容器技术引进到中国保险行业客户后，公司组建了专业的容器技术产品研发和实施服务团队，旨在帮助中国金融行业客户将容器创新技术应用于企业信息技术支持业务发展的基础能力改善与提升，成为中国金融保险行业容器技术服务领导品牌。
此外，凭借多年来在呼叫中心领域的业务经验与技术积累，睿云智合率先在业界推出基于开源软交换平台FreeSwitch的微服务架构多媒体数字化业务平台，将语音、视频、webchat、微信、微博等多种客户接触渠道集成，实现客户统一接入、精准识别、智能路由的CRM策略，并以容器化治理来支持平台的全应用生命周期管理，显著提升了数字化业务处理的灵活、高效、弹性、稳定等特性，为帮助传统企业向“以客户为中心”的数字化业务转型提供完美的一站式整体解决方案。
本文转自DockOne-Kubernetes-项目中pod调度使用法则
