Kubernetes 前世今生 Borg 类比Kubernetes

Kubernetes 前世今生 Borg 类比Kubernetes

什么是云计算

云计算平台分类

一openstack这种的云管平台，将很多物理机在这基础之上安装hypervisor，然后上面再启动一些虚拟机，然后再将这些虚拟机组成大的云平台，这是以openstack为例的，它最终的交付形态是一个一个的操作系统，在操作系统之上需要部署你的应用。

另外一类就是google的borg系统为主，它没有使用虚拟化技术，它的主要的实现方式是轻量级的作业调度，它调度的是一个一个的进程，Borg就是这样一个平台，Borg本身利用了容器技术，比如cgroup，就是Google开源给Linux的，

Borg架构

Borg主要支撑了两类业务，一类是生产业务，叫做production workload，比如邮箱服务，比如文档服务，还有一种是离线作业。

离线业务和在线业务有什么差别呢？在线业务要求高可用，要求永远在线，对资源的开销可能没有那么大，他不是大量消耗某些计算资源这种，除非负载非常大的时候。

离线业务一般是做批处理作业的，它对资源的开销会比较高，比如启动一个AI训练的时候它会疯狂的去吃CPU，离线作业的好处是对可用性的要求会稍微低，发起一个批处理作业的时候，你不能要求他马上返回，运行的时间可能几分钟，几小时，几天。所以对于离线作业的时效性要求低。

Google就是通过在线业务和离线业务混合部署方式，使得整个数据中心的资源利用率有本质上的提升。

Google Borg 简介

特性

物理资源利用率高。（没有使用虚拟化技术，不需要模拟操作系统，所有的资源都是用来做计算的）服务器共享，在进程级别做隔离。应用高可用，故障恢复时间短。调度策略灵活。应用接入和使用方便，提供了完备的 Job 描述语言，服务发现，实时状态监控和诊断工具。

有事21：

优势

对外隐藏底层资源管理和调度、故障处理等。（用户不需要管我怎么调度，只要告诉需要多少资源）实现应用的高可靠和高可用。足够弹性，支持应用跑在成千上万的机器上。

基本概念

Borg 架构

Borgmaster 主进程：（用来接收所有用户请求，请求提交给Rest API）

处理客户端 RPC 请求，比如创建 Job，查询 Job 等。维护系统组件和服务的状态，比如服务器、Task 等。负责与 Borglet 通信。

Scheduler 进程：(寻找一个最合适的机器，将作业调度过去)

调度策略：

worst fitbest fithybrid

调度优化：

Score caching: 当服务器或者任务的状态未发生变更或者变更很少时，直接采用缓存数据，避免重复计算。 Equivalence classes: 调度同一 Job 下多个相同的 Task 只需计算一次。Relaxed randomization: 引入一些随机性，即每次随机选择一些机器，只要符合需求的服务器数量达到一定值时，就可以停止计算，无需每次对 Cel l中所有服务器进行 feasibility checking。

Borglet：（每个节点上面的代理，有好几个职责，第一个职责是将节点的计算资源和节点健康状态上报给master，调度器就可以从master里面获取集群所有节点的健康状态和资源的计算能力）

Borglet 是部署在所有服务器上的 Agent，负责接收 Borgmaster 进程的指令。

cell里面是一个集群，cell里面有成千上万的节点，这批节点会被分为两类，一类叫做管理节点。

master节点本身是不多的， 可能就几台master，其次就是worker节点，worker节点是用来真正跑业务的节点，master上面会提供interface，作业提交到master之后，会由scheduler调度器去工作。

它会按照资源需求，会去集群里面选择最适合运行作业的节点，完成调度之后，作业和节点就会产生绑定关系。

在每个节点上面会跑一个代理叫做borglet，borglet会去接受master的指令负责将这个应用启动起来，运行你的业务。

调度器就有很多模式和策略了，下面是调度器里面常用的概念和模式了

worst fit：调度器会去找这个集群里面，资源利用率最低的一个节点，也就是找一个最闲的节点给你，空闲的资源和你资源需求实际上是非常大的，这样其实就是永远使用集群当中资源利用率最低的节点，这样就使得集群节点的作业负载平均。

best fit：恰好满足你需求的节点，他会去找能够满足你需求的节点

应用高可用

被抢占的 non-prod 任务放回 pending queue，等待重新调度。

在线业务的命是高可用，一个业务失去了高可用那么就完全没法提供在线服务，这个后果是不可承担的。

在线业务要永远保持在线业务的高可用，比如你要去部署或者扩容在线业务，他就会为你这个在线业务去做调度，当集群里面没有可用资源了怎么办？那么就要去杀掉离线业务，会将离线业务的资源抢过来，将其应用杀掉，将这个资源交给在线业务，这样先让在线业务先跑，但是离线业务不能丢，所以会将离线业务放进pending queue，等什么时候有资源了再重新跑。这样即保证了在线业务的高可用，又保证了离线业务的作业不可丢。

多副本应用跨故障域部署。所谓故障域有大有小，比如相同机器、相同机架或相同电源插座等，一挂全挂。

高可用怎么来，高可用往往通过冗余部署来，比如服务平时需要一个副本，如果副本坏了那么这个服务就不是高可用的，要确保服务高可用可以多部署几份，前面配置负载均衡，如果后面有一个实例坏了，那么还有其他实例支撑着，但是冗余部署，这三个副本跑在一台机器上面，那么这个机器坏了，那么冗余部署是没有意义的。所以Borg提供了跨故障域的部署，包括跨节点，跨机架，跨可用区域。

对于类似服务器或操作系统升级的维护操作，避免大量服务器同时进行。支持幂等性，支持客户端重复操作。

