Kubeflow:容器機器學習實戰

Transcript

1. Kubeflow︓容器機器學習實戰 Machine Learning Toolkit for Kubernetes
2. About Us 白凱仁(Kyle Bai) • Interested in emerging technologies. • COSCUP, Kubernetes Day and OpenStack Day Speaker. • OpenStack and Kubernetes Projects Contributor(100+ Contributions). • Certified Kubernetes Administrator. @kairen(k2r2.bai@gmail.com) https://kairen.github.io/
3. About Us 林義洋(Frank Lin) • M.S student in PU. • Intern in Industrial Technology Research Institute(ITRI). • COSCUP 2018 Staff. • AI Research Center in CGU. @yylin1(yylin1@gmail.com) https://medium.com/@frank.yylin
4. Agenda Today I would like to talk about • An overview of Kubernetes • Kubernetes Package Manager(以 ksonnet 為例) • An introduction to Kubeflow • Let's go to play Kubeflow • Q & A
5. An overview of Kubernetes • Why Kubernetes? • Kubernetes 架構與概念 • Kubernetes 抽象資源概念 • Kubernetes 有狀態服務部署與管理
6. Why Kubernetes?
7. 老方式: Bare-metal Machines • 沒有隔離 • 沒有命名空間 • 共用常見的函式庫 • 高耦合的應用程式與作業系統 kernel libs app app app app
8. 老方式: Virtual Machines • 隔離性高 • 效能會損失 • 同樣有高耦合的應用程式與作業系統 • 多虛擬機管理效率差 • 啟動時間慢 • 系統映像檔容量較肥 • 粒度粗 app libs kernel libs app app kernel app libs libs kernel kernel 作業系統層級
9. 新方式: Containers(OS-Level Virtualization) libs app kernel libs app libs app libs app • 效能佳 • 透過 namespace 隔離網路、UID 等 • 與 OS Kernel 高耦合 • 啟動時間快 • 應用映像檔容量較小(小至 10 MB)︐攜帶性佳 • 粒度細︐利用密度提升 應用程式層級
10. 新方式: Hpyervisor-based Containers • 取虛擬機與容器之間的特性平衡 • 輕量的虛擬機環境 https://katacontainers.io/
11. Docker Docker 利用 Linux 核心中的資源分離機制︐ 如 cgroups、namespace(Mount, UTS, IPC, PID 等)︐對處理程式進行封裝隔離。屬於作 業系統層虛擬化(OS Level virtualization)。
12. Open Container Initiative (OCI) OCI(The Open Container Initiative)是由多家頂尖 IT 公司共同組成的組織︐其目標是 制定 Container 的標準規範︐以利 Container 發展。該標準讓開發者打包、簽署應用 程式︐並且可以自由選用不同的 Container runtime 環境外︐在近日則更一步延伸。 而目前基於 OCI 標準 runtime 的 runC 已經是許多容器引擎的基礎。
13. Problems with standalone Docker 在單節點的主機上執行一或多組 Continer 應用程式︐將面臨單點故障問題(SPOF)與 擴展限制問題(Limited scalability)。
14. 因此我們需要一個好的系統來指揮
15. Container orchestration system
16. Google Trends
17. Google Container Engine
18. Amazon Elastic Container Service
19. Azure Kubernetes Service
20. Docker: Now Powered by Kubernetes
21. Incubator by Foundation 雲端原生運算基金會(Cloud Native Computing Foundation︐CNCF)的願景是建立並 推動採用為現代分散式系統環境︐來優化的新運算模式︐該基金會也提供了相關專 案的一致性認證計劃︐以此推動穩定版 Kubernetes 等其他專案的部署與應用。
22. CNCF Member
23. Kubernetes Kubernetes 是 Google 開源的容器(Container)分散式管理系統︐是 Google Borg 〸幾 年以來大規模應用容器技術的經驗累積和昇華的一個重要成果︐是建於 OCI Runtime 之上的容器叢集排程系統︐簡稱為 k8s( )。 Stars 40,350+ Commits 68,981+ Contributors 1,771+ “Kubernetes is becoming the Linux of the cloud” Jim Zemlin, Linux Foundation
24. Kubernetes 特性概觀 Kubernetes 管理跨區域與主機的容器節點︐提供基本部署、維運、管理︐以及執行 各項應用程式︐並具備多種特性。 資源監控 Monitoring 滾動升級 Rolling-update ⾼高可靠性 High-availability ⾃自我修復 Self-healing 雲端⽀支援 Cloud Provider 持久性儲存 Persistent Volumes 組態檔案 Configmap 安全性 Secret
25. 適合 Microservices 架構 Kubernetes 架構設計非常適合在微服務(Microservices)軟體架構︐透過多個容器 (Container)與負載平衡等來組成系統。
26. https://github.com/ramitsurana/awesome-kubernetes#installers https://caylent.com/50-useful-kubernetes-tools Other Kubespray RKE Kops Kube-aws Typhoon Kubicorn Docker for K8s LinuxKit Matchbox KubeNow Bootkube kubeadm-dind-cluster Kubernetes 部署工具 Minikube PKS https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit#gid=0
27. Minikube Kubernetes 社區官方維護的開源工具︐非常適合入門開發者使用︐Minikube 會透過 建立單節點虛擬機來部署 Kubernetes︐以提供開發者方便測試。 • 簡單部署與刪除節點(採用 kubeadm 作為 bootstrapper) • 支援多種 VM Driver︐如 Virtual Box、Hyper-V 與 KVM 等等 • 支援多種 Kubernetes Addons ︐如 Dashboard、NVIDIA GPU 等等 • 支援 Mounting Host 目錄 https://github.com/kubernetes/minikube
28. Kubeadm Kubeadm 同樣是由 Kubernetes 社區維護的工具︐與 Minkube 不同的是其原始碼被 包含在 Kubernetes 核心專案中。Kubeadm 主要是幫助建立最佳實踐的最小叢集。 • 適合部署多節點叢集︐也能支援 HA 與 Self-hosting 部署方式 • 支援以 Config 方式來描述部署的叢集 • 預設會支援 Kubernetes 新版本一些重點特性 • 許多部署工具背後也採用 kubeadm https://github.com/kubernetes/kubernetes/tree/master/cmd/kubeadm
29. Kubernetes The Hard Way http://bit.ly/2uqsIAn
30. Kubernetes System layers Nucleus: API and Execution Application Layer: Deployment and Routing Governance Layer: Automation and Policy Enforcement Interface Layer: Client Libraries and Tools Ecosystem Container Runtime Network Plugin Volume Plugin Image Registry Cloud Provider Identity Provider Device Plugin
31. Built on standards(plugins) Kubernetes 的容器引擎、網路與儲存都是透過標準化的規範來進行實作︐開發者與 供應商只需要依據規範的介面進行開發對應功能︐就能夠與 Kubernetes 進行整合。
32. Container Runtime Interface(CRI) CRI 是 Kubernetes 社區提出的規範︐由於隨著不同的容器引擎推成出新︐ Kubernetes 已不在只是管理 Docker 的容器︐CRI 將 Kubernetes 與具體容器實現進 行解耦︐來增加 Kubernetes 的擴展。 https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/server/streaming
33. Container Network Interface(CNI) CNI 是 CNCF 容器網路規範︐更是 Kubernetes 網路插件基礎。其思想為在 Container Runtime 建立時︐並建立 network namespace︐之後呼叫 CNI 插件來設定 netns 網 路︐最後提供給容器使用。 https://github.com/containernetworking
34. Container Storage Interface(CSI) CSI 在近期 v1.11 版本中︐已經進入 Alpha 階段。其目標是制定一個標準容器儲存介面 來提供給 SP(儲存供應商)快速開發插件來在 Container Orchestration (CO) 系統上使 用。 https://github.com/kubernetes-csi
35. Kubernetes Device Plugins Device Plugins 是 Kubernetes v1.8 加入的特性︐目標是以通用介面提供第三方設備廠 商開發插件化方式將裝置(如 GPU)資源串接至 Kubernetes 上︐並且提供容器 Extended Resources。 目前關注度高的 Device plugins︓ • NVIDIA device plugin for Kubernetes • AMD device plugin for Kubernetes • Solarflare Device Plugin
36. Device Plugin Architecture Device plugin 主要實作為以下︓ • Registration • ListAndWatch • Allocate: • PreStartContainer
37. Kubernetes 架構與概念
38. Kubernetes Architecture UI CLI API Users Master Nodes etcd scheduler controllers apiserver kubelet kube-proxy add-ons container runtime
39. Kubernetes Architecture Kubernetes 屬於分散式架構系統︐主要由三種節點角色組成︓ • Masters:主要工作為提供 API 與管理工作節點︐可視為主節點。 • Nodes(Minions) : 執行容器實例的節點︐上面會執行許多容器。 • etcds︓主要為 Kubernetes 的叢集資訊儲存與服務發現功能。
40. Kubernetes Masters • kube-apiserver: 提供 REST APIs︐包含授 權、認證與狀態儲存等。 • kube-controller-manager:所有叢集資源 控制功能都是透過控制管理器來操作。 • kube-scheduler:負責整個分散式系統的 資源排程︐透過一系列演算法來分配容器 到最佳節點。
41. Kubernetes Nodes • kubelet: 與 API 溝通︐並負責管理的映 像檔、容器與資料 Volume等操作。 • kube-proxy: 讓服務可以曝露給外部存 取的代理元件︐支援 iptables 與 ipvs。 • Container runtime: 基於 OCI Container Runtime 來執行應用程式容器實例。
42. Kubernetes API driven Kubernetes API 是以 JSON 作為其主要序列化模型的 HTTP API︐且能夠支援協定快取 區︐並用於叢集內部溝通使用。 • 通過 API 完成節點之間溝通進⾏行行 CRUD 操作，或是授權、認證與註冊等。 • Kubernetes 有明確定義與規範 API。⽀支援 OpenAPI。 • 使⽤用 gRPC 進⾏行行 Remote Procedure Call。 • 可擴展的 API。 • CRD(Custom Resource Definitions) • API server aggregation • Custom resources, controllers and apiservers
43. Kubernetes API 首先透過 kubectl 執行一下指令︓ $ kubectl create clusterrolebinding anonymous-become-admin \ --clusterrole=cluster-admin --user=system:anonymous 接著透過瀏覽器開啟 https://master_ip:8443 來查看 APIs。 /apis/apps/v1/namespaces/default/deployments/nginx Group Verb Resource https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/ batch police storage create update delete pod service nodes
44. Kubernetes API • API Group: 是邏輯上相關的種類集合︐如 Job 與 CronJob 都屬於批次處理功能相 關。 • Version: 每個 API Group 存在多個版本︐這些版本區分不同穩定度層級︐一般功能 會從 v1alpha1 升級到 v1beta1︐然後在 v1 成為穩定版本。 • Resource: 資源是透過 HTTP 發送與檢索的系統實體︐其以 JSON 來表示。可以是 單一或者多個資源。
45. API Spaces
46. API Levels 在 Kubernetes 中︐不同版本的 API 意味著不同層級穩定度與支援度︓ • Alpha level:在預設下是大多情況禁止使用狀態︐這些功能有可能隨時在下一版本被 遺棄︐因此只適用於測試用︐Example: v1alpha1。 • Beta level:在這級別一般預設會啟用︐這表示該功能已經通過很好的測試項目︐但 是物件內容可能會在後續版本或穩定版本發生變化。Example: v1beta2。 • Stable level:在這級別表示該功能已經穩定︐會很長的時間一直存在。Example: v1。
47. API - Resource ObjectMeta 該物件描述了資源的詮釋資料︐裡面也會包 含 End User 與系統的更新資訊。 • 名稱(metadata.name) • 類型(kind) • API 版本(apiVersion) • 標籤(metadata.labels) • 註釋(metadata.annotations)
48. API - ResourceSpec 這邊主要是由使用者定義以及描述所需的資 源狀態︐在建立與更新抽象物件時都會填寫 此內容。 • 容器資訊(spec.containers) • 儲存資訊(spec.volumes) • 容器容忍資訊(spec.tolerations)
49. API - ResourceStatus 這是由 Kubernetes 系統處理的抽象物件當 前狀態資訊︐通常不會由使用者更改。 • 抽象物件執行狀態(spec.phase) • 所屬容器狀態(spec.containerStatuses) • 其他相關資訊
50. Validation and Admission Admission:透過驗證叢集的全域約束來檢查是否建立或更新 API 物件︐在 Kubernetes 中有很多這樣功能。幾個約束範例︓ • NamespaceLifecycle: 如果命名空間不存在︐則拒絕該所有請求。 • ResourceQuota:為叢集的當前使用者強制執行額度限制。 Validation:檢查傳入的物件(建立與更新過程)的格式是否符合。例如︓ • 檢查所有的字串是否是有效的格式。 • 檢查是否有設定矛盾欄位。
51. Validation and Admission ResourceQuota NamespaceLifecycle RBAC Webhook X509 Client Certs Bootstrap Tokens
52. Governance Layer: Automation and Policy Enforcement (APIs optional and pluggable) Application Layer: Deployment and Routing (APIs required and pluggable) Nucleus: API and Execution (APIs required and not pluggable) CronJob batch/ v2alpha1 Job batch/v1 Deployment apps/v1 DaemonSet apps/v1 Pod core/v1 ReplicaSet apps/v1 StatefulSet apps/v1 ReplicationController core/v1 Endpoints core/v1 Ingress extensions/v1beta1 Service core/v1 ConfigMap core/v1 Secret core/v1 PersistentVolumeClaim core/v1 StorageClass storage/v1 ControllerRevision apps/v1 Event core/v1 LimitRange core/v1 ValidatingWebHookConfiguration admissionregistration/v1alpha1 HorizontalPodAutoscaler autoscaling/v1 APIService apiregistration/v1beta1 PodDisruptionBudget policy/v1beta1 PodPreset settings/v1alpha1 PodSecurityPolicy extensions/v1beta1 CertificateSigningRequest certificates/v1beta1 ClusterRole rbac/v1beta1 ClusterRoleBinding rbac/v1beta1 LocalSubjectAccessReview authorization/v1 Namespace core/v1 Node core/v1 PersistentVolume core/v1 ResourceQuota core/v1 Role rbac/v1beta1 RoleBinding rbac/v1beta1 SelfSubjectAccessReview authorization/v1 ServiceAccount core/v1 SubjectAccessReview authorization/v1 NetworkPolicy networking/v1 ComponentStatus core/v1 PriorityClass scheduling/v1alpha1 ClusterServiceBroker servicecatalog/v1beta1 ClusterServiceClass servicecatalog/v1beta1 ClusterServicePlan servicecatalog/v1beta1 ServiceInstance servicecatalog/v1beta1 ServiceBinding servicecatalog/v1beta1 MutatingWebHookConfiguration admissionregistration/v1alpha1 SelfSubjectRulesReview authorization/v1 TokenReview authentication/v1 CustomResourceDefinition apiextensions/v1beta1
53. Controller - Control loops • 觀察實際狀態 • 找出抽象資源更新差異 • 驅使當前狀態 → 期望狀態 • 調解系統抽象資源狀態 • 支援各種資源的 Controller︐如 Deployments、 ReplicaSets 等等 observe diff act
54. Scheduler 負責將 Pod 排程到特定節點上︐其工作如下︓ • 你建立一個 Pod • Scheduler 收到你建立的新 Pod 沒有被分配節點的通知 • Scheduler 將節點資訊塞到 Pod 中 • Kubelet 收到 Pod 更新︐發現裡面(Pod.Spec.NodeName)有自己名稱︐因此透過 Runtime 啟 動容器
55. 進一步探討 Scheduler 流程 ❶ ❶ Watch for pods that: • Are in PENDING phase • Have no Pod.Spec.NodeName assigned • Are explicitly requesting our scheduler (default otherwise)
56. 進一步探討 Scheduler 流程 ❷ ❷ Node selection algorithm(Filter and Rank): • PodFitsHostPorts • … • LeastRequestedPriority • …
57. 進一步探討 Scheduler 流程 ❸ ❸ Post Pod <===> Node binding to the API Server
58. 進一步探討 Scheduler 流程 ❹ ❹ Profit!!!
59. Scheduler 選取節點流程 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6
60. Scheduler 選取節點流程 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Predicate MatchNodeSelector PodSelectorMatches NoDiskConflict …
61. Scheduler 選取節點流程 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Predicate Host 2 Host 3 Host 4 Host 5 Priority Node Affinity Priority Selector Spread Priority Image Locality Priority …
62. Scheduler 選取節點流程 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Host 1 Host 2 Host 3 Host 4 Host 5 Host 6 Predicate Host 2 Host 3 Host 4 Host 5 Priority Host 3 Select
63. Kubernetes 抽象資源概念
64. Kubernetes Application • 所有使用者將透過抽象資源組合來執行應用程式 • 啟用主要工作負載類別︓ • Stateless: Deployment + ReplicaSet • Stateful: StatefulSet • Cluster: DaemonSet • Batch: CronJob + Job • Service/microservices︓ • Service + kube-proxy • Ingress + Ingress controller • DNS
65. Pods • Kubernetes 最小執行單位 • Container 與 Volume 的小群組 • 群組內緊密耦合︐如 Container 放置、原子複製 • 每個 Pod 只有一個 IP(當然不是硬性) • 共享 localhost、volumes 與 network 等 • 支援 Init container “Pod is a single instance of an application in Kubernetes”
66. Volumes • 儲存會在 Pod 啟動時自動附加(如果有定義的話) • 依據需求建立本地臨時目錄 • 支援使用 Host 檔案、目錄與裝置 • 支援多種儲存系統 • NFS、GlusterFS • iSCSI、Cinder、RBD • Git repo • Secret、Configmap(Kubernetes object)
67. Namespace • 一組 Kubernetes 資源與物件的抽象集合 • 不同 Namespace 之間 Kubernetes 資源 與物件是隔離的 • 將資源物件與 Host 解藕 • 不同 Namespace 能做簡單的使用者隔 離(不同使用者用不同 Namespace) • 能與 Adminssion、Authorization、 Authentication 相結合
68. ConfigMap • 將組態文件從容器映像檔分離 • 可以掛載成檔案到 Container 中 • 可以用在 Pod 的 Container 環境變數 Node Pod Config API
69. Secrets • 與 ConfigMap 功能 87% 一樣 • 以 Base64 做 encode (有跟沒有一樣) • 適合用於敏感資料與檔案 Node Pod Secret API
70. Labels • 使用者提供的 Key/Value 屬性 • 可以附加到任何 API object 上 • 通常用在一組應用的 API Object 識別與分組 • 可以由 Selector 來查詢︐當作 SQL 的 `select ... where ..`
71. Selector • 用來查詢 Lables︐當作 SQL 的`select ... where ..` • 許多 API Object 透過 Selector 來選取關聯的 Object(如 Service select Pod) • Equality-based selectors (=, ==, !=) • Set-based selectors (in, notin, exists) track = stable app: my-app track: stable tier: FE app: my-app track: canary tier: FE
72. app: my-app track: stable tier: FE app: my-app track: canary tier: FE app: my-app track: stable tier: BE app: my-app track: canary tier: BE
73. app = my-app app: my-app track: stable tier: FE app: my-app track: canary tier: FE app: my-app track: stable tier: BE app: my-app track: canary tier: BE
74. app = my-app, tier = FE app: my-app track: stable tier: FE app: my-app track: canary tier: FE app: my-app track: stable tier: BE app: my-app track: canary tier: BE
75. app = my-app, track = stable app: my-app track: stable tier: FE app: my-app track: canary tier: FE app: my-app track: stable tier: BE app: my-app track: canary tier: BE
76. Services • Kubernetes 存取 Pod 的抽象資源(以 Selector 選定 Pod) • 支援 DNS 查詢來導向對應 Pod IP( Pod 掛掉會改變) • DNS SRV records for ports • 提供不同 Access Policy: • ClusterIP • NodePort • LoadBalancer • Headless Virtual IP Client
77. Services 的背後實現者 - kube-proxy
78. Replication Controllers • 確保 Pod 在叢集上有 N 份副本 • 當缺少就新建︐當多一個就刪除 • 透過 Selector 來選取管理 Pod • select pod num == replicas value • 能夠動態縮放 • 僅支援 equality-based selector ReplicationController - selector = {"app": "my-app"} - template = { ... } - replicas = 4 API Server How many? 3 Start 1 more OK How many? 4 “Controller manages replicated pods for an application pattern”
79. Replica Sets • 與 Replication Controllers 87% 功能一樣 • 是新一代 Replication Controllers • 支援 Set-based selector • 為 Deployment 的基底 Repica Sets - selector: { "matchLabels": {"key": value}, "matchExpressions": [{k, o, v}] } - replicas = 4 API Server How many? 3 Start 1 more OK How many? 4
80. Deployments • Rollouts as a service • 支援 Rolling update 與 Recreate 方式更新 Pod Template • 聲明式更新 • 管理 RS 與 Pod Deployment - strategy: {type: RollingUpdate} - replicas: 3 - selector: - app: my-app ...
81. Rolling Updates Deployment - replicas: 3 - selector: - app: my-app - version: v1 Service - app: my-app Live-update an application $ kubectl set image deployment \ my-app my-app= :v2 —record
82. Deployment - replicas: 3 - selector: - app: my-app - version: v1 Deployment - replicas: 0 - selector: - app: my-app - version: v2 Service - app: my-app
83. Deployment - replicas: 3 - selector: - app: my-app - version: v1 Deployment - replicas: 1 - selector: - app: my-app - version: v2 Service - app: my-app
84. Deployment - replicas: 2 - selector: - app: my-app - version: v1 Deployment - replicas: 1 - selector: - app: my-app - version: v2 Service - app: my-app
85. Deployment - replicas: 2 - selector: - app: my-app - version: v1 Deployment - replicas: 2 - selector: - app: my-app - version: v2 Service - app: my-app
86. Deployment - replicas: 1 - selector: - app: my-app - version: v1 Deployment - replicas: 2 - selector: - app: my-app - version: v2 Service - app: my-app
87. Deployment - replicas: 1 - selector: - app: my-app - version: v1 Deployment - replicas: 3 - selector: - app: my-app - version: v2 Service - app: my-app
88. Deployment - replicas: 0 - selector: - app: my-app - version: v1 Deployment - replicas: 3 - selector: - app: my-app - version: v2 Service - app: my-app
89. Rollback Kubernetes 支援查看正在 Rolling Update 的 Deployment︓ $ kubectl rollout history deploy my-app # 查看狀態 $ kubectl rollout status deployment my-app # 暫停與繼續滾動升級 $kubectl rollout pause/resume deployment my-app # 回滾到上一個版本 $ kubectl rollout undo deployment my-app $ kubectl rollout undo deployment my-app --to-revision=1
90. DaemonSets • 每個節點啟動一個 Pod 作為 Daemon • 不支援副本概念 • Pod 生命週期綁定於節點 • 適合用於 logging 或 agents • 支援滾動升級
91. Jobs • 管理 Pod 需要被完成幾次 • 可支援一次執行一個或多個 Pod • 當 Pod 發生錯誤時︐會重新開啟一個新的 直到完成 Job - parallelism: 3 - completions: 6 - selector: - job: my-work
92. Ingress • 以 Virtual Host 概念來 Proxy 到 K8s 內部服務 • 支援 SSL termination、Name-based 等等 • 支援 TCP、UDP proxy • 能以 URL Paths 來 Proxy 不同內部服務 • 目前有許多實現專案 • ingress-nginx • Traefik • F5 BIG-IP Controller • Kong
93. Kubernetes 有狀態服務部署與管理
94. StatefulSets • 依序啟動與刪除管理的 Pod (LIFO) • 自動為 Pod 帶入編號 • 當使用 Volume template 時︐會自動建立 對應編號 • 為 Pod 提供身份辨識︐如 hostname、 DNS 名稱 • 支援滾動升級 volume-db-0 volume-db-1 volume-db-2 db-0 db-1 db-2
95. 常見的 Kubernetes 應用程式部署 • 利用 CLI 或是 Dashboard 部署指定應用程式的容器至 Kubernetes。 • 撰寫一些 Deployment, Services, Configmaps 等物件資源的 YAML︐然後將這些部 署至 Kubernetes。 • 透過 Kubernetes Package Manager 進行部署︐如 Helm、Ksonnet。 • 利用 Kubernetes SDK 以程式碼方式部署。
96. 一個部署 Kubernetes 應用程式的流程 1.假設有 Config 需要設定︐我們需要先建立 ConfigMap 2.然後建立 RC 來管理 Pod︐並在 Pod 描述 ConfigMap 使用方式 3.建立 Service 來提供 Backend Pod 能夠對外提供存取 4.建立 Frontend Pod 來連接 Backend Pod
97. 但是管理有狀態應用程式需要面臨... https://www.slideshare.net/smalltown20110306/agiletw-feat-devopstw-kubernetes
98. 有狀態服務(Stateful Service) Database: MySQL, MongoDB Data process: Spark, Hadoop DL/ML: TensorFlow, Caffe2 Monitor: Prometheus Storage: Gluster, Ceph Logging: Elasticsearch …等
100. 這時候就需要一個好用的『工具人』
101. Operator Operator 是 CoreOS 開發的框架︐目標是簡化複雜有狀態應用的管理︐它能夠達到 應用程式的狀態事件變化︐並利用控制器與客製化資源(CustomResourceDefinition) 來透過擴展的 Kubernetes API 進行自動建立、管理與配置應用程式容器實例。
102. CustomResourceDefinitions(CRD) CustomResourceDefinition(CRD) 是 v1.7+ 版本新加入的 Kubernetes API 擴展機制︐ 目標是無需修改核心程式碼就能對 Kubernetes 進行擴展。 • 使用自定義物件進行擴展 Kubernetes API • CRDs 能夠沿用熟悉的 UX 工具︐ex: kubectl • 能夠與 Custom Controllers 進行結合 • 支援 SubResources(v1.10+)
103. CRD Example
104. CRD Example
105. Custom Controller by client-go
106. Custom Controller With CRD
107. Operator 主要作用為︖ • 是一個 Domain Specific 控制器 • 一套具特定應用程式知識的軟體 • 透過自定義的 Controller/Resource(CRD) 來擴展 Kubernetes 功能 • 簡化有狀態應用程式的創建、組態與管理過程 • 透過程式自動化維護應用程式
108. Operator Pattern
109. Operator 的服務部署模式 - Etcd
110. Try it
111. Kubernetes Package Manager(以 ksonnet 為例)
112. 常見的 Kubernetes 應用程式部署 • 利用 CLI 或是 Dashboard 部署指定應用程式的容器至 Kubernetes。 • 撰寫一些 Deployment, Services, Configmaps 等物件資源的 YAML︐然後將這些部 署至 Kubernetes。 • 透過 Kubernetes Package Manager 進行部署︐如 Helm、Ksonnet。 • 利用 Kubernetes SDK 以程式碼方式部署。
113. Kubernetes Tools
114. Kubernetes Tools
115. Ksonnet Ksonnet 是一個命令工具︐可以更輕鬆地管理由多個組件組成的複雜部署︐簡化編寫 和部署 Kubernetes 配置。 • 對於每個環境︐我們可以輕鬆部署相同的組件︐但參數略有不同︐以便針對特定環境對其進行自定義 • 透過在 jsonnet 內定義 Kubernetes manifests︐並將內容部署到 Kubernetes 叢集中 • Kubeflow 使用 Ksonnet 部署所需的組件。 “A CLI-supported framework for extensible Kubernetes configurations”
116. Ksonnet 架構與目標 Ksonnet 是定義 Kubernetes 應用程式組態的一種方法︐其利用 Jsonnet 這種 JSON 模板語言與概念來定義 Kubernetes manifests 以部署多套應用程式至不同環境。
117. Ksonnet - Application 用來表示一個完整 Kubernetes 應用程 式的 manifests 目錄︐並以簡單的方 式耦合其他應用︐該目錄由 ks init <name> 來自動產生。
118. Ksonnet - Environment Environment 由四個元素組成︐其中有些會從 當前 kubeconfig 中取得︓ • Name: ksonnet app 是唯一識別名稱 • Server: Kubernetes API address 與 port • Namespace: kubeconfig 的 namespace • Kubernetes API version
119. Ksonnet - Component Components 可以是單一 Kubernetes 資源(e.g. Deployment)︐或者複雜的應用堆疊。Ksonnet 以下 面兩種產生方式︓ • 透過 ks generate 指令自動產生︐這種情況下 manifest 以 Jsonnet 語言來定義。 • 手動將檔案放到 components/︐這時可以用 JSON 或 Jsonnet︐但檔案名稱要以 *.jsonnet 副檔名儲存。
120. Ksonnet - Prototype & Parameter • Prototypes 是 Components 的基礎範例︐被用來透過 ks generate 產生 Components。 • Parameters 允許你透過參數客製 Prototypes︐不管是建立時或建立之後都可以透過 ks param 指令檢視與修改。
121. Ksonnet - Prototype & Component
122. Ksonnet - Prototype & Component & ENV
123. Ksonnet - Module Modules 提供一個跨環境的共享 components 方法︐其引用了 components/ 中包含 自己的 params.libsonnet 子目錄。一個 Modules 可以達到以下︓ • 可以類似於 components 在多個環境使用 • 具有嵌套結構︐以更具選擇性的方式對 components 分組 • 與給定的 environment 附加 modules 結合使用。
124. Ksonnet - Part Ksonnet 的設計圍繞在模組化概念︐因此會將大多數共享 prototype 程式碼重構為單 一部分函式庫。
125. Ksonnet - Package and Registry • 當撰寫完一個應用後︐可以透過 ks pkg 指令分發或者重用程式碼︐Ksonnet CLI 會 將程式碼放到 vendor/ 目錄保存。 • Registries 用來存放打包好的 Packages。 • 預設使用 https://github.com/ksonnet/parts/tree/master/incubator 來取得 Packages • 也可以透過 Github、Filesystem 與 Helm repo URI 取得
126. Try it $ ks init ks-example $ cd ks-example $ ks generate deployed-service guestbook-ui \ --image gcr.io/heptio-images/ks-guestbook-demo:0.1 \ --type ClusterIP $ ks apply default $ kubectl get svc guestbook-ui
127. Try it $ ks prototype list $ ks pkg list $ ks env list $ ks env add cloud --context= cloud
128. 機器學習與分散式訓練近況
129. AI Systems 重要的挑戰 • 系統基礎設施 • Host OS CPU & GPU • Container + GPU • 執行訓練環境 • 單台主機執行&多GPU • 有彈性分散式集群 Ref: https://github.com/Langhalsdino/Kubernetes-GPU-Guide
130. 簡易管理和隔離 Deep learning 環境 使用 Docker 容器能將應用程式包覆至隔離的虛擬環境中︐以簡化部署並可對容器啟 用 GPU 資源︐以獲得更佳的隔離和效能。 Ref: https://www.linuxinsider.com/story/84928.html
131. Deep Learning 分散式訓練發展 • 隨著設計的模型越來越複雜︐模型參數越來越多︐神經網路的參數個數上百億個︐ 訓練的DataSet 多到可能依照TB計算︐整個 DL訓練過程非常是非常耗時。 • 雖然GPU的硬體技術、網路模型結構和訓練方法均取得了很大的突破︐但是單機訓練耗時過久的 情況仍是無法迴避的問題︐於是就有了「分散式深度學習訓練方法」與及對應的框架。
132. 何時要採用分散式訓練︖ 分散式的深度學習並不總是最佳的選擇︐需要視情況而定︓ • 進行分散式訓練︐由於同步、資料和參數與網路傳輸等︐分散式系統相比單機訓練 要多不少額外的必要開銷。 • 可能導致網路模型的訓練時間過長︓ • 神經網路太大 • 資料量太大 其中都要考慮到 「網路傳輸」與「總計算量」
133. 何時要採用分散式訓練︖ 分散式的深度學習並不總是最佳的選擇︐需要視情況而定︓ • 進行分散式訓練︐由於同步、資料和參數與網路傳輸等︐分散式系統相比單機訓練 要多不少額外的必要開銷。 若這兩者匹配 • 大模型配小資料 、小模型配大資料
 <導致欠擬合和過擬合> 最終訓練得到的模型缺少泛化能力
