深入剖析Kubernetes
张磊
Kubernetes社区资深成员与项目维护者
立即订阅
22715 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (5讲)
开篇词 | 打通“容器技术”的任督二脉
免费
01 | 预习篇 · 小鲸鱼大事记(一):初出茅庐
02 | 预习篇 · 小鲸鱼大事记(二):崭露头角
03 | 预习篇 · 小鲸鱼大事记(三):群雄并起
04 | 预习篇 · 小鲸鱼大事记(四):尘埃落定
容器技术概念入门篇 (5讲)
05 | 白话容器基础(一):从进程说开去
06 | 白话容器基础(二):隔离与限制
07 | 白话容器基础(三):深入理解容器镜像
08 | 白话容器基础(四):重新认识Docker容器
09 | 从容器到容器云:谈谈Kubernetes的本质
Kubernetes集群搭建与实践 (3讲)
10 | Kubernetes一键部署利器:kubeadm
11 | 从0到1:搭建一个完整的Kubernetes集群
12 | 牛刀小试:我的第一个容器化应用
容器编排与Kubernetes作业管理 (15讲)
13 | 为什么我们需要Pod?
14 | 深入解析Pod对象(一):基本概念
15 | 深入解析Pod对象(二):使用进阶
16 | 编排其实很简单:谈谈“控制器”模型
17 | 经典PaaS的记忆:作业副本与水平扩展
18 | 深入理解StatefulSet(一):拓扑状态
19 | 深入理解StatefulSet(二):存储状态
20 | 深入理解StatefulSet(三):有状态应用实践
21 | 容器化守护进程的意义:DaemonSet
22 | 撬动离线业务:Job与CronJob
23 | 声明式API与Kubernetes编程范式
24 | 深入解析声明式API(一):API对象的奥秘
25 | 深入解析声明式API(二):编写自定义控制器
26 | 基于角色的权限控制:RBAC
27 | 聪明的微创新:Operator工作原理解读
Kubernetes容器持久化存储 (4讲)
28 | PV、PVC、StorageClass,这些到底在说啥?
29 | PV、PVC体系是不是多此一举?从本地持久化卷谈起
30 | 编写自己的存储插件:FlexVolume与CSI
31 | 容器存储实践:CSI插件编写指南
Kubernetes容器网络 (8讲)
32 | 浅谈容器网络
33 | 深入解析容器跨主机网络
34 | Kubernetes网络模型与CNI网络插件
35 | 解读Kubernetes三层网络方案
36 | 为什么说Kubernetes只有soft multi-tenancy?
37 | 找到容器不容易:Service、DNS与服务发现
38 | 从外界连通Service与Service调试“三板斧”
39 | 谈谈Service与Ingress
Kubernetes作业调度与资源管理 (5讲)
40 | Kubernetes的资源模型与资源管理
41 | 十字路口上的Kubernetes默认调度器
42 | Kubernetes默认调度器调度策略解析
43 | Kubernetes默认调度器的优先级与抢占机制
44 | Kubernetes GPU管理与Device Plugin机制
Kubernetes容器运行时 (3讲)
45 | 幕后英雄:SIG-Node与CRI
46 | 解读 CRI 与 容器运行时
47 | 绝不仅仅是安全:Kata Containers 与 gVisor
Kubernetes容器监控与日志 (3讲)
48 | Prometheus、Metrics Server与Kubernetes监控体系
49 | Custom Metrics: 让Auto Scaling不再“食之无味”
50 | 让日志无处可逃:容器日志收集与管理
再谈开源与社区 (1讲)
51 | 谈谈Kubernetes开源社区和未来走向
答疑文章 (1讲)
52 | 答疑:在问题中解决问题,在思考中产生思考
特别放送 (1讲)
特别放送 | 2019 年,容器技术生态会发生些什么?
结束语 (1讲)
结束语 | Kubernetes:赢开发者赢天下
特别放送 | 云原生应用管理系列 (1讲)
基于 Kubernetes 的云原生应用管理,到底应该怎么做?
深入剖析Kubernetes
登录|注册

41 | 十字路口上的Kubernetes默认调度器

