深入剖析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
登录|注册

42 | Kubernetes默认调度器调度策略解析

张磊 2018-11-28
你好,我是张磊。今天我和你分享的主题是:Kubernetes 默认调度器调度策略解析。
在上一篇文章中,我主要为你讲解了 Kubernetes 默认调度器的设计原理和架构。在今天这篇文章中,我们就专注在调度过程中 Predicates 和 Priorities 这两个调度策略主要发生作用的阶段。
首先,我们一起看看 Predicates。
Predicates 在调度过程中的作用,可以理解为 Filter,即:它按照调度策略,从当前集群的所有节点中,“过滤”出一系列符合条件的节点。这些节点,都是可以运行待调度 Pod 的宿主机。
而在 Kubernetes 中,默认的调度策略有如下三种。
第一种类型,叫作 GeneralPredicates。
顾名思义,这一组过滤规则,负责的是最基础的调度策略。比如,PodFitsResources 计算的就是宿主机的 CPU 和内存资源等是否够用。
当然,我在前面已经提到过,PodFitsResources 检查的只是 Pod 的 requests 字段。需要注意的是,Kubernetes 的调度器并没有为 GPU 等硬件资源定义具体的资源类型,而是统一用一种名叫 Extended Resource 的、Key-Value 格式的扩展字段来描述的。比如下面这个例子:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《深入剖析Kubernetes》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(14)

  • freeman
    首先筛选出满足资源的机器。如果可用节点大于等于需求副本集则一个node一份,顺序取node调度即可,如果node节点少于副本数量,则进行一次调度后,剩下的副本重复上面的事情。直到为每个副本找到对应node或者调度失败。
    2018-11-29
    1
    7
  • Dale
    在工作中遇到这个问题,需要将pod尽量分散在不通的node上,通过kubernetes提供的反亲和性来解决的。从回答中老师希望从Priorities阶段中实现,我的想法如下:
    1、首先在Predicates阶段,已经选择出来一组可以使用的node节点
    2、在Priorities阶段,根据资源可用情况将node从大到小排序,加上node节点个数为m
    3、根据pod中配置replicate个数n,在node列表中进行查找出资源可用的top n的node节点
    4、如果node节点个数m不满足pod中的replicate个数,每次选择top m之后,重新计算node的资源可用情况,在选择top(n-m)的node,会存在node上有多个情况,最大程度上保证pod分散在不同的node上
    2018-12-13
    2
  • tyamm
    老师,我有个疑问。这个课程后面会讲到如何搭建master节点高可用么??
    2018-11-28
    2
  • 王景迁
    根据老师上面说的,默认的调度策略不是应该有四种类型吗?为什么文章开头说是三种类型?
    2019-10-23
    1
  • 鱼自由
    老师,最后你提到为 Priorities 设置权重,请问,这个操作在哪里进行?

    作者回复: google一下 kube-scheduler policy。是一个配置文件或者配置yaml。

    2019-01-03
    1
  • 小朱
    请教一个问题,自己启动了另一个scheduler,某一个node上同时存在default-scheduler和second-scheduler调度的资源。但是scheduler只统计schedulerName是自己的pod,这样就和node上面kubelet统计的资源就出现了不一致,这种设计是为什么呢?
    2018-12-05
    1
  • 东东
    找到堆叠的原因,然后通过调整priorities相应的权重来避免“堆叠”
    2019-07-04
  • 北卡
    细看调度这一块,觉得k8s的设计真的蛮精彩的。
    2019-01-15
  • tommyCmd
    最近也一直被这个问题困扰,讨论一个方案是把pod的qos都设为Guaranteed,希望老师能够解答困惑
    2018-12-12
  • 马希民
    想请教一下老师,在做优先级选择的时候节点的剩余资源是如何得到的?是通过已经分配在该节点上的pod声明limit的资源总和还是通过该节点当前的实际资源使用情况呢?按照调度器使用缓存的说法,似乎应该是前者,那么如果一个pod在声明的时候要求了远远高于本身所需的资源,就会造成这个节点资源的极大浪费?小白不太懂,老师多多指教
    2018-11-28
  • 周娄子
    写一个类似nginx一致性hash的算法
    2018-11-28
  • 快乐就好
    问一下,我用二进制安装的kubernetes,在实现master的HA时,通过haproxy反代多个Master, 我测试手动注入kube-apiserver故障,进行一下调度和资源操作都是正常的,然后我恢复故障的apiserver,资源操作也都是正常,我用的kube-proxy 是ipvs, 我就发现node上通过ipvsadm查看流量转发情况到apiserver的其他两个master 节点都是有的,但是新恢复的apiserver上面是没有一点流量过来,是否在恢复前需要把故障节点etcd 信息给清了,再启动故障的服务,然后master 状态信息自动同步过来。
    2018-11-28
  • Alex
    podAntiAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchExpressions:
                  - key: name
                    operator: In
                    values:
                    - nginx-demo
                topologyKey: "kubernetes.io/hostname"

    我用了反亲和的特性让pod分到了不同的机器上,不知道是否回答了你的问题

    作者回复: 这就成了predicate了,我们希望的是一个priority

    2018-11-28
  • wilder
    沙发
    2018-11-28
收起评论
14
返回
顶部