134. 管理容器分散式集群 Why choose kubernetes ? ⽣產環境中︐我們將可能有多台機器需要被編配設置︐且環境可能是複雜的︐需要網路、運算與儲存 • 適合⼤規模管理與擴展︐自動化部屬 • 透過 Kubernetes DNS 機制來解析伺服器位址 • 透過 Replication Controller 來管理故障重啟問題 • Kubernetes 提供 Monitoring 與 Logging 等功能 • 能夠⽀援使⽤ CPU 與 GPU 排程來指定節點
135. 舉例 ︓ Tensoflow GPU 分散式訓練 EX : TensorFlow 分佈式訓練︐繁雜的節點配置將成為 ML Developer 新的負擔 tf.train.ClusterSpec({ "worker": [ "worker0.example.com:2222", "worker1.example.com:2222", "worker2.example.com:2222" ], "ps": [ "ps0.example.com:2222", "ps1.example.com:2222" ]}) https://www.tensorflow.org/deploy/distributed
136. An introduction to Kubeflow • What is Kubeflow? • What in the Toolkit? • Kubeflow 想達到到什麼目標︖ • Kubeflow Jupyter Hub • TF Operator 管理TFJOB
137. What is Kubeflow? Kubeflow 目標是簡化在 Kubernetes 上運行 Machine learning (ML) 的過程︐使之通 過更簡單、可攜帶與可擴展的創建。 • 目標不是在於重建其他服務︐而是提供一個最佳開發系統︐來部署到任何集群中︐有效確保ML在集群 之間移動性︐並輕鬆將任務擴展任何集群。 • 由於使用 Kubernetes 來做為基礎︐因此只要有 Kubernetes 的地方︐都能夠運行部署 Kubeflow。 Ref: https://www.kubeflow.org/
138. The Community (kubeflow/community) • 66 individual members • 12 Organizations • Alibaba Cloud, Caicloud, Canonical, Cisco, Datawire, Dell, Github, Google, Heptio, Huawei, Intel, Microsoft, Momenta, Pachyderm, Project Jupyter, Red Hat, Seldon, Weaveworks • ~ 1000 GitHub events per week (8249 total) • ~ 44 contributors per week (109 total) • ~ 40 commits per week (408 total) • ~ 65 commenters per week (163 total) • ~ 35 PR creators per week (77 total) • ~ 85 PRs created per week (601 total) Ref: https://www.kubeflow.org/
139. What in the Toolkit? • Jupyter Hub: 用於建立與管理互動式的 「Jupyter Notebook」 • TF Job Operator and Controller: 
 用來擴展管理訓練任務︐可設定使用 CPU 或 GPU︐並簡化分散式部署配置 • Tensorflow Serving: 
 部署經過訓練過後的的TensorFlow模型︐提供使用者使用與進行預測 Ref: https://www.kubeflow.org/ +
