簡書不活躍何缓，歡迎到這里捉到我，查看更多干貨还栓。
針對Kubeflow組件較多碌廓，容易搞不清每個(gè)組件是干什么的，本文先對Kubeflow進(jìn)行一個(gè)系統(tǒng)的概括剩盒，讓大家明白各個(gè)組件分別的用處谷婆，并對組件間的關(guān)系進(jìn)行理順，幫助大家合理快速的選擇自己需要的組件辽聊，隨后會(huì)對每個(gè)組件的底層架構(gòu)和流程分別進(jìn)行詳細(xì)的介紹和剖析纪挎，供大家針對性的進(jìn)一步學(xué)習(xí)。

什么是Kubeflow跟匆？

Kubeflow是Kubernetes的機(jī)器學(xué)習(xí)工具包异袄。Kubeflow是運(yùn)行在K8S之上的一套技術(shù)棧，這套技術(shù)棧包含了很多組件玛臂，組件之間的關(guān)系比較松散烤蜕，我們可以配合起來用封孙，也可以單獨(dú)用其中的一部分。下圖是官網(wǎng)顯示Kubeflow作為在Kubernetes上安排ML系統(tǒng)組件的平臺(tái)：

Kubeflow架構(gòu)圖

Kubeflow工作流程階段圖

• 在實(shí)驗(yàn)階段枫绅，我們將基于初始假設(shè)來開發(fā)模型泉孩，并反復(fù)測試和更新模型以產(chǎn)生所需的結(jié)果：

  • 確定我們要ML系統(tǒng)解決的問題坠七。
  • 收集和分析訓(xùn)練ML模型所需的數(shù)據(jù)碳锈。
  • 選擇一個(gè)ML框架和算法，并為模型的初始版本編碼双揪。
  • 試驗(yàn)數(shù)據(jù)并訓(xùn)練模型县耽。
  • 調(diào)整模型超參數(shù)以確保最有效的處理和最準(zhǔn)確的結(jié)果句喷。

• 在生產(chǎn)階段，我們將部署執(zhí)行以下過程的系統(tǒng)：

  • 將數(shù)據(jù)轉(zhuǎn)換為訓(xùn)練系統(tǒng)所需的格式（為了確保我們的模型在訓(xùn)練和預(yù)測過程中行為始終一致兔毙，轉(zhuǎn)換過程在實(shí)驗(yàn)階段和生產(chǎn)階段必須相同）唾琼。
  • 訓(xùn)練ML模型。
  • 服務(wù)模型以進(jìn)行在線預(yù)測或以批處理模式運(yùn)行澎剥。
  • 監(jiān)督模型的性能锡溯，并將結(jié)果輸入到我們的程序中，以調(diào)整或重新訓(xùn)練模型哑姚。

由此可以看出祭饭，Kubeflow的目標(biāo)是基于K8S，構(gòu)建一整套統(tǒng)一的機(jī)器學(xué)習(xí)平臺(tái)叙量，覆蓋最主要的機(jī)器學(xué)習(xí)流程（數(shù)據(jù)->特征->建模->服務(wù)→監(jiān)控）倡蝙，同時(shí)兼顧機(jī)器學(xué)習(xí)的實(shí)驗(yàn)探索階段和正式的生產(chǎn)環(huán)境。

Kubeflow組件

Kubeflow提供了一大堆組件绞佩，涵蓋了機(jī)器學(xué)習(xí)的方方面面悠咱，為了對Kubeflow有個(gè)更直觀深入的了解蒸辆，先整體看一下Kubeflow都有哪些組件，并對Kubeflow的主要組件進(jìn)行簡單的介紹：

• Central Dashboard：Kubeflow的dashboard看板頁面
• Metadata：用于跟蹤各數(shù)據(jù)集析既、作業(yè)與模型
• Jupyter Notebooks：一個(gè)交互式業(yè)務(wù)IDE編碼環(huán)境
• Frameworks for Training：支持的ML框架
  • Chainer
  • MPI
  • MXNet
  • PyTorch
  • TensorFlow