张磊 2018-11-26
你好,我是张磊。今天我和你分享的主题是:十字路口上的 Kubernetes 默认调度器。
在上一篇文章中,我主要为你介绍了 Kubernetes 里关于资源模型和资源管理的设计方法。而在今天这篇文章中,我就来为你介绍一下 Kubernetes 的默认调度器(default scheduler)。
在 Kubernetes 项目中,默认调度器的主要职责,就是为一个新创建出来的 Pod,寻找一个最合适的节点(Node)。
而这里“最合适”的含义,包括两层:
从集群所有的节点中,根据调度算法挑选出所有可以运行该 Pod 的节点;
从第一步的结果中,再根据调度算法挑选一个最符合条件的节点作为最终结果。
所以在具体的调度流程中,默认调度器会首先调用一组叫作 Predicate 的调度算法,来检查每个 Node。然后,再调用一组叫作 Priority 的调度算法,来给上一步得到的结果里的每个 Node 打分。最终的调度结果,就是得分最高的那个 Node。
而我在前面的文章中曾经介绍过,调度器对一个 Pod 调度成功,实际上就是将它的 spec.nodeName 字段填上调度结果的节点名字。
备注:这里你可以再回顾下第 14 篇文章《深入解析 Pod 对象(一):基本概念》中的相关内容。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《深入剖析Kubernetes》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(7)

  • CYH
    问题回答:messos二级调度是资源调度和业务调度分开;优点:插件化调度框架(用户可以自定义自己调度器然后注册到messos资源调度框架即可),灵活可扩展性高.缺点:资源和业务调度分开无法获取资源使用情况,进而无法做更细粒度的调度.k8s调度是统一调度也就是业务和资源调度进行统一调度,可以进行更细粒度的调度;缺点其调度器扩展性差。以上是本人拙见,请老师指正。

    作者回复: 一点都不拙!

    2018-11-29
    1
    24
  • loda
    想请教个问题,kubernetes如何保证用户能提前知道这次调度能否成功?
    场景:很多公司都希望提前就发现资源池余量是否充足,从而决定是要加机器还是可以继续扩容
    拙见:
    1.scheduler的缓存其实是一个非常重要的数据,可以提供当前时刻调度能否成功的视图,但是直接暴露出来不太符合kubernetes以apiserver为依据的原则
    2.提供余量检查接口,实时查询apiserver中所有pod和node,根据扩容参数算出剩余资源量。不过规模大后,对集群压力太大
    3.定时采集上述指标,缺点是实时性太差
    4.监听pod crud,自己独立维护一个和scheduler一样的缓存或持久话数据,每次基于这个数据判断剩余量。缺点是维护成本较高,容易出现数据不一致

    想问下,有没有更合适的方式?
    2018-12-09
    3
  • 宋晓明
    老师 刚才遇到一个问题 我初始化的时候 分配的ip范围是10.64.200.0/22 然后两个master 3个node kubernetes自己分配master分别是200.0/24 201.0/24 然后其他两个node是202.0/24 203.0/24 其实这些范围已经用满了 在加第三个node 在master看也成功了 但创建多个pod的时候 第三个node上的pod是失败的,后来发现第三个node上kube-bridge网桥上没有IP地址,需求是:因为master上不会有自己创建的pod的,所以master上地址段有点浪费,我如何把master上空闲的地址段用到新增node上,还是不用管,还是怎么样?
    2018-11-27
    2
  • Vip He
    老师您好,这个pod调度过程是并行的吗还是一个一个pod调度?

    作者回复: 串行的

    2019-05-26
    1
  • dgonly
    调度器对APIServer的更新失败,Bind过程失败,老师说等schedule cache同步后就恢复正常,这个怎么理解?
    我理解是informer path继续watch,发现pod没有被bind到node就继续执行一遍调度流程吗?如果某种原因更新APIServer一直失败,会不会就一直执行重新调度的操作,有没有一种类似重试超过一定比如就丢弃的机制。谢谢!
    2018-11-26
    1
  • wypsmall
    请教一个问题,调度策略中有没有对网络io限制呢?也就是说不希望高网络io的pod被调度到同一个宿主机。
    2019-02-13
  • 如果能结合源码将解决就更好了,不知道相关代码在哪啊
    2019-01-25
收起评论
7
返回
顶部