[Kubeflow系列]总览介绍

什么是Kubeflow

对于官网的定义:

The Kubeflow project is dedicated to making deployments of machine learning (ML) workflows on Kubernetes simple, portable and scalable. Our goal is not to recreate other services, but to provide a straightforward way to deploy best-of-breed open-source systems for ML to diverse infrastructures.

我们可以看出kubeflow是在Kubernetes之上构建Machine Learning的项目, 他本身不会创建任何AI或者Kubernetes的服务, 而是为了Machine Learning项目构建的更加简单, 更加可扩展.

为了更好的学习Kubeflow, 我们需要有以下的基础知识:

  1. 容器技术, 包含docker使用, 镜像制作, Kubernetes 任务提交等一系列的Paas能力
  2. AI技术, 包括各种AI框架, 以及分布式AI模型等
  3. Python语言, kubeflow的代码库大多以Python编写

Kubeflow有什么

Kubeflow有很多的组件, 可以在官网文档的Components模块之中找到所有能力组件, 我把这些模块整理了一下, 画出脑图, 如下:

左边的一列为kubeflow面向机器学习领域提供的能力, 包括模型的训练推理以及自动学习的超参调优组件, Kubeflow已经支持了市面上大多数的训练和推理框架, 其中最完善的就是google自己家的TensorFlow.

当然也是最重要的一个模块, 毕竟Kubeflow的名字有一般来自于它.

右边的一列为Kubeflow的基础能力, 主要为pipeline, notebook, fairing以及一些公共的组件, 例如元数据管理等, 这个部分是围绕AI能力外围的基础组件, 主要关注于工程部分, 例如使用pipeline进行编排, 使用notebook进行开发等.

下面准备简单介绍一下这几个模块, 某些组件特别大, 我准备单独写个文章介绍, 这里就会一笔带过.

TFJob 和 TF Serving

模型训练是机器学习最主要的实践场景,尤其以使用机器学习框架TensorFlow进行模型训练最为流行,但是随着机器学习的平台由单机变成集群,这个问题变得复杂了。GPU的调度和绑定,涉及到分布式训练的编排和集群规约属性的配置(cluster spec)也成了数据科学家们巨大的负担。

为了解决这一问题,一个新的资源类型TFJob,即TensorFlow Job被定义出来了。通过这个资源类型,使用TensorFlow的数据科学家无需编写复杂的配置,只需要关注数据的输入,代码的运行和日志的输入输出。

下面看一个官方案例来看一下TFJob的定义, 除了tfReplicaSpecs定义为PS Worker等概念之外, 其实和没有K8s的POD定位没有太多的区别.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
apiVersion: "kubeflow.org/v1beta1"
kind: "TFJob"
metadata:
name: "tf-smoke-gpu"
namespace: "kubeflow"
spec:
tfReplicaSpecs:
PS:
replicas: 1
template:
metadata:
creationTimestamp: null
spec:
containers:
- args:
- python
- tf_cnn_benchmarks.py
- --batch_size=32
- --model=resnet50
- --variable_update=parameter_server
- --flush_stdout=true
- --num_gpus=1
- --local_parameter_device=cpu
- --device=cpu
- --data_format=NHWC
image: swr.cn-north-5.myhuaweicloud.com/kubeflow/tf-benchmarks-cpu:v20171202-bdab599-dirty-284af3
name: tensorflow
ports:
- containerPort: 2222
name: tfjob-port
resources:
limits:
cpu: '1'
workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
restartPolicy: OnFailure
Worker:
replicas: 1
template:
metadata:
creationTimestamp: null
spec:
containers:
- args:
- python
- tf_cnn_benchmarks.py
- --batch_size=32
- --model=resnet50
- --variable_update=parameter_server
- --flush_stdout=true
- --num_gpus=1
- --local_parameter_device=cpu
- --device=gpu
- --data_format=NHWC
image: swr.cn-north-5.myhuaweicloud.com/kubeflow/tf-benchmarks-gpu:v20171202-bdab599-dirty-284af3
name: tensorflow
ports:
- containerPort: 2222
name: tfjob-port
resources:
limits:
nvidia.com/gpu: 1
workingDir: /opt/tf-benchmarks/scripts/tf_cnn_benchmarks
restartPolicy: OnFailure

