Kubernetes 是如何实现资源共享的

本文讲的是Kubernetes 是如何实现资源共享的【译者的话】Kubernetes相对于Mesos,不同之处在于对资源的调度管理,这篇Proposal展示了Kubernetes对于资源管理方面的思考,也反映了Kubernetes的发展方向。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述和架构、部署和核心机制分析、进阶篇——Kubernetes调工作原理及源码分析等。

使用场景和需求

作为一个集群管理员,希望创建一个环境来运行不同类型的工作负载,例如长时间运行的服务、大数据服务等等。由于这些应用被不同的业务部门所管理,所以我必须保证每个应用都有足够的计算资源。具体来说,如下所示:

  • 长时间运行的服务(应用域)和大数据服务(大数据域)能够共享资源: 
    • 定义每个区域的资源使用情况,例如40%的资源属于应用域,60%属于大数据域。
    • 借入/借出协议:如果一个区域里有空闲资源,则可以被其他区借出,并且被抢占。
  • 在大数据域运行多个集群:
    • 定义大数据域内每个集群的资源使用情况,例如Hadoop、Spark等等。
    • 在这些大数据集群之间共享资源,例如通过借入/借出方式。

以大数据为例,需求的具体细节如下:

  • 运行一组应用程序。
  • 保证每个应用程序有一定量可用的计算资源。
  • 提供一种机制,确保每个应用根据权重尽量访问所有未被使用的资源(每个应用对应一个权重,即如果所有应用都想使用所有的可用资源,则按照相对权重比例来操作)。
  • 如果一个应用程序A使用的资源少于保证值时,并且在可用资源不足的情况下,该应用需要使用保证值大小的资源,则可以从其他应用(有空闲计算资源的应用或者使用资源超出保证值的应用)那里获得足够的计算资源,以获得自身资源保证值对应的资源。

更进一步,将应用域和大数据域划分成两个“桶”,为每个“桶”分配一小部分的计算资源。与此同时,每个“桶”可以无限制地访问整个集群的资源,但是超过分配值之外的资源随时可以被收回。

根据mesos-style.md这份文档,我们完全可以通过一个定制的组件来做到这一点;但是这种资源规划、管理和共享的通用需求,最好由Kubernetes来实现。

术语

  • Arbitrator:根据策略分配资源(resource allocation)的新组件;默认调度器(通常是kube-scheduler)仍通过现有的策略为Pods指定资源(resource assignment)。
  • Deserved(Resource):arbitrator分配给namespace的资源总数。
  • Overused:如果使用的资源超过deserved的资源,命名空间将被认为是overused的。

背景

随着Kubernetes的发展,目前可以通过以下几个功能实现资源Qos控制和共享。

抢占和重调度

一个pod可以被驱逐,因为一些其他pod需要它使用的资源(抢占)。有一个基于优先级的抢占方案(每个Pod都有一个优先级,而具有更高和可能相同优先级的pod可以抢占它;谁做出决定及哪个Pod要抢占还待定,但可以是默认的调度程序,也可以是重调度器,也可能是集成了调度功能的基于应用的控制器,当然也可以是他们配合工作)。抢占总是使用优雅的终止方式。优先权方案通常意味着配额在每个优先级别的基础上分配,以便应用程序可以在最高优先级级别给予有限数量的配额,并且可以给予更大量的配额(甚至是无限的,即集群的整体能力),但是优先级较低。与此同时,重调度器通过驱逐Pod来执行集群级别的策略(目前有一个原始的重调度器来执行这样一个策略:关键的pod,如Heapster,DNS等不会由于集群中的可用资源不足而被阻止运行;但还有很多其他策略可以执行)。它通过驱逐一个或多个pod来允许一些待处理的Pod(s)进行调度。抢占需要在命名空间之间调度资源;arbitrator会是优先级规则的定义者,比如没有满足deserved的namespace的优先级高于overused的namespace。arbitrator将使用驱逐(Eviction)功能进行抢占。重调度器确保关键Pod不会由于资源不足而停止运行,也会重新调度其他Pods使其获得更好的安置(译者注:拥有合理的运行所需资源)。有了arbitrator之后,kube-system命名空间将能够获得无限的资源:即申请多少就能够得到多少,其他命名空间共享剩余的资源;对于“更好的安置(译者注:重新调度以获得更合理的资源)”没有其他影响。

工作负载专用控制器和ThirdPartyResource

