聽聞 kubernetes，快速瞭解一番

 

看到 各位 大廠都在用這個，  而本人最可能是用yarn 作些ML的事情，   趕快了解一下， 先掃盲記錄一下。

 

一.名稱趣聞

kubernetes縮寫爲k8s， 阿哈 ，原來是：k8s，意思就是k後面跳過8個字母后到s，就變成了k8s。  kubernetes /kubə'netis/，重音在第三個音節，讀音：庫伯耐踢死

難免說這些硅谷的人呀，起名有一套！

它是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單而且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。在生產環境中部署一個應用程序時，一般要部署該應用的多個實例以便對應用請求進行負載均衡。

在Kubernetes中，咱們能夠建立多個容器，每一個容器裏面運行一個應用實例，而後經過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不須要運維人員去進行復雜的手工配置和處理。

 

 

2、爲啥會出現這個東西？

「」「

  在建設分佈式訓練平臺的過程當中，咱們和機器學習的各個業務方，包括搜索推薦、圖像算法、交易風控反做弊等，進行了深刻溝通。

   那麼，對算法工程師是如何的？ 從調查中發現，算法業務方每每專一於模型和調參，而工程領域是他們相對薄弱的一個環節。

   建設一個強大的分佈式平臺，整合各個資源池，提供統一的機器學習框架，將能大大加快訓練速度，提高效率，帶來更多的可能性，此外還有助於提高資源利用率。

」「」

   方便人的工具纔是好東西！

   

  

傳統的應用部署方式是經過插件或腳原本安裝應用。這樣作的缺點是應用的運行、配置、管理、全部生存週期將與當前操做系統綁定，這樣作並不利於應用的升級更新/回滾等操做，固然也能夠經過建立虛擬機的方式來實現某些功能，可是虛擬機很是重，並不利於可移植性。

新的方式是經過部署容器方式實現，每一個容器之間互相隔離，每一個容器有本身的文件系統 ，容器之間進程不會相互影響，能區分計算資源。相對於虛擬機，容器能快速部署，因爲容器與底層設施、機器文件系統解耦的，因此它能在不一樣雲、不一樣版本操做系統間進行遷移。

容器佔用資源少、部署快，每一個應用能夠被打包成一個容器鏡像，每一個應用與容器間成一對一關係也使容器有更大優點，使用容器能夠在build或release 的階段，爲應用建立容器鏡像，由於每一個應用不須要與其他的應用堆棧組合，也不依賴於生產環境基礎結構，這使得從研發到測試、生產能提供一致環境。相似地，容器比虛擬機輕量、更「透明」，這更便於監控和管理。

 

 

說的是否是太書面了 ？ 看看其餘人如何說的:

痛點一：對算力的需求問題

1. 公司目前的 Yarn 不支持 GPU 資源管理，雖然近期版本已支持該特性，但存在穩定性風險。

2. 缺少資源隔離和限制，同節點的任務容易出現資源衝突。

3. 監控信息不完善。在發生資源搶佔時，每每沒法定位根本緣由。

4. 缺乏彈性能力，目前資源池是靜態的，若是能借助公有云的彈性能力，在業務高峯期提供更大的算力，將能更快的知足業務需求。

痛點二：人肉管理的成本很高

        人肉化的管理主要包含了部署和訓練任務管理兩大方面，越多的人肉管理就是越多的成本呀。

        部署：

             不一樣的訓練任務對 Python 的版本和依賴徹底不一樣，好比有些模型使用 Python 2.7，有些使用 Python 3.3，有些使用 TensorFlow 1.8，有些使用 TensorFlow 1.11 等等，很是容易出現依賴包衝突的問題。雖然沙箱能在必定程度上解決這問題，可是也帶來了額外的管理負擔。還有， 不一樣 GPU 機型依賴的 Nvidia 驅動也不一樣，較新的卡，好比 V100 所依賴的版本更高。人肉部署還須要管理和維護多個不一樣的驅動版本。  等等

       管理：

            啓動訓練任務時，  須要手動查看 / 評估資源的剩餘可用狀況，手動指定 PS 和 Worker 的數量，管理配置並進行服務發現。這些都給業務方帶來了很大的負擔。而，Kubernetes 提供了生命週期管理的 API，用戶基於 API 便可一鍵式完成訓練任務的增刪改查，避免人工 ssh 的各類繁瑣操做，能夠大幅提高用戶體驗和效率。

 

 

痛點三：監控的缺失

         監控也是分佈式訓練重要的一環，它是性能調優的重要依據。

        例如以下的描述：    

「」「」

好比在 PS-Worker 的訓練框架下，咱們須要爲每一個 PS/Worker 配置合適的 GPU/CPU/Memory，並設置合適的 PS 和 Worker 數量。若是某個參數配置不當，每每容易形成性能瓶頸，影響總體資源的利用率。好比當 PS 的網絡很大時，咱們須要增長 PS 節點，並對大參數進行 partition；當 worker CPU 負載太高時，咱們應該增長 Worker 的核數。

早期版本的 Hadoop 和 Yarn 並不支持 GPU 的資源可視化監控，而 Kubernetes 已擁有很是成熟監控方案 Prometheus，它能週期採集 CPU，內存，網絡和 GPU 的監控數據，即每一個 PS/Worker 的資源使用率都能獲得詳細的展現，爲優化資源配置提供了依據。事實上，咱們也是經過監控信息爲不一樣的訓練任務分配合適的資源配置，使得在訓練速度和總體的吞吐率上達到一個較好的效果。

「」

 