• Hyperparameter Tuning:Katib躬贡，超參數(shù)服務(wù)器
• Pipelines：一個(gè)ML的工作流組件，用于定義復(fù)雜的ML工作流
• Tools for Serving：提供在Kubernetes上對機(jī)器學(xué)習(xí)模型的部署
  • KFServing
  • Seldon Core Serving
  • TensorFlow Serving(TFJob):提供對Tensorflow模型的在線部署眼坏，支持版本控制及無需停止線上服務(wù)拂玻、切換模型等
  • NVIDIA Triton Inference Server(Triton以前叫TensorRT)
  • TensorFlow Batch Prediction
• Multi-Tenancy in Kubeflow：Kubeflow中的多租戶
• Fairing：一個(gè)將code打包構(gòu)建image的組件
  Kubeflow中大多數(shù)組件的實(shí)現(xiàn)都是通過定義CRD來工作。目前Kubeflow主要的組件有：
• Operator是針對不同的機(jī)器學(xué)習(xí)框架提供資源調(diào)度和分布式訓(xùn)練的能力（TF-Operator宰译，PyTorch-Operator檐蚜，Caffe2-Operator，MPI-Operator沿侈，MXNet-Operator）;
• Pipelines是一個(gè)基于Argo實(shí)現(xiàn)了面向機(jī)器學(xué)習(xí)場景的流水線項(xiàng)目闯第，提供機(jī)器學(xué)習(xí)流程的創(chuàng)建、編排調(diào)度和管理缀拭，還提供了一個(gè)Web UI咳短。
• Katib是基于各個(gè)Operator實(shí)現(xiàn)的超參數(shù)搜索和簡單的模型結(jié)構(gòu)搜索的系統(tǒng)，支持并行搜索和分布式訓(xùn)練等蛛淋。超參優(yōu)化在實(shí)際的工作中還沒有被大規(guī)模的應(yīng)用咙好，所以這部分的技術(shù)還需要一些時(shí)間來成熟；
• Serving支持部署各個(gè)框架訓(xùn)練好的模型的服務(wù)化部署和離線預(yù)測褐荷。Kubeflow提供基于TFServing勾效，KFServing，Seldon等好幾種方案叛甫。由于機(jī)器學(xué)習(xí)框架很多层宫，算法模型也各種各樣。工業(yè)界一直缺少一種能真正統(tǒng)一的部署框架和方案其监。這方面Kubeflow也僅僅是把常見的都集成了進(jìn)來卒密，但是并沒有做更多的抽象和統(tǒng)一。

以上棠赛，我對Kubeflow組件進(jìn)行了系統(tǒng)的概括哮奇，來幫助我們對各個(gè)組件有一個(gè)基本的了解和整體的把握。趁熱打鐵睛约，接下來我們詳細(xì)介紹每一個(gè)組件的架構(gòu)和工作流程鼎俘。

Jupyter Notebooks

Jupyter本身包含很多組件。對于個(gè)人用戶辩涝，使用JupyterLab + Notebook就足夠了贸伐。但是如果把Jupyter當(dāng)成一個(gè)公司級的平臺(tái)來看待的話就遠(yuǎn)遠(yuǎn)不夠了。這時(shí)候需要考慮的事情就比較多了怔揩，比如多用戶捉邢、資源分配脯丝、數(shù)據(jù)持久化、數(shù)據(jù)隔離伏伐、高可用宠进、權(quán)限控制等等。而這些問題恰恰是K8S的特長藐翎。因此把Jupyter和K8S結(jié)合起來使用就非常順理成章材蹬。
JupyterHub是一個(gè)多用戶的Jupyter門戶，在設(shè)計(jì)之初就把多用戶創(chuàng)建吝镣、資源分配堤器、數(shù)據(jù)持久化等功能做成了插件模式。其工作機(jī)制如下圖所示:

JupyterHub工作機(jī)制圖

• Pod
• Deployment
• Service
• Job
• TFJob
• PyTorchJob

因此浦箱，可以直接從Kubeflow中的Jupyter notebook創(chuàng)建上述Kubernetes資源。 notebook中已預(yù)裝了Kubernetes kubectl命令行工具祠锣，可以說也是非常簡單了酷窥。
將Jupyter notebook綁定在Kubeflow中時(shí)，可以使用Fairing庫使用TFJob提交訓(xùn)練作業(yè)伴网。訓(xùn)練作業(yè)可以運(yùn)行在單個(gè)節(jié)點(diǎn)蓬推，也可以分布在同一個(gè)Kubernetes集群上，但不能在notebook pod內(nèi)部運(yùn)行澡腾。通過Fairing庫提交作業(yè)可以使數(shù)據(jù)科學(xué)家清楚地了解Docker容器化和pod分配等流程沸伏。
總體而言糕珊，Kubeflow-hosted notebooks可以更好地與其他組件集成，同時(shí)提供notebook image的可擴(kuò)展性毅糟。