140. Kubeflow 想達到什麼目標︖ 在不同基礎設施上使 Machine learning (ML) 更加簡單與快速 (Laptop ML rig Training cluster Production cluster) Ref: @Seldon
 Hassle Free, Scalable, Machine Learning with Kubeflow
141. Simple Potable Scalable 更簡單 可攜帶 可擴展 Data Scientist / ML Engineer 能夠專注於模型創建
 部署學習成本較低 保持 Kubernetes Cluster 位於不同平台上可移植性 Kubernetes 上啟⽤用
 ⼯工作負載平衡
142. Inference ML Environment Ref: How to Get Started with Kubeflow https://medium.com/@amina.alsherif/how-to-get-started-with-kubeflow
143. Kubernetes managing resources 透過 Kubernetes 和 containers 來管理操作系統和硬體資源 Ref: How to Get Started with Kubeflow https://medium.com/@amina.alsherif/how-to-get-started-with-kubeflow
144. Use Kubeflow Ref: How to Get Started with Kubeflow https://medium.com/@amina.alsherif/how-to-get-started-with-kubeflow Kubeflow 透過kubeflow在Kubernetes上︐簡化移植和擴展機器學習（ML）工作流程的部署
145. Kubeflow 負責管理任務流程 只需要擔心如何透過Kubernetes 調整參數和設定目標︐來進行ML模型訓練 Ref: How to Get Started with Kubeflow https://medium.com/@amina.alsherif/how-to-get-started-with-kubeflow
146. ML Workflow
147. ML Workflow 繁瑣的資料預處理
148. ML 與 DevOps 關係 實際 ML code 確實是其中的一部分︐周圍的資料處理與系統建置等佔大多數。 Ref: Sculley et al.: Hidden Technical Debt in Machine Learning Systems
149. Kubeflow Workflow for 0.1 Version Developer 建立模型
150. Kubeflow Workflow for 0.1 Version 節點分散式訓練 TFJob
151. Kubeflow Workflow for 0.1 Version Serving
152. What Serving ? • TensorFlow Serving 是靈活、⾼高效能的機器學習模型服務系統，是專⾨門為⽣生產環境⽽而設 計，能簡單部署新的演算法與實驗來來提供同樣的架構與 API 進⾏行行服務 • 根據學習模型，進⾏行行反向輸入輸出 • gRPC over HTTP/2 • REST API over HTTP/1.1 需要 Ref: https://www.kubeflow.org/ Serving Response (output) Request (input) gRPC
153. What is ? • 開源框架 Seldon Core 使您可以更輕鬆︐更快速地在Kubernetes上大規模部署機器學習模 型和實驗 • 允許數據科學家使用任何機器學習框架或編程語言創建模型
 • Python based models including • Tensorflow models • Sklearn models • Spark models • H2O models • R models ⽬目前seldon-coe 正與kubeflow 共同整合ML Workflow