ThirdPartyResource对象是使用新的API对象类型扩展Kubernetes API的一种方法。新的API类型将被赋予一个API endpoint并支持相应的增、删、改、查操作。您可以使用此API endpoint创建自定义对象。通过mesos-style.md和ThirdPartyResource,开发人员可以使用自定义对象构建workload customized controller(译者注:工作负载自定义控制器)。
k82cn/kube-arbitrator有一个例子,它通过ThirdPartyResource功能提供资源共享和抢占功能。

水平/垂直缩放和节点级QoS

节点级资源使用率的改进,对集群级资源共享并无贡献。但是关于节点级QoS,还应该考虑Pod的请求和限制。

方案

概要

为了满足上述要求,需要一个新的组件(k8s-arbitrator)和两个ThirdPartyResource(Consumer和Allocation)。

Consummer是arbitrator的ThirdPartyResource,以下yaml文件演示了Consumer的定义,

apiVersion: kuabe-arbitrator.incubator.k8s.io/v1
kind: Consumer
metadata:
name: defaults
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
reserved:
limits.memory: 1Gi

对于每个Consumer对象,它有两个字段:hard和reserved:

  • reserved:定义了为namespace保留的资源。它使用与”Compute Resource Quota”和”Storage Resource Quota”相同的资源类型。reserved不能超过hard定义的资源。如果启用了ResourceQuota Admission,它还将检查“预留”的总数是否超过了群集中的资源。
  • hard :定义了namespace可以使用的最大资源;它不能超过namespace的Quota.hard

Consumer由arbitrator为每个namespace创建,并且必要时由集群管理员进行更新;arbitrator创建具有无限hard和零reservedConsumer,因此namespace默认共享集群资源。

arbitrator将创建或更新Allocation中的额外字段:deserved

  • deserved:类似于Quota中的“Used”,它没有在yaml文件中定义,而是由arbitrator更新。它定义了arbitrator分配给命名空间的总资源。它不会走过Quota.hard,也可能因namespace的资源请求而改变。
  • hard/deserved:从'Consumer'复制;如果'Consumer'被更新,它也将在下一个调度周期被更新。

apiVersion: kuabe-arbitrator.incubator.k8s.io/v1
kind: Allocation
metadata:
name: defaults
spec:
deserved:
cpu:"1.5"
hard:
requests.cpu:"1"
requests.memory:1Gi
limits.cpu:"2"
limits.memory:2Gi
reserved:
limits.memory:1Gi

下图显示了Consumer/Allocation中的hardreserveddeserved的关系。

注意:只有”Compute Resource Quota”和”Storage Resource Quota”可用于reserveddeserved 。

-------------  <-- hard
|           |
|           |
- - - - - - -  <-- deserved
|           |
|           |
|           |
-------------  <-- reserved
|           |
-------------

k8s-arbitrator是一个新的组件,它会创建/更新Consumer和Allocation:

  • 基于arbitrator的策略计算 deserved 资源(Allocation.deserved);例如:DRF和namespace的请求(PoC中使用了pending pod)
  • 如果namespace 使用了过多的资源 (used > deserved),arbitrator 通知相应的controller,并在指定时间后有选择的终止Pod

同时,k8s默认调度器仍然根据其策略来分派任务到主机,例如PodAffinity:k8s-arbitrator负责resource allocation,k8s-scheduler负责resource assignment。

Arbitrator将DRF作为默认策略。它将从k8s-apiserver中取得pod/node,并根据DRF算法计算每个namespace的deserved资源;然后更新相应的配置。默认调度间隔为1s(可配置)。arbitrator不会将主机名分配给deserved资源中;它依赖默认的调度器(kube-scheduler)在适当的主机上分派任务。

Arbitrator还符合以下要求:

  • namespace的总体deserved资源不能超过群集中的资源。
  • deserved资源不能超过消费者的hard资源。
  • 如果集群中有足够的资源,deserved资源不能少于reserved资源。

抢占

当资源请求/配额发生变化时,每个命名空间的deserved资源也可能会发生变化。“较高”的优先级Pods将可能触发eviction,下图显示了由于deserved资源变化而引发eviction的情况。

T1:                 T2:                               T3:
--------------     -------------- --------------     -------------- --------------
| Consumer-1 |     | Consumer-1 | | Consumer-2 |     | Consumer-1 | | Consumer-2 |
|   cpu:2    | ==> |   cpu:1    | |   cpu:0    | ==> |   cpu:1    | |   cpu:1    | 
|   mem:2    |     |   mem:1    | |   mem:0    |     |   mem:1    | |   mem:1    |
--------------     -------------- --------------     -------------- --------------

  • T1:集群中只有一个namespace:Consumer-1;所有资源(cpu:2,mem:2)都被分配给它。
  • T2:创建一个新的namespace: Consuemr-2;arbitrator 重新计算每个namespace的资源分配,缩小overused的namespace。
  • T3:管理overused的namespace的controller必须选择一个Pod来杀死,否则arbitrator将会随机抽取需要杀死的Pods。Evict后,资源会被分配给underused的namespace。