Pipelines

在Kubeflow v0.1.3之后红选， pipeline已經(jīng)成為Kubeflow的核心組件。Kubeflow的目的主要是為了簡化在Kubernetes上運(yùn)行機(jī)器學(xué)習(xí)任務(wù)的流程留特，最終希望能夠?qū)崿F(xiàn)一套完整可用的流水線, 來實(shí)現(xiàn)機(jī)器學(xué)習(xí)從數(shù)據(jù)到模型的一整套端到端的過程纠脾。 而pipeline是一個(gè)工作流平臺(tái)，能夠編譯部署機(jī)器學(xué)習(xí)的工作流蜕青。所以從這個(gè)層面來說苟蹈，pipeline能夠成為Kubeflow的核心組件一點(diǎn)也不意外。
kubeflow/pipelines實(shí)現(xiàn)了一個(gè)工作流模型右核。所謂工作流慧脱，或者稱之為流水線（pipeline），可以將其當(dāng)做一個(gè)有向無環(huán)圖（DAG）贺喝。其中的每一個(gè)節(jié)點(diǎn)被稱作組件（component）菱鸥。組件處理真正的邏輯，比如預(yù)處理躏鱼，數(shù)據(jù)清洗氮采，模型訓(xùn)練等。每一個(gè)組件負(fù)責(zé)的功能不同染苛，但有一個(gè)共同點(diǎn)鹊漠，即組件都是以Docker鏡像的方式被打包，以容器的方式被運(yùn)行的茶行。
下圖顯示了Kubeflow Pipelines UI中管道的運(yùn)行時(shí)執(zhí)行圖：

Pipeline運(yùn)行時(shí)執(zhí)行圖

Pipelines架構(gòu)

下圖是官方提供的Kubeflow Pipelines架構(gòu)圖：

pipelines架構(gòu)圖

