共计 4013 个字符，预计需要花费 11 分钟才能阅读完成。
摘要：Volcano 次要是基于 Kubernetes 做的一个批处理零碎，心愿下层的 HPC、中间层大数据的利用以及最上面一层 AI 可能在对立 Kubernetes 下面运行的更高效。
Volcano 产生的背景
上图是咱们做的一个剖析，咱们将其分为三层，最上面为资源管理层，两头为畛域的框架，包含 AI 的体系、HPC、Batch，WKflow 的治理以及像当初的一些微服务及流量治理等。再往上是行业以及一些行业的利用。
随着一些行业的利用变得复杂，它对所需要的解决方案也越来越高。举个例子在 10 多年以前，在金融行业提供解决方案时，它的架构是非常简单的，可能须要一个数据库，一个 ERP 的中间件，就能够解决银行大部分的业务。
而当初，每天要收集大量的数据，它须要 spark 去做数据分析，甚至须要一些数据湖的产品去建设数据仓库，而后去做剖析，产生报表。同时它还会用 AI 的一些零碎，来简化业务流程等。
因而，当初的一些行业利用与 10 年前比，变得很简单，它可能会利用到上面这些畛域框架外面的一个或多个。其实对于行业利用，它的需要是在多个畛域框架作为一个交融，畛域框架的诉求是上面的资源管理层可能提供对立的资源管理。
Kubernetes 当初越来越多的承载了对立的资源管理的角色，它能够为 HPC 这些行业畛域框架提供服务，也能够作为大数据畛域的资源管理层。Volcano 次要是基于 Kubernetes 做的一个批处理零碎，心愿下层的 HPC、中间层大数据的利用以及最上面一层 AI 可能在对立 Kubernetes 下面运行的更高效。
Volcano 要解决什么样的问题？
挑战 1: 面向高性能负载的调度策略
e.g. fair-share, gang-scheduling
挑战 2: 反对多种作业生命周期治理
e.g. multiple pod template, error handling
挑战 3: 反对多种异构硬件
e.g. GPU, FPGA
挑战 4: 面向高性能负载的性能优化
e.g. scalability, throughput, network, runtime
挑战 5：反对资源管理及分时共享
e.g. Queue, Reclaim
Volcano 架构体系
蓝色局部是 K8s 自身的组件，绿色的局部是 Volcano 新加的一些组件。
作业提交流程：
1、通过 Admission 后，kubectl 将在 kube-apiserver 中创立 Job (Volcano CRD) 对像
2、JobController 依据 Job 的配置创立 相应的 Pods e.g. replicas
3、Pod 及 PodGroup 创立 后，vc-scheduler 会到 kube-apiserver 获取 Pod/PodGroup 以及 node 信息
4、获取信息后，vc-scheduler 将依据其配置的调度策略为每一个 Pod 选取适合节点
5、在为 Pod 调配节点后，kubelet 将从 kube-apiserver 中获得 Pod 的配置，启动相应的容器
须要强调的几点：
vc-scheduler 中的调度策略都以插件的模式存在, e.g. DRF, Priority, Gang
vc-controllers 蕴含了 QueueController, JobController，PodGroupController 以及 gc-controller
vc-scheduler 不仅能够调度批量计算的作业，也能够调度微服务作业；并且能够通过 multi-scheduler 性能与 kube-scheduler 共存
局部组件介绍
Controller
右边为 Volcano Job Controller，不只调度应用的 Volcano，Job 的生命周期治理、作业管理都在这外面蕴含。咱们提供了对立的作业管理，你只有应用 Volcano，也不须要创立各种各样的操作，就能够间接运行作业。
左边为 CRD Job Controller，通过上面的 PodGroup 去做集成。
scheduler 架构体系
Scheduler 反对动静配置和加载。右边为 apiserver, 左边为整个 Scheduler,apiserver 里有 Job、Pod、Pod Group；Scheduler 分为三局部，第一层为 Cache, 中间层为整个调度的过程，左边是以插件模式存在的调度算法。Cache 会将 apiserver 里创立的 Pod、Pod Group 这些信息存储并加工为 Jobinfors。中间层的 OpenSession 会从 Cache 里拉取 Pod、Pod Group，同时将左边的算法插件一起获取，从而运行它的调度工作。
状态之间依据不同的操作进行转换，见下图。
另外，咱们在 Pod 和 Pod 的状态方面减少了很多状态，图中蓝色局部为 K8s 自带的状态； 绿色局部是 session 级别的状态，一个调度周期，咱们会创立一个 session，它只在调度周期内发挥作用，一旦过了调度周期，这几个状态它是生效的；黄色局部的状态是放在 Cache 内的。咱们加这些状态的目标是缩小调度和 API 之间的一个交互，从而来优化调度性能。
Pod 的这些状态为调度器提供了更多优化的可能。 例如，当进行 Pod 驱赶时，驱赶在 Binding 和 Bound 状态的 Pod 要比拟驱赶 Running 状态的 Pod 的代价要小 (思考：还有其它状态的 Pod 能够驱赶吗？)；并且状态都是记录在 Volcano 调度外部，缩小了与 kube-apiserver 的通信。但目前 Volcano 调度器仅应用了状态的局部性能，比方当初的 preemption/reclaim 仅会驱赶 Running 状态下的 Pod；这次要是因为分布式系统中很难做到齐全的状态同步，在驱赶 Binding 和 Bound 状态的 Pod 会有很多的状态竞争。
在性能下面能带来哪些益处？
1）反对多种类型作业混合部署
2）反对多队列用于多租户资源共享，资源布局；并分时复用资源
3）反对多种高级调度策略，无效晋升整集群资源利用率
4）反对资源实时监控，用于高精度资源调度，例如 热点，网络带宽；容器引擎，网络性能优化, e.g. 免加载
分布式训练场景
Gang-scheduler
Case 1: 1 job with 2ps + 4workers
Case 2: 2 jobs with 2ps + 4workers
Case 3: 5 jobs with 2ps + 4workers
在 Volcano 和 kubeflow+kube-scheduler 做比照，Case 1 在资源短缺的时候成果是差不多的；Case 2 是在没有足够的资源的状况下同时运行两个作业，如果没有 gang-scheduling，其中的一个作业会呈现忙等；Case 3 当作业数涨到 5 后，很大概率呈现死锁；个别只能实现 2 个作业。
IOAware
3 个作业的执行工夫总和; 每个作业带 2ps + 4workers
默认调度器执行工夫稳定较大
执行工夫的进步量根据数据在作业中的比例而定
缩小 Pod Affinity/Anti-Affinity，进步调度器的整体性能
大数据场景
Spark-sql-perf (TP-DCS, master)
104 queries concurrently
(8cpu, 64G, 1600SSD) * 4nodes
Kubernetes 1.13
Driver: 1cpu,4G; Executor: (1cpu,4G)*5
如果没有固定的 driver 节点，最多同时运行 26 条查问语句
因为 Volcano 提供了作业级的资源预留，总体性能进步了~30%
HPC 场景
MPI on Volcano
布局
GPU 共享个性
1）算力优化：
GPU 硬件加速，TensorCore
GPU 共享
昇腾革新
2）调度算法优化：
Job/Task 模型，提供 AI 类 Job 对立批量调度
多任务排队，反对多租户 / 部门共享集群
单 Job 内多任务集群中最优化亲和性调度、Gang Scheduling 等
支流的 PS-Worker、Ring AllReduce 等分布式训练模型
3）流程优化
容器镜像
CICD 流程
日志监控
Volcano 能够反对更大规模的一个集群调度，咱们当初是 1 万个节点百万容器，调度的性能每秒达到 2000 个 Pod。
1) 编排：
Etcd 分库分表，e.g. Event 放到独自库，wal/snapshot 独自挂盘
通过一致性哈希扩散解决，实现 controller-manager 多活
Kube-apiserver 基于工作负载的弹性扩容
2) 调度：
通过 EquivalenceCache，算法剪枝 等技术晋升单调度器的吞吐性能
通过共享资源视图实现调度器多活，晋升调度速率
3) 网络：
通过 trunkport 晋升单节点容器密度及单集群 ENI 容量
通过 Warm Pool 预申请网口，晋升网口发放速度
基于 eBPF/XDP 反对大规模、高度变动的云原生利用网络，e.g. Service, network policy
4) 引擎：
containerd 并发 启动优化
反对 shimv2，晋升单节点容器密度
镜像下载减速 Lazy loading
Cromwell 社区集成
Cromwell 是一个流程调度软件，它能够定义不同的作业，这个软件在基因测序以及基因计算畛域里利用是比拟宽泛的。
Cromwell 社区原生反对 Volcano
企业版曾经上线 华为云 GCS
通过 cromwell 反对作业依赖
Volcano 提供面向作业、数据依赖的调度
Volcano CLI
KubeSim
简介：
集群进行性能测试及调度的形容工具
不受资源限度，模仿大规模 K8S 集群
残缺的 K8S API 调用，不会真正创立 pod
曾经反对产品侧大规模专项及调度专项的模仿工作
总体构造：
Worker cluster：承载 kubemark 虚构节点，hollow pod
Master cluster：治理 kubemark 虚构节点，hollow node
Hollow pod = hollow kubelet + hollow proxy
社区活跃度：
• 1.4k star，300+ fork，150+ 贡献者
• 3 Maintainer，7 Reviewer
• 30 家企业、科研机构
目前应用 Volcano 的局部企业
点击关注，第一工夫理解华为云陈腐技术~
