Kubernetes之Pod调度
【烧脑式Kubernetes实战训练营】本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
Kubernetes中的调度策略主要分为全局调度与运行时调度2种。其中全局调度策略在调度器启动时配置,而运行时调度策略主要包括选择节点(nodeSelector),节点亲和性(nodeAffinity),pod亲和与反亲和性(podAffinity与podAntiAffinity)。Node Affinity、podAffinity/AntiAffinity以及后文即将介绍的污点(Taints)与容忍(tolerations)等特性,在Kuberntes1.6中均处于Beta阶段。
本文着重介绍运行时调度策略。
设置节点label
Label是Kubernetes核心概念之一,其以key/value的形式附加到各种对象上,如Pod、Service、Deployment、Node等,达到识别这些对象,管理关联关系等目的,如Node和Pod的关联。
获取当前集群中的全部节点:
kubectl get nodes
为指定节点设置label:
kubectl label nodes <node-name> <label-key>=<label-value>
确认节点label是否设置成功:
kubectl get nodes -l ‘label_key=label_value’
选择节点(nodeSelector)
nodeSelector是目前最为简单的一种pod运行时调度限制,目前在Kubernetes1.7.x及以下版本可用。Pod.spec.nodeSelector通过kubernetes的label-selector机制选择节点,由调度器调度策略匹配label,而后调度pod到目标节点,该匹配规则属于强制约束。后文要讲的nodeAffinity具备nodeSelector的全部功能,所以未来Kubernetes会将nodeSelector废除。
nodeSelector举例
设置label
$ kubectl label nodes bjo-rpt-re-002.dev.fwmrm.net disktype=ssd node "bjo-rpt-re-002.dev.fwmrm.net" labeled
查看满足非master节点且disktype类型为ssd的节点:
kubectl get nodes -l 'role!=master, disktype=ssd' NAME STATUS AGE VERSION bjo-rpt-re-002.dev.fwmrm.net Ready 39d v1.7.1
pod.yaml文件内容:
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: disktype: ssd
创建pod
kubectl create -f pod.yaml
查看pod nginx被调度到预期节点运行。
$ kubectl get po nginx -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 10s 10.244.3.13 bjo-rpt-re-002.dev.fwmrm.net
注:如果非默认namespace,需要指定具体namespace,例如:
kubectl -n kube-system get pods -o wide
内置节点label
Kubernetes自v1.4开始,节点有一些built-in label,罗列如下:
- 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
built-in label举例
yaml文件内容:
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: kubernetes.io/hostname: bjo-ep-svc-017.dev.fwmrm.net
创建pod,并检查结果符合预期,pod被调度在预先设置的节点 bjo-ep-svc-017.dev.fwmrm.net。
$ kubectl get po nginx -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 3m 10.244.1.58 bjo-ep-svc-017.dev.fwmrm.net
亲和性(Affinity)与非亲和性(anti-affinity)
前面提到的nodeSelector,其仅以一种非常简单的方式、即label强制限制pod调度到指定节点。而亲和性(Affinity)与非亲和性(anti-affinity)则更加灵活的指定pod调度到预期节点上,相比nodeSelector,Affinity与anti-affinity优势体现在:
- 表述语法更加多样化,不再仅受限于强制约束与匹配。
- 调度规则不再是强制约束(hard),取而代之的是软限(soft)或偏好(preference)。
- 指定pod可以和哪些pod部署在同一个/不同拓扑结构下。
亲和性主要分为3种类型:node affinity与inter-pod affinity/anti-affinity,下文会进行详细说明。
节点亲和性(Node affinity)
Node affinity在Kubernetes 1.2做为alpha引入,其涵盖了nodeSelector功能,主要分为requiredDuringSchedulingIgnoredDuringExecution与preferredDuringSchedulingIgnoredDuringExecution 2种类型。前者可认为一种强制限制,如果 Node 的标签发生了变化导致其没有符合 Pod 的调度要求节点,那么pod调度就会失败。而后者可认为理解为软限或偏好,同样如果 Node 的标签发生了变化导致其不再符合 pod 的调度要求,pod 依然会调度运行。
node affinity举例
设置节点label:
$ kubectl label nodes bjo-ep-dep-040.dev.fwmrm.net cpu=high node "bjo-ep-dep-040.dev.fwmrm.net" labeled$ kubectl label nodes bjo-ep-svc-017.dev.fwmrm.net cpu=mid node "bjo-ep-svc-017.dev.fwmrm.net" labeled$ kubectl label nodes bjo-rpt-re-002.dev.fwmrm.net cpu=low node "bjo-rpt-re-002.dev.fwmrm.net" labeled
部署pod的预期是到非master节点(role!=master)、且CPU高配的机器上(cpu=high)。
查看满足条件节点:
$ kubectl get nodes -l 'cpu=high, role!=master' NAME STATUS AGE VERSION bjo-ep-dep-040.dev.fwmrm.net Ready 41d v1.7.1
pod.yaml文件内容如下:
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: affinity: nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: roleoperator: NotInvalues:- masterpreferredDuringSchedulingIgnoredDuringExecution:- weight: 1preference:matchExpressions:- key: cpuoperator: Invalues:- high containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent
检查结果符合预期,pod nginx成功部署到非master节点且CPU高配的机器上。
$ kubectl get po nginx -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx 1/1 Running 0 32s 10.244.2.185 bjo-ep-dep-040.dev.fwmrm.net
pod亲和性(Inter-pod affinity)与反亲和性(anti-affinity)
inter-pod affinity与anti-affinity由Kubernetes 1.4引入,当前处于beta阶段,其中podAffinity用于调度pod可以和哪些pod部署在同一拓扑结构之下。而podAntiAffinity相反,其用于规定pod不可以和哪些pod部署在同一拓扑结构下。通过pod affinity与anti-affinity来解决pod和pod之间的关系。
与Node affinity类似,pod affinity与anti-affinity同样分为requiredDuringSchedulingIgnoredDuringExecution and preferredDuringSchedulingIgnoredDuringExecution等2种类型,前者被认为是强制约束,而后者后者可认为理解软限(soft)或偏好(preference)。
pod affinity与anti-affinity举例
本示例中假设部署场景为:期望is服务与oltp服务就近部署,而不希望与solr服务部署同一拓扑结构上。
yaml文件部分内容:
spec: replicas: 1 template: metadata:labels:app: isspec:affinity:podAffinity:requiredDuringSchedulingIgnoredDuringExecution:- labelSelector:matchExpressions:- key: appoperator: NotInvalues:- solrtopologyKey: kubernetes.io/hostnamepodAntiAffinity:preferredDuringSchedulingIgnoredDuringExecution:- weight: 1podAffinityTerm:labelSelector:matchExpressions:- key: appoperator: Invalues:- oltptopologyKey: beta.kubernetes.io/os
查看部署结果,is服务与oltp部署到了同一台机器,而solr被部署在其他机器上。
$ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE is-3059482752-5s14t 0/1 Running 1 1m 10.244.1.60 bjo-ep-svc-017.dev.fwmrm.net oltp-282283610-kdvnp 1/1 Running 0 1m 10.244.1.53 bjo-ep-svc-017.dev.fwmrm.net solr-908150957-rswlm 1/1 Running 0 1m 10.244.3.5 bjo-rpt-re-002.dev.fwmrm.net
亲和性/反亲和性调度策略比较
调度策略 匹配标签 操作符 拓扑域支持 调度目标 nodeAffinity 主机 In, NotIn, Exists, 否 pod到指定主机DoesNotExist, Gt, Lt podAffinity Pod In, NotIn, Exists, 是 pod与指定pod同一拓扑域DoesNotExist PodAntiAffinity Pod In, NotIn, Exists, 是 pod与指定pod非同一拓扑域DoesNotExist
污点(Taints)与容忍(tolerations)
对于Node affinity,无论是强制约束(hard)或偏好(preference)方式,都是调度pod到预期节点上,而Taints恰好与之相反,如果一个节点标记为 Taints ,除非 Pod也被标识为可以耐受污点节点,否则该Taints节点不会被调度pod。Taints)与tolerations当前处于beta阶段,
Taints节点应用场景比如用户希望把Kubernetes Master节点保留给 Kubernetes 系统组件使用,或者把一组具有特殊资源预留给某些 pod。
pod不会再被调度到taint标记过的节点。taint标记节点举例如下:
$ kubectl taint nodes bjo-ep-dep-039.dev.fwmrm.net key=value:NoSchedule node "bjo-ep-dep-039.dev.fwmrm.net" tainted
如果仍然希望某个pod调度到taint节点上,则必须在 Spec 中做出Toleration 定义,才能调度到该节点,举例如下:
tolerations: - key: "key" operator: "Equal" value: "value" effect: "NoSchedule"
effect 共有三个可选项,可按实际需求进行设置:
1. NoSchedule:pod不会被调度到标记为taints节点。
2. PreferNoSchedule:NoSchedule的“preference”或“soft”版本。
3. NoExecute:该选项意味着一旦Taint 生效,如该节点内正在运行的 Pod 没有对应 Tolerate 设置,会直接被逐出。
总结
使用者可根据实际需求,充分利用pod的相关高级调度策略,使Kubernetes更好的服务于我们的需求。
参考文档
Assigning Pods to Nodes: https://kubernetes.io/docs/con ... node/
Advanced Scheduling in Kubernetes: http://blog.kubernetes.io/2017 ... .html
欢迎转载,请注明作者出处:张夏,FreeWheel Lead Engineer,DockOne社区
原文发布时间为:2017-08-25
本文作者:张夏
本文来自云栖社区合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。
原文标题:Kubernetes之Pod调度
Kubernetes之Pod调度相关推荐
- 二十、Kubernetes中Pod调度第二篇NodeAffinity详解、实例
1.概述 在默认情况下,一个Pod在哪个Node节点上运行,是由Scheduler组件采用相应的算法计算出来的,这个过程是不受人工控制的.但是在实际使用中,这并不满足的需求,因为很多情况下,我们想控制 ...
- Kubernetes对Pod调度指定Node以及Node的Taint 和 Toleration
1.指定pod到指定的node上 #1.1查看节点的lebel kubectl get nodes --show-labels#1.2获取到该节点的label信息 ip-10-100-2-80 Rea ...
- Kubernetes Pod调度进阶:Taints(污点)和Tolerations(容忍)
[注意]最后更新于 2 years ago,文中内容可能已过时,请谨慎使用. 污点(Taint)和容忍(Toleration)是从Kubernetes 1.6开始提供的高级调度功能. 在Kuberne ...
- 6、kubernetes 核心技术-Pod
文章目录 一.Pod 概述 1.1 Pod 基本概念 二.Pod存在的意义 三.Pod实现机制 3.1 共享网络 3.2 共享存储 四.Pod镜像拉取策略 五.Pod资源限制 六.Pod 生命周期和重 ...
- k8s的list-watch机制和 pod调度约束
文章目录 一: k8s的list-watch 机制 1.1 k8s通过list-watch 机制进行每个组件的写作 1.2 Pod 的典型启动过程 1.3 调度过程 1.3.1 预算策略(predic ...
- Fluid 0.6 版本发布:数据感知的Pod调度与数据集自动弹性扩缩容
简介:Fluid 是 CNCF 基金会旗下云原生环境中数据密集型应用的高效支撑平台,由南京大学.阿里云云原生团队以及 Alluxio 开源社区联合发起.项目自开源发布以来吸引了众多相关方向领域专家和工 ...
- [kubernetes] Schedule --- Node调度与隔离
目录 1. NodeSelector 2. 亲和与反亲和 Affinity and Anti-affinity 节点Node 亲和性 pod 亲和性和反亲和性 3. 污点(Taints)与容忍(to ...
- Kubernetes中Pod生命周期
在 Kubernetes中Pod是容器管理的最小单位, 有着各种各样的Pod管理器. 那么一个Pod从启动到释放, 在这期间经历了哪些过程呢? Pod自开始创建, 到正常运行, 再到释放, 其时间跨度 ...
- Kubernetes 是如何调度的?
作者 | 阿文,责编 | 郭芮 头图 | CSDN 下载自东方IC 出品 | CSDN(ID:CSDNnews) 自互联网出现以来 ,云计算的概念已经提出了有 50 年.从1957 年,John Mc ...
最新文章
- Android的IPC机制(一)——AIDL的使用
- java 读取css文件_java文件读取的两种方式
- 近似装箱问题(三种联机算法实现)
- 服务器系统日志有哪些centos,CentOS 分析服务器日志命令
- 办公自动化-实测doc文档-创建文档添加内容-0223
- uilabel自动换行
- python中的exec()、eval()以及complie()
- 阶段1 语言基础+高级_1-3-Java语言高级_06-File类与IO流_05 IO字符流_2_字符输入流读取字符数据...
- 深度学习优化算法大全系列7:NAdam,算法选择,调参
- 波普尔心智格列高利心智_心智与人工智能理论
- 泰迪杯数据分析比赛2018年B题解答
- 调用高德API实现数据可视化
- python正则表达式爬取链家租房信息
- VMware esxi6.7虚拟机安装教程
- Java随笔记录第五章:类设计基础
- cocos2dx3.16输入框:TextField和EditBox的使用
- 不露脸也可以做自媒体短视频,简单罗列几个易上手的领域
- android midi字节,MIDI的20个基本概念
- 双色球彩票生成之一用户彩票号码随机生成
- Taro 牵手腾讯有数,助力小程序数据化运营
热门文章
- 将科学计数法的数值转化为字符
- AndroidStudio_java.util.ConcurrentModificationException---Android原生开发工作笔记237
- ES6新特性_ES6语法糖_class静态成员---JavaScript_ECMAScript_ES6-ES11新特性工作笔记034
- OAuth2.0_JWT令牌介绍_Spring Security OAuth2.0认证授权---springcloud工作笔记147
- k8s集群部署项目_JAVA项目(推送镜像到云镜像服务器_这里使用阿里云)---K8S_Google工作笔记0061
- springcloud工作笔记092---清理多余权限垃圾数据小工具
- C#.Net工作笔记010---c#中的静态扩展方法_可动态给string等_添加共通方法好用
- new 失败的处理方式
- 多线程的那点儿事(之大结局)
- 一步一步写算法(之排序二叉树的保存和加载)