• Python SDK: 用于創(chuàng)建kubeflow pipelines組件的特定語言（DSL）伯铣。
• DSL compiler: 將Python代碼轉(zhuǎn)換成YAML靜態(tài)配置文件（DSL編譯器 ）艾凯。
• Pipeline Web Server: pipeline的前端服務(wù)，它收集各種數(shù)據(jù)以顯示相關(guān)視圖：當(dāng)前正在運(yùn)行的pipeline列表懂傀，pipeline執(zhí)行的歷史記錄趾诗，有關(guān)各個(gè)pipeline運(yùn)行的調(diào)試信息和執(zhí)行狀態(tài)等。
• Pipeline Service： pipeline的后端服務(wù)，調(diào)用K8S服務(wù)從YAML創(chuàng)建 pipeline運(yùn)行恃泪。
• Kubernetes Resources: 創(chuàng)建CRDs運(yùn)行 pipeline郑兴。
• Machine Learning Metadata Service: 用于監(jiān)視由Pipeline Service創(chuàng)建的Kubernetes資源，并將這些資源的狀態(tài)持久化在ML元數(shù)據(jù)服務(wù)中(存儲(chǔ)任務(wù)流容器之間的input/output數(shù)據(jù)交互）贝乎。
• Artifact Storage: 用于存儲(chǔ)Metadata和Artifact情连。Kubeflow Pipelines將元數(shù)據(jù)存儲(chǔ)在MySQL數(shù)據(jù)庫中，將工件存儲(chǔ)在Minio服務(wù)器或Cloud Storage等工件存儲(chǔ)中览效。
• Orchestration Controllers：任務(wù)編排却舀，比如 Argo Workflow控制器，它可以協(xié)調(diào)任務(wù)驅(qū)動(dòng)的工作流锤灿。

Pipelines工作原理

流水線的定義可以分為兩步挽拔，首先是定義組件，組件可以從鏡像開始完全自定義但校。這里介紹一下自定義的方式：首先需要打包一個(gè)Docker鏡像螃诅，這個(gè)鏡像是組件的依賴，每一個(gè)組件的運(yùn)行状囱，就是一個(gè)Docker容器术裸。其次需要為其定義一個(gè)python函數(shù)，描述組件的輸入輸出等信息亭枷，這一定義是為了能夠讓流水線理解組件在流水線中的結(jié)構(gòu)袭艺，有幾個(gè)輸入節(jié)點(diǎn)，幾個(gè)輸出節(jié)點(diǎn)等叨粘。接下來組件的使用就與普通的組件并無二致了猾编。
實(shí)現(xiàn)流水線的第二步，就是根據(jù)定義好的組件組成流水線宣鄙，在流水線中袍镀，由輸入輸出關(guān)系會(huì)確定圖上的邊以及方向默蚌。在定義好流水線后冻晤，可以通過 python中實(shí)現(xiàn)好的流水線客戶端提交到系統(tǒng)中運(yùn)行。
雖然kubeflow/pipelines的使用略顯復(fù)雜绸吸，但它的實(shí)現(xiàn)其實(shí)并不麻煩鼻弧。整個(gè)的架構(gòu)可以分為五個(gè)部分，分別是ScheduledWorkflow CRD以及其operator流水線前端锦茁，流水線后端攘轩，Python SDK和persistence agent。

• ScheduledWorkflow CRD擴(kuò)展了argoproj/argo的Workflow定義码俩。這也是流水線項(xiàng)目中的核心部分度帮，它負(fù)責(zé)真正地在Kubernetes上按照拓?fù)湫騽?chuàng)建出對應(yīng)的容器完成流水線的邏輯。
• Python SDK負(fù)責(zé)構(gòu)造出流水線，并且根據(jù)流水線構(gòu)造出 ScheduledWorkflow的YAML定義笨篷，隨后將其作為參數(shù)傳遞給流水線系統(tǒng)的后端服務(wù)瞳秽。
• 后端服務(wù)依賴關(guān)系存儲(chǔ)數(shù)據(jù)庫（如MySQL）和對象存儲(chǔ)（如S3），處理所有流水線中的CRUD請求率翅。
• 前端負(fù)責(zé)可視化整個(gè)流水線的過程练俐，以及獲取日志，發(fā)起新的運(yùn)行等冕臭。
• Persistence agent負(fù)責(zé)把數(shù)據(jù)從Kubernetes Master的etcd中sync到后端服務(wù)的關(guān)系型數(shù)據(jù)庫中腺晾，其實(shí)現(xiàn)的方式與CRD operator類似，通過informer來監(jiān)聽 Kubernetes apiserver對應(yīng)資源實(shí)現(xiàn)辜贵。

Pipelines提供機(jī)器學(xué)習(xí)流程的創(chuàng)建悯蝉、編排調(diào)度和管理，還提供了一個(gè)Web UI念颈。這部分主要基于Argo Workflow泉粉。我相信這會(huì)是Kubeflow后續(xù)要大力發(fā)展的部分。

Fairing

Kubeflow Fairing是一個(gè)Python軟件包榴芳，可輕松在Kubeflow上訓(xùn)練和部署ML模型嗡靡。Fairing還可以擴(kuò)展為在其他平臺(tái)上進(jìn)行訓(xùn)練或部署。目前窟感，Fairing已擴(kuò)展為可在Google AI Platform上進(jìn)行訓(xùn)練讨彼。
Fairing簡化了在混合云環(huán)境中構(gòu)建，訓(xùn)練和部署機(jī)器學(xué)習(xí)（ML）訓(xùn)練job的過程柿祈。通過使用Fairing并添加幾行代碼哈误，可以直接從Jupyter notebook在本地或在云中使用Python代碼運(yùn)行ML訓(xùn)練作業(yè)。訓(xùn)練工作完成后躏嚎，可以使用Fairing將訓(xùn)練后的模型部署為預(yù)測端點(diǎn)蜜自。
上面介紹了Kubeflow代碼編輯器Jupyter Notebooks，用于將代碼打包構(gòu)建image的Fairing卢佣，以及工作流組件Pipelines核心組件重荠，下面我們再介紹用來調(diào)參的Katib和發(fā)布部署服務(wù)的KFServing。

Katib