Arbitrator使用pod的“/evict”REST API来回收资源。但是当arbitrator选择需要被杀死的Pods时,至少有两个要求:

  • Evict后,pods不能少于PodDisruptionBudget。
  • Evict后,namespace的资源不能少于reserved

Namespace在驱逐后可能会变成underused;arbitrator将尝试从最overused的namespace尝试杀死Pods。对于资源碎片的问题,暂时不在本文的讨论范围内;将在抢占实施文档中讨论设计细节。

功能交互

调度器

使用调度程序的HTTPExtender访问arbitrator,实现基于Allocation.Deserved的predicates。增强HTTPExtender的接口,为了性能考虑,只发送v1.Pod;arbitrator只指定资源数量,而不指定具体的主机。

工作负载特定的控制器

Arbitrator还将在特定工作负载的控制器中驱逐overused的namespace。基于特定工作负载的控制器不能使用比Allocation.deserved更多的资源。如果Allocation.deserved更新,它会选择Pods驱逐;否则arbitrator将在宽限期(grace period)后驱逐Pod(例如FCFS)。

多调度器

如果启用多调度器;只能启用一个arbitrator以避免竞争条件。

Admission 控制器

如果有计算资源和存储资源的配额,Arbitrator检查Consumer相对于这些Quta的定义。Consumer.hard不能超过Quota.hard。ResourceQuotaAdmission的其他指标将遵循当前行为。 

对其他Admission插件没有影响。

节点级QoS

在原型中,仅考虑requestlimit会在后续版本考虑。

ReplicaController/ReplicaSet

由于Consumer/Allocation是namespace级别而不是Job/RC级别,k8s-controller-manager不能根据RC的比例创建pod;它需要最终用户在RC之间平衡Pods或在Consumer中请求预留资源。

kubelet

现在还不涉及kubelet,虽然命名空间的Allocation.deserved也是kubelet中evict的一个因素,例如:

  • 拒绝overused的namespace的请求
  • 如果节点资源耗尽,则选择最overused的namespace里的Pods

目前进展

  • 基于DRF的arbitrator策略(完成)
  • 由k8s-arbitrator自动创建Consumer/Allocation(持续)
  • 面向 Consumer.reserved 的策略(持续)
  • 其它,例如doc,测试(持续)

路线图和未来

  • 高级的策略,例如不打破PodDisruptionBudget
  • 使用 “resourceRequest” 来减少 pending pod的使用
  • 加强关于存储策略,例如“PV / PVC”
  • k8s-arbitrator的HA
  • 层级Consumer
  • 无限Allocation用于kube-system
  • 面向 limit 的策略(节点/资源QoS)
  • Consumer / Allocation 客户端库,用于开发新的workload customized controller

引用

原文链接:Policy based resource sharing of Kubernetes (翻译:付辉)

原文发布时间为:2017-04-05

本文作者:付辉

本文来自合作伙伴Dockerone.io,了解相关信息可以关注Dockerone.io。

原文标题:Kubernetes 是如何实现资源共享的

时间: 2024-12-13 15:33:27

Kubernetes 是如何实现资源共享的的相关文章

DockOne微信分享(一二〇):基于Kubernetes的私有容器云建设实践

本文讲的是DockOne微信分享(一二〇):基于Kubernetes的私有容器云建设实践[编者的话]本次分享将为大家介绍易宝支付私有容器云从0到1的建设之路.包括技术选型.理论基础.基于Kubernetes的容器云和CI/CD落地过程中的挑战和踩过的坑. 建设背景及目标 在Docker技术流行开来之前,保证软件交付的质量和速度对于大多数企业来说都是困难的.业务的复杂性带来了应用的复杂性,面对成千上万的不同应用,运维部门需要时刻应对来自不同应用.不同环境的挑战.特别是在自动化运维程度不高的企业,"

巅峰对决之Swarm、Kubernetes、Mesos

本文讲的是巅峰对决之Swarm.Kubernetes.Mesos,[编者的话]这篇文章对比了三大主流调度框架:Swarm.Kubernetes和Mesos.文章不仅从理论上讨论了各个框架的优缺点,还从两个实际的案例出发,分析了每个框架具体使用方法. 这篇文章对比了三大主流调度框架:Docker Swarm.Google Kubernetes和Apache Mesos(基于Marathon框架).在解释了调度和容器的基本概念后,文章探讨了每个框架的特点,并从以下两个用例来对比他们:一个只使用了两个