154. Kubeflow 使用流程 Ref: https://schd.ws/hosted_files/kccnceu18/d4/Kubeflow_Deep_Dive.pdf
155. Jupyter Hub 用於建立與管理互動式 Jupyter notebook ︐提供多用戶使用 • 認證功能 • 生成符合環境的 Pod
156. TF Operator 管理TFJOB TF Operator 自定義資源（CRD）進行擴展 Kubernetes API 管理︐並透過自定義類別 「 TFJob 」來管理各項任務。 查看kubeflow tfjos狀狀態 tfjobs.kubeflow.org
157. TF Operator 管理TFJOB Kubeflow 使用者可以像創建 Kubernetes 資源一樣創建和管理 TF Job: 定義分散式執行︓ Master、Worker、ParameterServer replicaSpecs 副本
158. TF Operator 管理TFJOB tf_operator的工作就是創建對應的4個Pod︐並且將環境變量 「 tf_config 」傳入到每個Pod中 tf_config 包含三個部分內容︓
 當前集群ClusterSpec、該節點的角色類型以及ID。 EX: Pod為worker0︐它所收到的環境變量TF_CONFIG為: tf_operator負責將集群拓拓撲的發現和配置⼯工作完成
159. Jupyter Notebook • 介於 IDE 以及 Editor 之間的寫 code 工具 • 逐行執行 • 易呈現資料視覺化
160. TFJob Dashboard 由於TFJob只能在執行期間檢查日誌︐因此需要單獨的日誌收集
161. Kubeflow 0.2 • What is Kubeflow? • What in the Toolkit? • Kubeflow 想達到到什麼目標︖ • Kubeflow Jupyter Hub • TF Operator 管理TFJOB
162. Kubeflow 0.2 [New] • Katlib (Hyper Parameter 可擴展且靈活參數調整框架) • Horovod & OpenMPI (改善了TensorFlow的分佈式訓練性能by Uber) • PyTorch operator 用來運行PyTorchJob CRD • Caffe2 operator • Pachyderm 管理複雜數據管道 • MPI operator 用於MPI作業 • TFJob Dashboard (Batch interface) • 新增更快速的 deploy.sh 部署腳本
 [Improvement] • TfJob - v1alpha2 • JupyterHub 提供更多的錯誤回報 • 改進服務監控 (Istio)