TensorFlow Serving是Google开源的一个灵活的、高性能的机器学习模型服务系统,能够简化并加速从模型到生产应用的过程。它除了原生支持TensorFlow模型,还可以扩展支持其他类型的机器学习模型。

部署完成之后, 可以通过API访问TF Serving或者GRpc的方式来进行推理服务.

1
2
kubectl get svc mnist-service
curl -X POST -d @input.json http://EXTERNAL_IP:8500/v1/models/mnist:predict

这个部分可以参考阿里云的文章, 后续再写详细介绍的文章

其中有一点需要的注意的是: TFJob是Kubeflow在K8s上的CRD, 而TF-Serving是TensorFlow的内容, Kubeflow只不过在K8s上启动一个镜像实例而已, 所以你也可以来完成TF-Serving功能

Katib超参数训练系统

Katib is a Kubernetes Native System for Hyperparameter Tuning and Neural Architecture Search. The system is inspired by Google vizier and supports multiple ML/DL frameworks (e.g. TensorFlow, MXNet, and PyTorch).

Katib 也是对 Google Vizier 的开源实现,因此也遵循其中对问题的抽象模型:Study,Trial 和 Suggestion.
Trial 代表着一个由超参数的取值组成的列表,每个 Trial 都需要一次运行来得到这些超参数取值对应的结果。这里提到的运行就是一次训练的过程。Study 代表着在可行空间上运行的单个优化。每个 Study 都有一个配置,来描述可能取值的空间,超参数推荐算法等。此外,Study 包含一组 Trial,代表着算法在超参数集合中选取推荐值的多次尝试。如图所示,是创建一次 Study 并且进行 Trial 的验证的过程。

Currently Katib supports the following exploration algorithms in v1alpha1:

这块非常不懂唉, 后续等恶补一下知识了. 现在摘要了这篇博客文章的内容

Pipeline

这块的目的就是为了编排Kubeflow任务用的, 在这篇文章之中介绍.

Jupiter Notebook

Notebook是数据科学家比较喜欢的编程工具, kubeflow已经集成:

上图是notebook的创建页面, 可以看出来kubeflow的notebook有以下能力:

  1. 自定义镜像
  2. 支持资源定义
  3. 支持各种数据盘挂载
  4. 支持GPU调度

使用notebook提交pipeline

以官方的Lightweight Python components - basics为例子

  • 上边的cell定了流程算子
  • 中间的cell编译流程算子, 生成argo的配置文件pipeline.zip
  • 下面的cell创建了Pipeline Service的客户端, 创建了experimentrun执行了任务

Fairing SDK

Kubeflow Fairing is a Python package that makes it easy to train and deploy ML models on Kubeflow. Kubeflow Fairing can also been extended to train or deploy on other platforms. Currently, Kubeflow Fairing has been extended to train on Google AI Platform.

Kubeflow Fairing packages your Jupyter notebook, Python function, or Python file as a Docker image, then deploys and runs the training job on Kubeflow or AI Platform. After your training job is complete, you can use Kubeflow Fairing to deploy your trained model as a prediction endpoint on Kubeflow.

官网上介绍Fairing的文字, fairing的定位就是机器学习的SDK, 但他最大的一个好处就是简化构建镜像的麻烦, 它能自动帮你构建镜像, 并将镜像部署在k8s上运行, 因为之前的开发模式是这样子的:

引入Kubeflow变成这样了:

平白多了几部做镜像的步骤, 而且做镜像对数据科学家来说是个难活, 因此引入Fairing工程是十分必要的

其他

上面已经把kubeflow最重要的内容将完, 但是k8s还有很多其他子项目, 虽然不然之前的模块那么重要, 但是也是必不可少的内容. 这些组件很多都不在k8s之中, 在k8s的其他项目里面.

Metadata