Docker、Kubernetes、Apache Mesos 之争 | 一个与传说不同的故事

本文讲的是Docker.Kubernetes.Apache Mesos 之争 | 一个与传说不同的故事[编者的话]有无数的文章.讨论和社交网络上的交流在比较 Docker.Kubernetes 和 Mesos. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的 CI/CD 实践:开发流程中引入 CI.CD:Gitlab 和 CI.CD 工具:G

Google Kubernetes设计文档之Pod篇

[编者按]Kubernetes是Google开源的容器集群管理系统.它构建于Docker技术之上,为容器化的应用提供资源调度.部署运行.服务发现.扩容缩容等整一套功能,本质上可看作是基于容器技术的mini-PaaS平台.为帮助国内开发者了解Kubernetes技术,CSDN联合浙江大学SEL实验室共同翻译Kubernetes的系列设计文档,本文为系列的第二篇Pod. 在Kubernetes中,创建.调度和管理的最小部署单位是Pod,而不是容器. 什么是Pod 一个Pod对应于由若干容器组成的一个

容器和Kubernetes的应用与开发

容器就是新的进程 让我们从计算机开聊. 当计算机启动时,它会运行一个叫init的程序,然后init会启动其他所需的程序:服务器.终端.窗口管理器等. Init能做几件有趣的事情, 例如让一个程序开机启动, 隔一段时间运行一个程序, 还有确保一个程序没有失败或者crash,如果有就重启它. 正在运行的程序可以看到这台机器上的所有东西: 其它在运行的程序,所有的文件,以及网络. 多个进程同时跑在一台计算机上.所有的进程可以自由的互相之间交互,或者与常规的资源交互. 通过将进程进行划分, 程序员可以有

应用开发的先锋:容器和Kubernetes的故事

本文介绍了容器和Kubernetes的底层概念,以及它们如何给应用开发提供了新的模式. 容器就是新的进程 让我们从计算机开聊. 当计算机启动时,它会运行一个叫init的程序,然后init会启动其他所需的程序:服务器.终端.窗口管理器等. Init能做几件有趣的事情, 例如让一个程序开机启动, 隔一段时间运行一个程序, 还有确保一个程序没有失败或者crash,如果有就重启它. 正在运行的程序可以看到这台机器上的所有东西: 其它在运行的程序,所有的文件,以及网络. 多个进程同时跑在一台计算机上.所有

局域网资源共享故障分析解决实例

组建局域网络,最大的应用莫过于文档资源.音视频资源的共享以及打印机的共享.随着使用时间的推移,网络环境因为受到软硬件的影响,势必出现许多问题.本章列举在资源共享方面常见的一些问题,希望能给读者朋友一个排除参考.同时也准备了一些相关的知识供大家了解,便于弄清和领会问题的实质. 实例1:不同网段如何实现互访 疑问:两个部门的IP地址类似"192.168.0.1"与"192.168.1.1",其子网掩码都为"255.255.255.0",属于不同的网段

与时俱进 XP不改组策略也能资源共享

对于中小企业来说员工计算机采用操作系统版本最多的还要属Windows XP系统了,XP系统下的资源共享恐怕是最为老生常谈的问题了.解决办法无外乎修改组策略,开启GUEST帐户等等.然而你是否遇到过资源共享时无法针对被访问计算机进行配置的情况呢?遇到这种问题我们根本无法修改组策略,无法对GUEST帐户开启或关闭.相信这个难题一直困扰着不少网络频道的读者,今天笔者就为各位介绍一个新招--与时俱进让XP系统不改组策略也能实现资源共享. 一,传统XP系统资源共享时的解决办法: 当我们在企业通过一台员工计

XP/Server 03远程桌面资源共享大全

Windows系统拥有一个非常不错的功能--远程桌面,相信不好网络管理员都真真正正的是通过远程桌面功能管理远程服务器或普通客户机.然而你是否知道通过远程桌面连接目标计算机后,我们可以轻松实现本地计算机硬盘,剪贴板等方面的共享吗?当我们想将本地资源上传到远程服务器上是否必须通过FTP呢?今天笔者就利用公司的实际环境为各位介绍远程桌面资源共享的终极评测,让我们可以真正了解到我们可以通过远程桌面共享哪些资源. 一.远程桌面连接的前世今生: Windows远程桌面连接组件诞生与windows 2000系