痛點四：資源隔離較弱

        早期的機器學習平臺基於 Yarn 的 Angel 和 XLearning，因爲 Yarn 缺少對實例之間的資源隔離，咱們在內存，網絡，磁盤等均遇到不一樣程度的問題。

        因爲 Yarn 沒有對任務的內存進行隔離，因此，業務方經常因對內存資源估計不許而致使 worker 的進程 OOM。因爲全部的進程都共用宿主機的 IP，很容易形成端口衝突，此外磁盤 IO 和網絡 IO 也很容易被打爆。

 

 三. kubernetes做爲機器學習基礎平臺

        Kubeflow 旨在支持多種機器學習框架運行在 Kubernetes 之上，好比 Tensorflow, Pytorch, Caffe 等常見框架。它包含了 operator、pipeline、超參數調優、serving 等諸多模塊。它經過提供對應的 operator，基於 Kubernetes 的 Pod/headless Service 等基礎資源爲框架提供與之相配的更高層次的資源。好比 tf-operator 爲 Tensorflow 提供了 job 維度的生命週期管理能力，以知足 Tensorflow 分佈式訓練的資源和拓撲需求，達到了一鍵式部署 Tensorflow 訓練任務的效果。

 

 

  

 

 4、繼續瞭解一下 

Kubernetes 組件

• 1Master 組件
• 1.1kube-apiserver
• 1.2ETCD
• 1.3kube-controller-manager
• 1.4cloud-controller-manager
• 1.5kube-scheduler
• 1.6插件 addons
• 1.6.1DNS
• 1.6.2用戶界面
• 1.6.3容器資源監測
• 1.6.4Cluster-level Logging
• 2節點（Node）組件
• 2.1kubelet
• 2.2kube-proxy
• 2.3docker
• 2.4RKT
• 2.5supervisord
• 2.6fluentd

 

Master 組件

Master組件提供集羣的管理控制中心。

Master組件能夠在集羣中任何節點上運行。可是爲了簡單起見，一般在一臺VM/機器上啓動全部Master組件，而且不會在此VM/機器上運行用戶容器。請參考構建高可用羣集以來構建multi-master-VM。

kube-apiserver

kube-apiserver用於暴露Kubernetes API。任何的資源請求/調用操做都是經過kube-apiserver提供的接口進行。請參閱構建高可用羣集。

ETCD

etcd是Kubernetes提供默認的存儲系統，保存全部集羣數據，使用時須要爲etcd數據提供備份計劃。

kube-controller-manager

kube-controller-manager運行管理控制器，它們是集羣中處理常規任務的後臺線程。邏輯上，每一個控制器是一個單獨的進程，但爲了下降複雜性，它們都被編譯成單個二進制文件，並在單個進程中運行。

這些控制器包括：

• 節點（Node）控制器。
• 副本（Replication）控制器：負責維護系統中每一個副本中的pod。
• 端點（Endpoints）控制器：填充Endpoints對象（即鏈接Services&Pods）。
• Service Account和Token控制器：爲新的Namespace建立默認賬戶訪問API Token。

cloud-controller-manager

雲控制器管理器負責與底層雲提供商的平臺交互。雲控制器管理器是Kubernetes版本1.6中引入的，目前仍是Alpha的功能。

雲控制器管理器僅運行雲提供商特定的（controller loops）控制器循環。能夠經過將--cloud-providerflag設置爲external啓動kube-controller-manager ，來禁用控制器循環。

cloud-controller-manager 具體功能：

• 節點（Node）控制器
• 路由（Route）控制器
• Service控制器
• 卷（Volume）控制器

kube-scheduler

kube-scheduler監視新建立沒有分配到Node的Pod，爲Pod選擇一個Node。

插件 addons

插件（addon）是實現集羣pod和Services功能的。Pod由Deployments，ReplicationController等進行管理。Namespace 插件對象是在kube-system Namespace中建立。

DNS

雖然不嚴格要求使用插件，但Kubernetes集羣都應該具備集羣 DNS。

羣集 DNS是一個DNS服務器，可以爲 Kubernetes services提供 DNS記錄。

由Kubernetes啓動的容器自動將這個DNS服務器包含在他們的DNS searches中。

用戶界面

kube-ui提供集羣狀態基礎信息查看。

容器資源監測

容器資源監控提供一個UI瀏覽監控數據。

Cluster-level Logging

Cluster-level logging，負責保存容器日誌，搜索/查看日誌。

節點（Node）組件

節點組件運行在Node，提供Kubernetes運行時環境，以及維護Pod。

kubelet

kubelet是主要的節點代理，它會監視已分配給節點的pod，具體功能：

• 安裝Pod所需的volume。
• 下載Pod的Secrets。
• Pod中運行的 docker（或experimentally，rkt）容器。
• 按期執行容器健康檢查。
• Reports the status of the pod back to the rest of the system, by creating a mirror podif necessary.
• Reports the status of the node back to the rest of the system.

kube-proxy

kube-proxy經過在主機上維護網絡規則並執行鏈接轉發來實現Kubernetes服務抽象。

docker

docker用於運行容器。

RKT

rkt運行容器，做爲docker工具的替代方案。

supervisord

supervisord是一個輕量級的監控系統，用於保障kubelet和docker運行。

fluentd

fluentd是一個守護進程，可提供cluster-level logging.。

 

 ha , 好複雜， 那麼 如何將其玩轉起來， 額， 這比較多了， 仍是看這位老兄的吧， 寫的挺多的，

   http://baijiahao.baidu.com/s?id=1602795888204860650&wfr=spider&for=pc

 

 

 參考：

https://mp.weixin.qq.com/s/cQNZnswSiKa8O0SkAiuRkQ