有些命令可以反复去敲的，不管你输入多少次，返回的都是统一的结果

当服务器状态变为不可用时，要控制重新调度任务的速率。因为 Borg 无法区分是节点故障还是出现了短暂的网络分区，如果是后者，静静地等待网络恢复更利于保障服务可用性。当某种“任务 @ 服务器”的组合出现故障时，下次重新调度时需避免这种组合再次出现，因为极大可能会再次出现相同故障。记录详细的内部信息，便于故障排查和分析。保障应用高可用的关键性设计原则是：无论何种原因，即使 Borgmaster 或者 Borglet 挂掉、失联，都不能杀掉正在运行的服务（Task）。

Borg 系统自身高可用

• Borgmaster 组件多副本设计。

• 采用一些简单的和底层（low-level）的工具来部署 Borg 系统实例，避免引入过多的外部依赖。

• 每个 Cell 的 Borg 均独立部署，避免不同 Borg 系统相互影响。

资源利用率

通过在线和离线业务的混合部署，使得资源利用率非常的高，如果我们只跑在线，一定会有些问题，业务波谷的资源是空闲的，为了节省整个资源中心数据成本，

• 通过将在线任务（prod）和离线任务（non-prod，batch）混合部署，空闲时，离线任务可以充分利用计算资源，繁忙时，在线任务通过抢占的方式保证优先得到执行，合理地利用资源。

• 98% 的服务器实现了混部。

• 90% 的服务器中跑了超过 25 个 Task 和 4500 个线程。

• 在一个中等规模的 Cell 里，在线任务和离线任务独立部署比混合部署所需的服务器数量多出约 20%-30%。可以简单算一笔账，Google 的服务器数量在千万级别，按 20%算也是百万级别，大概能省下的服务器采购费用就是百亿级别了，这还不包括省下的机房等基础设施和电费等费用。

Borg 调度原理

如果你是开发人员，你的任务除了写好业务逻辑，还可能想保证业务的高可用，这样就需要代码的健壮和留够足够的资源。

怎么样才算留够足够的资源？这就需要做压力测试，用了多少资源，或者基于现状去做一个压力测试看用了多少资源，然后在申请资源的时候，然后将这个预估的量给出来，因为可能突然来一个业务高峰要抗的住，所以要多申请一点资源。

隔离性

安全性隔离

早期采用Chroot jail，后期版本基于Namespace。

性能隔离

采用基于Cgroup的容器技术实现。在线任务（prod）是延时敏感（latency-sensitive）型的，优先级高，而离线任务（non-prod，Batch）优先级低。Borg 通过不同优先级之间的抢占式调度来优先保障在线任务的性能，牺牲离线任务。· Borg将资源类型分成两类∶（从资源配额的维度看）

可压榨的（compressible），CPU是可压榨资源，资源耗尽不会终止进程（cpu是分时复用的原理，反正我就这么多cpu时间片，你告诉我应该怎么样去分配，每个人雨露均沾，每个人都给一点，这是可压榨资源，当竞争大的时候，那么大家一起按照预先分配的比例每个人都去分配一些，你的性能会慢一些，但是你的程序不会退出）不可压榨的（non-compressible），内存是不可压榨资源，资源耗尽进程会被终止。磁盘也是不可压榨资源，对于不可压榨资源，用尽了只能终止这个进程。

什么是 Kubernetes（K8s）?

Kubernetes 是谷歌开源的容器集群管理系统，是 Google 多年大规模容器管理技术 Borg的开源版本，主要功能包括：

• 基于容器的应用部署、维护和滚动升级(一个应用先跑3个实例，在升级的时候一个个滚动着升级，对用户来说这是无感知的，悄悄的就把版本换掉了)

• 负载均衡和服务发现

• 跨机器和跨地区的集群调度

• 自动伸缩（监控业务cpu等metrics，超过你设置的一些阈值的话，会自动做伸缩的）

• 无状态服务和有状态服务

• 插件机制保证扩展性

可以看到Kubernetes最终去运行应用的时候，这些应用都是容器化的应用，Kubernetes有核心的组件叫做kubelet，类似于Borglet，它会去调用CRI的接口，通过runtime运行时将一个一个容器进程运行起来。

命令式系统关注 “如何做”

在软件工程领域，命令式系统是写出解决某个问题，完成某个任务，或者达到某个目标的的明确步 骤。此方法明确写出系统应该执行某指令，并且期待系统返回期望结果。

命令式就是要你做什么，每一步都得告诉清楚，而且要严格按照所说的做，就比如遥控器，你跳台的时候，或者调整音量的时候，你按一下遥控器它就变一下，这种特性是响应比较快，你给他一个指令就立马返回，基于这个返回再去做下一步的指示。

Kubernetes 的所有管理能力构建在对象抽象的基础上，核心对象包括：

• Node：计算节点的抽象， 用来描述计算节点的资源抽象，健康状态等；

• Namespace：资源隔离的基本单位，可以简单理解为文件系统中的目录结构（对于不同的用户可以通过权限控制来决定用户可以访问哪个namespace，这样也是可以说是资源隔离，每个用户访问特定命名空间下的资源）

• Pod：用来描述应用实例，包括镜像地址，资源需求等。 Kubernetes 中最核心的对象，也是打通

应用和基础架构的秘密武器；

对于实时系统，可以以阻塞的方式，你敲一条命令，让其给你一个respones，但是对于分布式的系统，如果每个请求都是阻塞的，那么整个平台效率都不会高的。阻塞的话意味着CPU就等在那了，即使有CPU被人也没有办法获得CPU。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。