163. Kubeflow 0.2 Deploy • Kubeflow 0.2 提供︐新的部署腳本︐更簡易使用 • 對於ML工程師與數據科學家︐目標以最大限度地減少他們開始使用平 台部署所需的工作量
 
 
 export KUBEFLOW_VERSION=0.2.2 curl https://raw.githubusercontent.com/kubeflow/kubeflow/v${KUBEFLOW_VERSION}/scripts/deploy.sh | bash
164. Kubeflow 0.2 Deploy 腳本協助快速Deploy所需套件 • 包含創建檢查ksonnet版本 • Kubeflow 定義Namespace • Kubeflow 相關package
165. Kubeflow Argo Argo是一個開源的容器Workflows引擎︐用於kubernetes監控任務工作 • 可視化呈現工作流狀態 • 便於查看任務之間關係 • 即時影像有助於Debug
166. PyTorch operator PyTorch operator 自定義資源（CRD）︐用戶可以像Kubernetes中的其他內置資源一樣創建和 管理︐PyTorch Job 便於查看任務之間關係。 • 部署「pytorchjobs.kubeflow.org 」CRD 和 pytorch-operator 來管理PyTorch任務的 生命週期
167. PyTorch operator • 部署訓練模型PyTorchJob ︐並可自行定義使用的Container Image以及分散式訓練副本 透過Pod 查看任務
 kubectl get pods -l pytorch_job_name=distributed-mnist