在了解katib的處理流程之前虚茶，先介紹下katib目前有哪些組件：

• Experiment Controller：提供對Experiment CRD的生命周期管理戈鲁。
• Trial Controller：提供對Trial CRD的生命周期管理。
• Suggestions：以Deployment的方式部署嘹叫，用Service方式暴露服務(wù)婆殿，提供超參數(shù)搜索服務(wù)。目前有隨機(jī)搜索罩扇，網(wǎng)格搜索婆芦，貝葉斯優(yōu)化等。
• Katib Manager：一個(gè)GRPC server，提供了對Katib DB的操作接口消约，同時(shí)充當(dāng)Suggestion與 Experiment之間的代理癌压。
• Katib DB：數(shù)據(jù)庫。其中會(huì)存儲(chǔ)Trial和Experiment荆陆，以及Trial的訓(xùn)練指標(biāo)滩届。目前默認(rèn)的數(shù)據(jù)庫為 MySQL。

Katib架構(gòu)

Katib架構(gòu)圖

Katib工作原理

當(dāng)一個(gè)Experiment被創(chuàng)建的時(shí)候被啼，Experiment Controller會(huì)先通過Katib Manager在Katib DB中創(chuàng)建一個(gè)Experiment對象帜消，并且打上Finalizer表明這一對象使用了外部資源（數(shù)據(jù)庫）。隨后浓体，Experiment Controller會(huì)根據(jù)自身的狀態(tài)和關(guān)于并行的定義泡挺，通過Katib Manager提供的GRPC接口，讓Manager通過 Suggestion提供的GRPC接口獲取超參數(shù)取值命浴，然后再轉(zhuǎn)發(fā)給Experiment Controller娄猫。在這個(gè)過程中，Katib Manager是一個(gè)代理的角色生闲，它代理了Experiment Controller對Suggestion的請求媳溺。拿到超參數(shù)取值后，Experiment Controller會(huì)根據(jù)Trial Template和超參數(shù)的取值碍讯，構(gòu)造出Trial的定義悬蔽，然后在集群中創(chuàng)建它。
Trial被創(chuàng)建后捉兴，與Experiment Controller的行為類似蝎困，Trial Controller同樣會(huì)通過Katib Manager在Katib DB中創(chuàng)建一個(gè)Trial對象。隨后會(huì)構(gòu)造出期望的Job（如batchv1 Job倍啥，TFJob禾乘，PyTorchJob等）和Metrics Collector Job，然后在集群上創(chuàng)建出來虽缕。這些Job運(yùn)行結(jié)束后始藕，Trial Controller會(huì)更新Trial的狀態(tài)，進(jìn)而Experiment Controller會(huì)更新Experiment的狀態(tài)彼宠。
然后Experiment會(huì)繼續(xù)下一輪的迭代鳄虱。之前的Trial已經(jīng)被訓(xùn)練完成弟塞，而且訓(xùn)練的指標(biāo)已經(jīng)被收集起來了凭峡。Experiment會(huì)根據(jù)配置，判斷是否要再創(chuàng)建新的Trial决记，如果需要?jiǎng)t再重復(fù)之前的流程摧冀。
下圖是從網(wǎng)絡(luò)上（知乎@高策）找到的Katib競品對比分析圖，可供參考：

Katib競品對比分析圖

KFServing

對于深度學(xué)習(xí)的產(chǎn)品化來說椒惨，訓(xùn)練只是手段不是目的缤至，目的是將通過訓(xùn)練產(chǎn)生的模型放到手機(jī)的程序里或者互聯(lián)網(wǎng)的應(yīng)用中，用于語音或者文字的識(shí)別等應(yīng)用場景中康谆。

如何發(fā)布服務(wù)

KFServing/Seldon Core Serving對比圖

KFSerivng所處平臺(tái)架構(gòu)位置示意圖

生產(chǎn)模型部署過程示意圖

基于Kubeflow的ML流程圖

其它干貨（必備技能）：

1. Kubeflow/tf-operator源碼分析
2. 從原理到實(shí)戰(zhàn)惧蛹，徹底搞懂Nginx扇救！
3. 從原理到實(shí)戰(zhàn)，徹底搞懂Nginx（高級篇）
4. Python中的三個(gè)”黑魔法“與”騷操作“