元数据模块主要是为了用户能更好的管理和追踪kubeflow的流程, 它后台使用的是Google的ML-Metadata来管理, 而且暴露了REST API来跟用户调用, 同时也有Python SDK远程调用

kustomize

kustomize并不是kubeflow的一个项目, 而是kubernetes-sigs的一个子项目, 主要简化部署K8s服务的麻烦.

他的idea的是这样的: 之前部署k8s需要定义很多的YAML文件, 这些文件都要自己管理, 而kustomize可以将这些文件管理起来, 貌似还有版本管理的能力

看一下这个图片示意, 基本上就了解.

官网地址

Nuclio functions

Nuclio 是开源的一个实时无服务器平台, 支持可插拔的事件源和数据源, 下面是它的整体架构.

目前没看出来这个Serverless的框架和Kubeflow有太多的联系, 而且FaaS战场上Nuclio也不是真正的主流, knative是google推的Serverless解决方案, 所以这个部分不多介绍了.

ksonnet

ksonnet 是一个基于jsonnet的快速简化kubernetes yaml 配置的工具,可以实现配置的复用

同时也包含一个registry 的概念,可以实现可复用组件的分发,同时支持helm

Kubeflow里面主要使用ksonnet完成安装的时候参数的配置.

具体内容可以看官网文档

Microk8s

单机K8s测试环境的库, 这个安装起来比MinikubeMiniKF更加方便

1
2
3
4
git clone https://github.com/canonical-labs/kubernetes-tools
sudo kubernetes-tools/setup-microk8s.sh
git clone https://github.com/canonical-labs/kubeflow-tools
kubeflow-tools/install-kubeflow.sh

Volcano’s scheduler

Volcano调度是华为公司贡献给社区的批处理调度器, 支持AI和大数据计算

给K8s提供以下能力:

  1. Job management extensions and improvements, e.g:
    1. Multi-pod jobs
    2. Lifecycle management extensions including suspend/resume and restart.
    3. Improved error handling
    4. Indexed jobs
    5. Task dependencies
  2. Scheduling extensions, e.g:
    1. Co-scheduling
    2. Fair-share scheduling
    3. Queue scheduling
    4. Preemption and reclaims
    5. Reservations and backfills
    6. Topology-based scheduling
  3. Runtime extensions, e.g:
    1. Support for specialized container runtimes like Singularity, with GPU accelerator extensions and enhanced security features.
  4. Other
    1. Data locality awareness and intelligent scheduling
    2. Optimizations for data throughput, round-trip latency, etc.
Kube-Batch

kube-batch是一个为kubernetes实现批量任务调度的一个调度器,主要用于机器学习大数据HPC等场景.

而Volcano正是构建在Kube-Batch之上的.

Gang Scheduler

gang-schedule是什么概念? 用用户提交一个 batch job, 这个batch job 包含100个任务,要不这100个任务全部调度成功,要么一个都调度不成功。这种all or nothing调度场景,就被称作:gang-schedule,通常用于集群资源不足的场景,比如 AI 场景下调用GPU资源

Gang Scheduler特别适合机器学习场景, 引入Vocalno和Kube-bath最终目的就是为了引入Gang-Scheduler

参考文章

Dex

dex 是一个统一认证的服务,支持各种认证协议如Ouath2 ldap等,自己可以作为一个identity provider,也可以连到别的id provider(如github)上,dex作为一个中间代理.

安装官网给出的推荐案例, 使用dex进行租户认证

Github首页

Istio

Istio是钟Service Mesh的实现, Service Mesh这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长,服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求,例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。

Istio 提供了一个完整的解决方案,通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求.

官网首页以及中文官网

完结撒花

今天把kubeflow的一些概念都整理了一下, 除了AI那块不是特别懂, 所以介绍内容比较少, 后面需要再调研一下, 再写介绍文章, 至于工程方面的都基本上算调研好了, 后续深入使用的时候再写文章介绍

后续至少需要隆重写文章介绍的有:

  1. Pipeline的文章
  2. TFJob的文章
  3. TF-Serving的文章
  4. Katib的文章
  5. Istio的文章