168. Kubeflow / Katib • Katib提供基於ModelDB的Web UI • 是⼀一個可擴展且靈活的超參參數調整框架 • 不依賴於特定的深度學習框架
 例例如TensorFlow，MXNet和PyTorch
169. Let's go to play Kubeflow
170. https://hackmd.io/s/rJLok4pU7
171. 補充︓Kubeflow GPU Node #確認GPU集群節點︐是否可被分配資源
 $ kubectl get nodes "-o=custom- columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\.com/gpu"

172. Kubeflow 發展現況與特性規劃
173. Kubeflow 0.3 • 不用撰寫任何程式碼來提交 Hyperparameter tuning jobs(Katib) • 優化 Job operators 以支援框架之間的一致 API • 優化入門體驗︐透過點擊方式部署 Kubeflow 來降低學習難度。 • chainer-operator 初版釋出 • mxnet-operator 初步實現 • KubeBench Usable workflow 與 Example workloads 初版釋出
174. Kubeflow 0.3 • 透過 Knative 實現 in cluster image 建構 • 優化 TF Serving 元件的可讀性與擴展性 • 優化各 Operators 的功能 • Kunming 新增一個 Prometheus component https://docs.google.com/document/d/1Wdxt1xedAj7qF_Rjmxy1R0NRdfv7UWs-r2PItewxHpE/edit#
175. Elastifile with Kubeflow • 提供完整的存儲和數據管理解決方案 • 透過Google Cloud Launcher部署︐簡化雲數據管理︐遷移和共享︐同時提供全套 企業存儲Data功能 • 讓DataSet存放至Elastifile實現雲端同步 https://www.youtube.com/watch?v=NAqD6siHcpE
176. Future Kubeflow Serving 節點分散式訓練 Developer 建立模型 Katlib https://speakerdeck.com/masayaaoyama/introduction-to-kubeflow-0-dot-1-and-future-at-cloud-native-meetup-tokyo-number-2
177. 177 Katacoda 參考 https://www.katacoda.com/kubeflow
178. 暫存區
179. Jupyter Codes from __future__ import print_function import tensorflow as tf with tf.Session(): input1 = tf.constant([1.0, 1.0, 1.0, 1.0]) input2 = tf.constant([2.0, 2.0, 2.0, 2.0]) output = tf.add(input1, input2) result = output.eval() print("result: ", result)