Try   HackMD

Study Group Notes

tags: Main

How-to

  • Each week we will post several questions to guide your studies.
  • Questions will be distributed among teams.
  • Answer the questions based on your understanding from studying. Present and organize your answers like a formal study note.
  • You are encouraged to add contents or comments to other people's work.
  • We will review and discuss the answers during meeting.

Teams

  • Team1:蔡闊光、陳劭愷
  • Team2:王領崧、王劭元
  • Team3:羅家濬、唐晏湄

2020/8/3-8/18 Cloud AI Platform Comparison

Discuss what features should be added to Kubeflow

  • AWS: Sagemaker (team1)
    • Amazon SageMaker Autopilot
      Amazon SageMaker Autopilot 的推出讓對機器學習不熟練的使用者也可以輕易訓練出自己的機器學習模型，包含 分類模型 (Classification) 與 迴歸模型 (Regression) 。使用者僅需將資料集(須為 csv 格式)上傳並選定要預測之欄位， Autopilot 會探索不同演算法、超參數、資料前處理方式的組合，進而找到較為準確的機器學習模型。
    • Amazon SageMaker Debugger
      Amazon SageMaker Debugger 藉由監控、記錄並分析機器學習模型中的 Tensor 與神經網路的狀態，使用者可透過設定不同的 Rule 監控模型，當 SageMaker Debugger 偵測到 overfitting、vanishing gradient、class imbalance 等問題時，將及時發出警示給使用者。使用者可以利用 Amazon SageMaker Studio 視覺畫的介面查看 Tensor 與神經網路在訓練過程的狀態，進而偵錯並改善模型。
    • https://aws.amazon.com/tw/sagemaker/
  • Azure: ML Service (team2)
    • Machine Learning studio design tools
      studio中的設計工具讓建立ML pipeline變得十分容易，藉由圖形化的介面與托放的設計，使用者能夠簡單的匯入、刪除models與資料集，達到快速建立ML pipeline且容易修改的成效。在資料集的圖形方塊中，能透過選取"輸出 + 記錄"來將資料視覺化，或是新增規則來選擇要被使用的資料。所有的操作都是透過UI就能輕易達成，不需要撰寫任何的程式碼。
    • Machine Learning studio automated ML
      studio automated ML中，有個實驗執行的選單，提供設定結束準則(時間制、效果制或是其他特殊條件來中止訓練作業)、交叉驗證的次數、平行反覆運算上限等等，讓training的效率與效益最大化，又能符合使用者的期待。
      同時，studio automated ML中也有提供自動探索不同演算法、參數調整、資料處理的功能，幫助初學者也能訓練出準確的ML模型。
    • vscode extension
      Azure ML service有推出vscode的extensions，使用者可以直接透過vscode進行相關操作，而不需要到Azure ML工作區，簡化切換不同applications所帶來的時間與步驟。
  • Google Cloud Platform: AI Platform (team3)
    • Deep Learning VM Image
      它是google的compute engine的其中一種VM Image，為了處理資料以及ML開發而又特別優化過的版本。這個image中也會先裝好許多在ML開發過程中會需要用到的工具。能夠快速地將 Google Compute Engine 執行個體中含有最熱門 AI 架構的 VM Image執行個體化，而不必擔心軟體的相容性問題，也可以輕鬆新增 Cloud GPU 和 Cloud TPU 支援。

2020/8/3-8/18 Fundamental Concepts

Cloud computing (Team1)

  • What is the definition of IaaS, PaaS, SaaS in cloud computing?
    • IaaS is the utilization of APIs to manage the lowest levels of network infrastructure, including networking, storage, servers, and virtualization.
    • PaaS offers an even greater abstraction of cloud service, offering users the capability to build or deploy applications using tools without maintaining the underlying infrastructure. Users instead have control over the applications themselves.
    • SaaS enables users to use and access the cloud provider’s applications that are running on the provider’s infrastructure from thin client or program interfaces.
  • What is Service Level Agreement(SLA)?
    • 服務層協定指的是服務提供者與使用客戶之間，應就服務品質、水準以及性能等方面達成協議或訂定契約。
  • What are the differences between private cloud and public cloud?
    • 硬體成本: public cloud 可以讓企業省下大半的硬體支出的花費。
    • 高度自動化: public cloud 可以讓企業不用關心各種底層的基礎問題，·已如說系統裡面各種自動化服務以及警告系統等等，但是同時 private cloud 對於底層的完全掌控可以讓企業在部分特殊需求上面降低成本。
    • 彈性： public cloud 可以根據每一個季度的需求調整scale，而不會出現資源浪費的問題。
    • 資料安全： private cloud 讓企業可以把用戶資料存在自己的雲內，讓企業可以直接對用戶資料負責。

以下：
https://www.notion.so/justin0u0/Cloud-Computing-972fd95a8059429f8d90f1c407a99fd4#33e4ffe1c3d14e72bf437ec95aec5e90

Container (Team2)

  • What are the pros and cons of using container comparing to virtual machine?
    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →
    • Container
      • Container是將應用程式連同其環境打包的技術，他們共用Host OS的核心系統運行，並且建立控管機制來分配OS上的系統資源，但同時每個container互相獨立。
    • Virtual Machines (VM)
      • VM會先在Host OS上建立開發時的作業系統(Guest OS)，然後才在Guest OS上運行連同環境打包好的應用程式。
      • 每一個VM之間，會透過Hypervisor去協調每一個VM所需的資源，並加以防護。
    • Differences
      Container VM
      中心 應用程式 作業系統(Guest OS)
      部署速度 快 慢
      image size 小 大
      virtualization 作業系統層 硬體層
      安全性 較弱 較強
      記憶體 通常使用量較少 通常使用量較多
      可攜性 高 低
      穩定性 低 高

Other thing -> Container Background
https://www.notion.so/kerwenwwer/Demystifying-Containers-0076566c9b2b4d9a897554d5d4730134

  • What is concept of microservices?
    • 定義：將單體式的系統(Monolith)，拆解成多個獨立的小服務，再透過API將彼此串聯起來的架構，就是微服務。
    • 興起緣由：由於現今軟體日漸龐大複雜，如果依靠單體式系統來控管，成本太大且成效不佳。因此將一個完整的服務，拆解成一個個component，相較之下更容易維護、擴展性也會更好。
    • 特色：
      1. 服務間彼此關聯性低
      2. 資料管理去中心化(每個服務都可以有自己的資料庫)
      3. 服務間使用API來溝通
      4. 服務可以獨立部署

以下一些補充：
https://www.notion.so/justin0u0/Microservice-11a0e238cc97407da0cfe22c44f23636#57e9624749c44455b65e1cd94671987c

  • What is concept of DevOps?

    • DevOps = Development + Operation
    • concept：一種軟體開發的觀念，重視「開發人員」與「運維技術人員」間溝通合作的文化。
    • 四個核心
      1. Culture：開發多去想維運面，維運多去想開發面
      2. Automation：部屬與測試的自動化
      3. Measurement
      4. Sharing

  • What is CICD?

    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →

    • continuous integration
      • 針對軟體中的任何變動，都能自動且持續地進行驗證，驗證包含
        1. build
        2. test
        3. source code analysis
    • continuous delivery
      • 將CI合併後的code自動持續部署到測試環境，達到自動且持續快速的部署動作，可以加速之後的整體測試與驗證。
    • continuous deployment
      • 最後將測試成功的程式持續交付至客戶端或是部署到application上面，可加速使用者的反饋時間，更快且精準了解客戶體驗。

Deep learning (Team3)

  • What is the definition of AI, Machine Learning(ML) and Deep Learning(DL)?

    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →

    Image Not Showing Possible Reasons
    • The image file may be corrupted
    • The server hosting the image is unavailable
    • The image path is incorrect
    • The image format is not supported
    Learn More →

    • AI：由人工所設計的程式，其能夠像是模擬人類思考一樣，能夠辨別不同的感官刺激(聲音、圖像等)、有邏輯推理以及學習的能力。

    • ML：機器根據我們餵給它的資料從中學習出一套規則，用以解決類似的問題。而機器學習的過程中大致分為以下幾個步驟

      Image Not Showing Possible Reasons
      • The image file may be corrupted
      • The server hosting the image is unavailable
      • The image path is incorrect
      • The image format is not supported
      Learn More →

      • 選擇一個model(function set)
      • 生成不同的參數以產生不同的function，並判斷這些function有多好或是多不好
      • 最終找到一個最佳的function(訓練好的model)
      • 用其他資料來測試這個model

    • DL：使用神經網路來達成機器學習的效果

      Image Not Showing Possible Reasons
      • The image file may be corrupted
      • The server hosting the image is unavailable
      • The image path is incorrect
      • The image format is not supported
      Learn More →

  • How is model training different from model evaluation?

    • model training：機器根據訓練用的資料不斷修正參數，最後「學習」到新的能力。
    • model inference：把已經訓練好的model套用在新的資料上，再根據其表現回去調整參數。

  • What is the concept of ML pipeline?
    把機器學習的過程拆成好幾個步驟，並把它一個個串聯起來，形成一個pipeline。由於這些訓練出來的模型常被應用在「預測」或是「規劃」等等，這些問題會隨著輸入的資料改變而有不同的最佳策略，因此訓練模型不會有完成的一天。若是能夠自動化機器學習的過程，便能夠讓這些模型的應用更靈活。

2020/8/3-18 Kubernetes Basic Concepts

Overview

  • What is Kubernetes (Team1)
    Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications.
    • What does "portable" and "extensible" mean?
    • Portable: 在任何有 kubernetes 的環境都能使用一樣的 Configuration file 來進行部署。
    • Extensible:
      • Infrastructure Extensibility: Support portobility, scalable growth of project.
      • API Extensibility: Support customization (custom resource definition).
  • Kubernetes Components (Team2)
    • What is the role of each component?
      Image Not Showing Possible Reasons
      • The image file may be corrupted
      • The server hosting the image is unavailable
      • The image path is incorrect
      • The image format is not supported
      Learn More →
      • Pod
        • k8s中最小的運作單位，一個Pod對應到一個application
        • 每個Pod都有屬於自己的yaml檔
        • 一個Pod可以有一個或多個container
      • Worker Node(Node)：
        1. Kubernetes運作的最小硬體單位，可以是一個實體機或虛擬機。
        2. 每個Node有三個components：kublet, kube-proxy, Container runtime
          • kubelet：Node的管理員，負責控管此Node上所有Pods的狀態，並與control plane溝通
          • kube-proxy：Node的傳訊員，讓k8s中不在此Node上的其他物件可以知道此Node上的Pods的狀態
          • Container runtime：真正負責容器執行的程式
      • Control Plane Components(Master)
        Control Plane Components make global decisions about the cluster(e.g. scheduling)，as well as detecting and responding to cluster events.
        • kube-apiserver：管理整個k8s所需的API接口(Endpoint)。負責Node之間的溝通橋樑，每個Node彼此不能直接溝通，必須透過apiserver來轉介。
        • etcd：存放kubernetes中所有的cluster data來當作備份。可透過etcd還原k8s的狀態
        • kube-scheduler：用於監測那些新的pod尚未有assigned node，並選擇node給它們讓pod可以順利運作。node的選擇會根據資源的分配、軟硬體的限制、親和性(affinity)等等因素來決定。
          • affinity：不同與node-selector，有更多更加細緻的操作，是k8s後期才發展出的功能，主要分類為以下兩種性質:
            1. preferredDuringSchedulingIgnoredDuringExecution(軟策略)
              • weight(權重)：1-100
            2. requiredDuringSchedulingIgnoredDuringExecution(硬策略)
              • matchExpressions：底下所列的條件全都要滿足才會調度
        • kube-controller-manager：負責管理並運行 Kubernetes controller 的組件，controller是k8s裡一個個負責監視clusters狀態的process。controller-manager監控與更新cluster需要透過kube-apiserver來達成。為了降低複雜度，會先將各種controller compile成一個single binary，方便執行在single process中。以下細分每一種controller:
          1. Node controller：負責監控nodes的運作，當有nodes壞掉的時候做出回報。
          2. Replication controller：使與RC有關聯的pods能維持在正確的數量。

            selector為rc指定的pod
            replicas指定同時要有幾個pod在執行
            template定義pod資訊，包含label及containers資訊
          3. Endpoints controller：生成與維護所有Endpoints Object (即加入service和Pod)
          4. Service Account & Token controllers：為新的namespace創造一個default帳戶與API的access token。

一些補充：https://www.notion.so/justin0u0/Kubernetes-9cac20d1ac2c49109f0f95032ae60432

  • The Kubernets APIs (Team3)

    • What are the differences between "Imperative commands", "Imperative object configuration", and "Declarative object configuration"?

      • 這幾個方法都是用來管理k8s中的object
      • Declarative v.s. Imperative
        • Declarative：使用者告訴系統自己希望達到的目標是如何，系統會主動偵測應該要去執行哪些相對應的步驟。k8s的設計主要是建立在這樣的管理方式，才能有auto-healing或是auto-scaling等等功能
        • Imperative：一個指令一個動作，系統不會主動多做任何事。相較於Declarative的方式會比較綁手綁腳，但比較適合初學者學習k8s的運作。
      • object configuration：一個object可以用一個yaml或是json檔來定義
      • Imperative commands：直接對live object進行操作
        • 例子
          kubectl create deployment nginx --image nginx
        • 優點
          • 簡單好記
          • 方便操作
        • 缺點
          • 無法紀錄系統的更動歷史
          • 沒辦法做一個模板重複使用
      • Imperative object configuration：告訴系統要用甚麼操作更改yaml或json檔，進而改動到object
        • 例子
          kubectl delete -f nginx.yaml -f redis.yaml
        • 和Imperative commands比較的優點
          • Object configuration可以用git儲存
          • 在push之前可以比較檔案之間的變化，了解自己改了甚麼地方
          • 可以製作template
        • 和Imperative commands比較的缺點
          • 要對object的schema有一定的了解
          • 要多寫yaml檔
        • 和Declarative object configuration比較的優點
          • 比較易懂
          • 以k8s 1.5的版本而言，imperative object configuration做的比較完整
        • 和Declarative object configuration比較的缺點
          • 它比較適合用在更改檔案上，而非資料夾
          • 任何對live object的更改也都要更改在檔案上，否則之後就會被替換掉
      • Declarative object configuration：直接更改檔案，但是不用特別告訴系統要用甚麼方式更改。系統會自己偵測要使用哪些操作才能達到使用者要的效果
        • 例子
        ​​​​​​​​​​​​kubectl diff -f configs/
​​​​​​​​​​​​kubectl apply -f configs/
        先看有哪些更改的部分，確認完後再apply上去
        • 和Imperative commands比較的優點
          • 對live object進行的更改都可以被保留下來，就算使用者沒有手動把它更新回檔案上也沒關係(?)
          • 要對整個資料夾進行操作比較方便，不同的檔案也可以使用不同的動作更改
        • 和Imperative commands比較的缺點
          • 比較難debug，不知道在哪邊錯了

    • What is the "Object"?

      • 在 k8s 中，定義了各式各樣的object，每個 object 都是一個 persistent entity，用來表示目前 cluster 的特定狀態 & 運作行為
        Ex:
        1. 有哪些 containerized application 正在運行?
        2. 承上，在哪些 worker nodes 上運行?
        3. 這些 application 可用的 resource 為何?
        4. application 運作時的規範，例如：restart policy, fault-tolerance
      • 此外，每個object 都包含了 spec & status 兩個部份
        • spec：用來描述 object 要有甚麼樣的規格、內容、desired state等等
        • status：用來描述這個 object當前的狀態。由k8s負責維護跟更新。

    • What is the difference between "Namespace", "Resource", "Object"?

      • Namespace
        • Kubernetes 提供了抽象的 Cluster (virtual cluster) 的概念，讓我們能根據專案不同、執行團隊不同，或是商業考量，將原本擁有實體資源的單一 Kubernetes Cluster ，劃分成幾個不同的抽象的 Cluster (virtual cluster)，也就是 Namespaces。
        • 同一個namespace中的資源的name都不可以重複
        • 不同的namespace彼此不會互相影響
      • Object
        • 在一個namespace中會有很多object
        • 每個object會有自己的name
        • 在同個namespace中的同類型的object不能有重複的name，但不同種的可以
          Ex. 在同個namespace中只能有一個Pod叫myapp-1234，但同時可以有另一個deployment叫myapp-1234
        • A representation of a specific group+version+kind is an object. For example, a v1 Pod, or an apps/v1 Deployment.
      • Resource
        • A specific URL used to obtain the object is a resource. For example, a list of v1 Pod objects can be obtained from the /api/v1/pods resource.
        • Ex : A specific v1 Pod object can be obtained from the /api/v1/namespaces/<namespace-name>/pods/<pod-name> resource.
        • 參考來源
      • Resource就像是一個pointer，Kind是type，而Object則是instance(概念)
      • https://k2r2bai.com/2019/10/04/ironman2020/day19/

    • What is "Label", "Selector", "Annotation", "Field Selectors"?

      • Label
        • Label 是一個 key/value 的標籤，通常是用具有意義且可以辨別特定物件的屬性與分類。
        • Label 特點
          1. 每個物件可以同時擁有許多個labels(multiple labels)
          2. 可以透過 Selector，幫我們縮小要尋找的物件範圍。
          3. 目前 API 提供不再只是一個 key對應一個value(Equality-based requirement)的關係。
      • Annotation
        • 沒有識別用途的標籤
        • Annotations 主要是方便開發者、以及系統管理者管理上的方便，不會直接被 Kubernetes使用。
        • Ex: 我們可以在Pod的 Annotations 紀錄該 Pod的發行時間，發行版本，聯絡人email等
      • Selector
        • select 顧名思義，就是用來過濾 label 用的。
        • selector 格式
          1. Equality-based (=,==,!=)
          2. Set-based (in, notin, exists)
        • Ex: 使用命令 kubectl get pods -l 'env in (development,production)' --all-namespaces -o wide 列出所有 env 是 development 或 production 標籤
      • Field Selectors
        • 透過 Field Selectors，使用者可以根據 object 中的 Field 作為搜尋的依據

  • Add your own additional remarks and thoughts from reading the chapter

Cluster architecture (Team2)

  • What is "Node status"?
    • 可使用kubectl describe node <insert-node-name-here>來檢視Node status
    • Node status會提供的資訊有以下幾樣
      1. Address：分別有HostName、ExternalIP、InternalIP，其中HostName由kernal來report，但可被kubelet覆寫。
      2. Conditions：對於正在執行的Node的status表示，有以下幾種Condition
        • Ready： True代表Node是健康且準備接受Pod的，False則反之，Unknown則是Node controller在上個node-monitor-grace-period間沒聽到此Node(node-monitor-grace-period是在這段時間後，若沒收到Node的回覆，此Node就會被標記成unhealthy)。
        • DiskPressure：True代表Disk的空間快不夠，False則代表充裕。
        • MemoryPressure：True代表Memory空間快不夠，False則代表充裕。
        • PIDPressure：True代表太多Process run在此Node上，False則反之。
        • NetworkUnavailable：True代表此Node的網路現在沒辦法設定，False則反之。
      3. Capacity and Allocatable
        • Capacity代表這個Node擁有的所有資源，Allocatable代表的是一個普通的Pod可以從這個Node拿取的資源。
      4. Info
        • 描述一些基本的資訊，例如：kernel version、k8s version、Docker version、OS name。
  • What is "Control loop"?
    • Control loop是一個不會結束的迴圈，拿來監控系統的狀態。
    • Kubernetes中的Controller就是扮演Control loop的角色，controller會監視cluster的狀態，controller會盡量讓cluster的狀態接近理想的狀態
  • What is "Cloud Controller Manager"?
    • Cloud Controller Manager可以將cluster與雲提供者的API連接起來，並且將與cloud platform互動的component，從與cluster互動的component中獨立出來。
    • Cloud Controller Manager為插件機制的設計，使雲提供者能方便將雲端與k8s整合。
    • Controllers:
      • Node controller：負責在一個新的server被建立在雲服務的時候，創造Node object。要做以下幾點事情:
        1. 初始化Node object。
        2. 為Node object做標籤及註解，例如：此Node被deploy的region以及此Node能使用的資源。
        3. 拿取hostname以及network address。
        4. 查看Node的健康狀態，若unresponsive，使用cloud provider's API去查看server的狀態。若此Node被從server中移除，那controller也將在cluster中移除此Node。
      • Route controller：負責配置雲中的路由，使不同Pods裡的containers能互相溝通。有時也會為Pod網路分配IP Addresses。
      • Service controller：利用雲提供者的APIs達到負載平衡，並且在服務資源需要時，提供基礎的components。
  • Add your own additional remarks and thoughts from reading the chapter

Workloads

  • Pod lifecycle (Team3)

    • Pod lifetime
      • Pod不會永遠存在
      • 每個Pod都會有一個獨一無二的ID
      • 一旦Pod被scheduled到某個Node上，就不能再更改
      • 若是有其他東西被形容lifetime as a Pod，表示這個東西會跟著這個Pod一同刪除或是重新創建
    • Pod phase
      若是某個Node掛掉或是斷線，該Node上的所有Pod的狀態皆會設為Failed
      value Description
      Pending 這個Pod正在建立中，還有些container沒建完。這段時間包含Pod在等待scheduled，以及下載container所需的images
      Running Pod已經被scheduled到Node上，並且所有container都已經建完。至少有一個或以上的container還在跑，或是正處於starting或restarting
      Success 所有container都已經成功執行完畢，並且不會再restart
      Failed 所有container都執行完畢，但至少有一個執行失敗。也就是以非零的狀態結束，或是被系統關閉
      Unknown 因為某些原因而無法和Node溝通，導致無法讀取Pod的狀態

  • Ephemeral Containers (Team3)

    • 存在時間非常短暫
    • 使用Ephemeral Containers來監管服務，而非使用它們來創造一個application
    • 如果因為container壞掉，或是container所用的image沒有相對應的debug工具，都會導致不能使用kubectl來debug，這時就可以使用ephemeral container來debug
    • ephemeral container v.s. container
      • 和一般的container不同，它不保證資源充足，而且也不會自動重新執行。
      • 使用一般的ContainerSpec來描述它的內容，但不能填寫ports、livenessProbe、resources等等，因為它都沒有
      • 要使用API中的ephemeralcontainershandler才能創建，不能直接加在pod.spec中
      • 和一般的container一樣，在把它加到Pod後就不能隨意更改或是移除
    • https://medium.com/01001101/ephemeral-containers-the-future-of-kubernetes-workload-debugging-c5b7ded3019f

  • ReplicaSet (Team1)
    確保特定數量的 Pod 正在運行。Replication Controller 透過 Create, Delete pod 來維持 Pod 的數量。

  • Deployments (Team1)
    Deployment 內可以定義一個 Replicaset，並且可以控制 Deployment 的更新、回滾、暫停。
    https://www.notion.so/justin0u0/Deployment-26562e5ed539458d8c8e06433ccde435

  • StatefulSet (Team2)

    • Stateful vs Stateless
      • stateless：與伺服器要資料的過程都不會被記錄成狀態，每次的Request都是獨立，彼此沒有相互關聯，也就是說每次獲得的資料是無法被保存的，僅限於當下有作用。ex: 靜態網頁、container。
      • stateful：與stateless相反，每次的Request都會被記錄下來，日後都還可以進行存取，stateful最常見的應用就是資料庫。ex: Google Drive。
    • StatefulSet是kubernetes中用來建構stateful application的Resource(API) Object。statefulset controller會為每一個pod產生獨特的識別資訊，不會因為reschedule後產生變動。
      • 什麼樣的application需要用到StatefulSet?
        • 需要穩定且唯一的網路識別(reschedule 後的 pod name & hostname 都不會變動)。
        • 需要穩定的persistent storage(reschedule後仍會存取相同的資料)。
        • 佈署、更新Pods的時候，有其順序且是逐一完成的。
      • 兩個重要組成架構：
        1. Persistent Volume: 一個可以更新內容的儲存空間，但是可以永久儲存，不會隨著Pod一併消失(意即Volume不能被包含在Pod內)。
          存取模式 (acessModes) 有三種：
          ReadWriteOnce：被單一 Node 掛載為 read/write 模式
          ReadOnlyMany：被多個 Node 掛載為 read 模式
          ReadWriteMany：被多個 Node 掛載為 read/write 模式
        2. Headless service: 定義一個 ClusterIP: None 的service。使得DNS server會return整個Pods IP，而不是單一個的IP(clusters IP)，接著再透過DNS record lookup去連線到內部statefulset中的每個pod。

  • DaemonSet (Team2)

    • DaemonSet是確保在Kubernetes中的每一個node上都會有一個指定的pod來運行特定的工作，當有新的node加入到Kubernetes cluster後，系統會自動在那個node上生成出相同的 DaemonSet pod，當有node從Kubernetes cluster移除後，該node上的DaemonSet pod就會自動被清除掉。
    • 刪除 DaemonSet，由 DaemonSet 產生的 Pods 也會隨之被刪除。
    • 常見的應用:
      • 在每個 node 上運行一個 stroage daemon 。
      • 在每個 node 上運行一個收集 log 的 daemon。
      • 在每個 node 上運行一個監控 node 的 daemon。

  • Job (Team3)

    • 一個Job做一件事，它就像是領導者，負責分配工作到不同的Pod上去
    • 一個Job可以創立好幾個Pod
    • Job會去追蹤它所創立的Pod是否成功結束，當達到指定數量的Pod成功結束後，這個Job也成功結束了
    • 只要Job被刪掉，它所創立的Pod也都會被刪掉

  • CronJob (Team3)

    • 和前面所介紹的Job是類似的東西，但是多了自動排程的功能，適合使用在一些需要重複執行的任務(Ex. 固定時間發送email)
      • 固定間隔一段時間就執行一次
        Ex. 每隔五分鐘執行一次
      • 時間到了就執行一次
        Ex. 每個月的10號
    • 使用cron格式來描述排程的時間
    • 取名限制：必須要遵守DNS Subdomain Names規則

2020/8/18-9/3 Kubernetes Advanced Concepts Part I

Services, Load Balancing, and Networking (team1)

Storage (team2)

  • Volumes

    • Why need Volumes?
      • 檔案在container不是永久存在，每次的重啟都會使檔案隨之消失
      • k8s pod也有相同的問題
      • k8s pod中的多個containers之間時常需要檔案共享的需求
    • Background：
      • volume lifetime 與 pod lifetime 相同 (會一直存活到 pod 中的 container 全部消失為止)
      • 只要 pod 存在，資料就不會因為 container restart 而消失
      • volume基本上會以directory的形式存在於pod中，pod中的每一個container都可以存取(至於 directory 如何產生、資料實際存在哪裡則是由 volume type 決定，並非k8s負責管理)
      • 一個 volume 僅能給一個 pod 使用
    • Types of Volumes：
      • https://kubernetes.io/docs/concepts/storage/volumes/
      • 以下就比較常會在 on-premise 環境碰到的volume type進行說明：
        1. emptyDir
          • emptyDir 會在 pod 被分配到特定的 node 後產生，初始為一個空的目錄
          • 每個在 pod 中的 container，可以將 emptyDir 掛載在不同的路徑
          • container的crashing不會導致emptyDir的數據被刪除，只有當Pod從Node上移除時，emptyDir的資料才會被永久刪除
          • 若是有資料存進去 emptyDir，node 會取決於設定的環境，將資料儲存進 local SSD or disk 上，也可以透過設定 emptyDir.medium 為 Memory ，將資料放在 RAM(emptyDir 會以 tmpfs 的方式提供) ，但需要注意當node reboot時，tmpfs會被清空。
        2. hostPath
          • 在 Pod 物件上，掛載 Node 的資料夾或檔案
          • hostPath 的生命週期與 Node 相同，當 Pod 因某些原因而須重啟時，檔案仍保存在 Node 的檔案系統(file system)底下，直到該 Node 物件被 Kubernetes Cluster 移除，資料才會消失。
          • 非一般 pod 會用的 volume type，但以下情況例外：
            • container 需要監控 host Docker 的內部運作細節
            • container 中執行 cAdvisor(容器監控的工具)
          • hostPath volume 的內容僅能被 root 修改，因此若有修改需求的話，就必須把 container 以 privileged mode 執行，或是修改 hostPath volume 的權限
        3. local
          • local storage ex: disk
          • 只能以 PersistentVolume 的方式被使用，尚不支援 dynamic provisioning
          • 可以設定 nodeAffinity，因此 k8s scheduler 會挑選合適的 node 來使用
          • 如果node狀態為unhealthy，會造成local volume無法使用，進而導致掛載的無法存取資料
        4. nfs(Network FileSystem)
          • 利用外部的NFS(Network File System網路檔案系統)來存放資料，NFS需要自行準備好，k8s沒有處理這個
          • 與 emptyDir 不同，NFS volume 中的資料不會因為 pod 被刪除而一併被刪除
          • 可以預先把資料存放在 NFS volume 後再掛載
          • 可以同時被多個 pod 掛載 & 寫入，因此可以利用此特性來同時分享資料給多個 pod
        5. secret
          • 存放機密性資料的方式
          • secret volume會存在於tmpfs中，不會存在於硬碟上
        6. configMap
          • 提供使用者一個可以將設定與相關資料放到 pod 中的方式
          • 透過 configMap 關鍵字就可以將 configMap resource object 以 volume 的型式掛載到 pod 中使用。

  • Persistent Volumes
    Persistent Volume(PV) & Persistent Volume Claim(PVC)，透過這兩個概念將連結 storage 的過程抽象化，大幅降低使用者操作 storage 的困難度。

    • Persistent Volume (PV)
      • 由 storage 管理者負責產生，或是 StorageClass動態產生
      • 是 storage resource，也是一種 volume plugin
      • 擁有自己的 lifecycle (與Pod獨立分開)
    • Persistent Volume Claims (PVC)
      • 來自使用者的storage request
      • PVC 消耗 PV 資源(像是pod 消耗 node 資源)，也能夠指定特定的size or access mode的PV
    • PV & PVC Interaction Lifecycle

      • Provisioning

        • Static
          cluster administrator 預先建立數個 PV，讓使用者後續新稱PVC時，可以直接配對並開始使用storage
        • Dynamic
          當現存的 PV 沒有符合使用者的 PVC 需求時，會嘗試自動產生符合需求條件的 PV，而這樣的自動化行為，必須仰賴 StorageClass來達成。

      • Binding

        • PVC 被建立之後，k8s 會自動在 cluster 中尋找是否有合適的 PV 可用，若是尋找到就會將兩者連結(bind)起來。反之如果一直找不到合適的 PV，就會處在 Unbound的狀態。
        • 如果是透過動態的方式所產生的 PV，就一定會與該 PVC 連結起來，但不一定會完全符合需求(可能會超過，但不會低於需求)。
        • PVC to PV是 one-to-one mapping

      • Using

        • PVC與PV連接後，Pod 會將 PVC 當作是 volume使用 & 掛載到特定目錄上。
        • 關於 access mode 的部份，pod 會根據 PVC 中的定義來進行存取行為
        • 當 PVC 已經與 PV 連結完成，pod 就可以根據需求一直使用，沒有使用時間的限制

      • Storage Object in Use Protection

        • 確保PVC有被Pod使用且PV並沒有被系統移除
        • 當使用者刪除PVC時，k8s會確認Pod真的沒有使用PVC後，才會做刪除的動作
        • 當管理者刪除PV時，k8s會確認PV與PVC的連結真的斷開，才會做刪除的動作

      • Reclaiming
        當使用者已經不需要 volume 時，可以將 PVC 從 cluster 刪除，原本連結的 PV 就會被釋放，並且提供其他 PVC 進行 reclaim，而 PV 中有個 reclaim policy，用來告訴 cluster 當 PV 被釋放後，要如何處理已經存在的資料。目前支援的選項有 Retained, Recycled & Deleted 三種。

        • Retained
          當 PVC 刪除後(此時 PV 狀態為 Released，尚不能接收其他claim，因為原本的data仍保存在volume中)，cluster administrator 可以進行手動的 reclaim。
          1. 刪除 PV (對應的實際資料並不會消失)
          2. 可以選擇刪除資料 或 再建立一個 PV，並指到原本的儲存空間，這樣就會有一個帶有原本資料的PV了。
        • Deleted
          當這個 PVC 被刪除後，相對應的 PV & 實際的 storage 空間也都會一併被刪除。
        • Recycled
          透過刪除命令 rm -rf /thevolume/* 來刪除資料。
          k8s不建議此種reclaim policy，在未來的版本會被刪除。比較推薦的替代方法是dynamic provisioning。

      • Expanding Persistent Volumes Claims

        • 目前在 k8s 中，PVC 的擴充已經是預設支援的功能
        • 要注意Expanding不會產生新的 PV，而是對已經連結的 PV 進行擴充(resized)。

一些補充：https://www.notion.so/justin0u0/PersistentVolume-4d77bd9be6b941b6ad084e93b5a1bd8f

Configuration (team2)

  • Managing Resources for Containers
    • Request:
      • 透過specify container 的 resource request ，可以讓 scheduler 決定要將這個 Pod 分配哪一個 node
      • 當 node 中的資源超過 container request 的資源時，container 可以使用超過 request 的資源
    • Limit:
      • 透過specify container 的 resource limit，可讓 kublet 幫忙控管，使得 container 不會使用超過 limit 的資源
      • 若欲使用超過 limit 限制的資源時，會被 terminate
    • Resource type:
      • Compute resource: CPU, memory, huge page(After v1.14)
      • API resource: pod, Service…
    • Resource units in k8s:
      • CPU:
        1. 1CPU = 1 core and 1 hyperthread
        2. fraction is allowed
        3. absolute quantity e.g. 0.1代表相同多的CPU，無論在單核雙核或48核心
      • memory:
        1. measured in bytes
        2. 可以用 M, Mi, 科學記號
  • Pod Priority and Preemption
    • How to use priority and preemption:
      1. Add one or more PiorityClasses
      2. Create Pod with PriorityClassName，可用像 deployment 的方式 create Pod
    • PriorityClass:
      • mapping a priority class name to a integer value
      • priority class 的名字前面不可以有 system-
      • PriorityClass 的 value(32bit) 要小於等於十億，更大的數字是保留給 critical system Pods
      • 有兩個 optional field
        • globalDefault:若一個 Pod 沒有 priorityClassName ，那此 Pod 就屬於 globalDefault 為 true 的 PriorityClass。所有的 PriorityClass，只能有一個的 globalDefault 是 true，若全為 false ，則沒有 priorityClassName 的 Pod ，priority value 為 0
        • description: 任意的 string
    • Non-preempting PriorityClass:
      • 將 Pod 的 PreemptionPolicy 設成 Never (default 為 PreemptLowerPriority) ，這樣會使 Pod 被放進 scheduling queue 後，會一直等到有足夠的資源才會被 schedule，不會去 Preempt 其他的 Pods
      • Non-preempting PriorityClass 仍會被 preempt
    • Preemption:
      • 當 scheduler 發現沒有 node 符合 waiting queue 裡挑出的那個 Pod (以下簡稱 P)的資源要求，那 preemption 就會啟動，會試著找到移除某個 Node 裡一個或多個 priority 較低的 Pods 後，可以符合 P 的需求，找到後接著就開始移除那些 lower priority Pods，完成移除後，就可將 P schedule
      • Graceful termination of preemption victims:
        • Pods 被 preempt 後，會有 graceful termination period 可以在這段時間內去結束他們的工作，若沒有在時間內結束，仍會強制被 kill，在這段時間內，scheduler 仍會不停檢視 pending Pods
      • User exposed information:
        • 當 Pod P preempt Node N 一個或多個 Pod，P 的 nominatedNodeName 會被填成 N
        • 在 graceful termination period 期間，有可能 scheduler 找到有足夠資源的 Node 了，那 Pod P 仍會被 schedule，因此會有 nominatedNodeName 和 nodeName 不一樣的情況
        • 在 graceful termination period 期間，有可能有更高的 priority 的 Pod 被 schedler 被 schedule 到此 Node 上，那原本的 Pod P 的 nominatedNodeName 會被清空，並可以重新 preempt 其他 Node 上的 Pods

Scheduling and Eviction (team3)

  • Kubernetes Scheduler
  • Assigning Pods to Nodes
  • Scheduling Framework
    • 基本介紹
      • scheduling framework是個能夠讓使用者客製化自己的scheduler的工具
      • 可插拔結構，k8s有提供API，讓使用者可以針對自己想要的功能再額外新增一些插件即可，不會影響到scheduler的核心結構
      • 寫完之後會和scheduler的code compile在一起
    • Scheduling Cycle & Binding Cycle
      要把一個Pod schedule到一個Node上，會經過scheduling cycle以及binding cycle這兩個階段，而這兩個階段合起來則稱作一個scheduling context
      • scheduling cycle
        • 為Pod挑選出一個Node
        • 依序執行
      • binding cycle
        • 把Pod綁到該Node上
        • 同時執行
      • 如果Pod在這兩個cycle中突然出現問題，則會中止schedule的過程，而把這個Pod丟回queue裡面，等待下次重試
    • Extension points
      表示在不同階段中可以使用插件的時機
      • QueueSort (Sort)
        在開始過濾Node之前，先把Node排序好
      • Filter
        • 把沒辦法滿足所有基本條件的Node過濾掉
        • Filters會按照被配置上去的順序執行，只要前面一個不符合就不會執行後面的Filter
        • 可以對多個Node同時進行過濾
      • PostFilter
        • 如果經過Filter後沒有可以使用的Node，才會呼叫PostFilter
        • 用其他方法找出一個可以使用的Node，例如preemption
      • Score
        • scheduler會去呼叫一些scoring plugins來對這些Node評分
      • NormalizeScore
        調整不同的評分結果之間的權重
      • Reserve
        • 位於已經選好要綁定的Node，但還沒有真的綁定上去的期間。為了避免此時又有其他Pod想要競爭這個Node上的資源，因此會先為該Pod預留資源(Reserve)
        • 在這個時期所調用的插件，都會有Reserve跟Unreserve兩個method
        • Reserve：若是調用的插件中有其中一個的Reserve method失敗，則會視為Reserve失敗，不會再往下執行其他的插件或是後面scheduling或binding的階段。並且呼叫Unreserve method
        • Unreserve：若是Reserve或是之後scheduling 或 binding階段失敗了，就會呼叫Unreserve method。會清光原先為這個Pod保留的資源以及一些狀態。
        • 呼叫Unreserve的順序和呼叫Reserve的順序是互相顛倒的
      • Bind
        在這個時期調用的插件都是用來把Pod綁到Node上。每個插件可以決定要不要綁，如果有一個插件決定要綁的話，後面的插件都會被跳過。
      • PostBind
        在Pod已經成功綁定後才呼叫，用來清除一些已經不需要的資源

2020/9/15 KubeCon Review

  • KubeAcademy: Kubernetes Application and Container Workflows hosted by VMware (only discussion, no notes)

    • Strengths of container: velocity, portability, reliability, efficiency, self-service, isolation
    • Why we said container has programmatic construction?
    • How is container image different from VM image?
    • K8S defines data center from application prospective. E.g., Pod is like a VM.
    • K8S is declarative rather than imperative.
    • Why Pod? legacy applications, eparation concerns, reusability.

  • From Notebook to Kubeflow Pipelines with HP Tuning: A Data Science Journey - Stefano Fioravanzo & Ilias Katsakioris, Arrikto (team3)

    • 目標：Run a pipeline-based hyperparameter tuning worflow starting from Jupyter Notebook, with caching. Use Kale as a workflow tool to orchestrate Katib and Kubeflow Pipelines experiments.
    • 如何讓data scientist能更簡便的完成整個ML的開發流程
    • Kale

      把Jupyter Notebook中的每個cell規劃成具有依附關係的一個個步驟，然後直接轉移到KF Pipeline上，而不需要修改任何code
    • Katib
      • 自動化調整hyperparameter的工具
      • Katib算出來的hyperparemeter會及時用在原本的experiment上
    • Arrikto Rok
      • Kale also integrates with Arrikto’s Rok to efficiently make the data available across Kubeflow components in a versioned way, and snapshot every step of each pipeline, making all pipelines completely reproducible.
      • 在ML的pipeline過程中會產生很多個不同版本、經過不同處理的data，所以做data的version control很重要。

  • Is Sharing GPU to Multiple Containers Feasible? - Samed Güner, SAP (team1)

  • Enabling Multi-user Machine Learning Workflows for Kubeflow Pipelines - Yannis Zarkadas, Arrikto & Yuan Gong, Google (team1)

  • Expanding Serverless to Scale-out Kubeflow Pipelines - Yaron Haviv, Iguazio (team2)

    • What is serverless?
      • 由第三方雲計算供應商負責後端基礎結構的維護，以服務的方式為開發者提供所需功能，例如數據庫。這個架構就是要讓開發人員專注代碼的運行而不需要管理任何的基礎設施。

      若每一個microservices都自己手動設定，從create到deployment，那非常消耗精力。所以希望可以透過code的方式來傳達我們所需的設定，並透過Serverless的方式請別人完成。

      • Why not use Serverless for data preperation and training?
      • MLRun's benifit
      • flowchart

  • Taming Data/State Challenges for ML Applications and Kubeflow - Skyler Thomas, Hewlett Packard Enterprise (team2)

    • challenges
      1. Data API availability
      • ML tools are really not unified around a single data access API
      • 不同的 ML application 需要不同的storage APIs
      • example: HDFS go fast to storage, but there is no infrastructure in k8s to deal with it.
      • Conclusion: Need data infrastructure to support different protocol
      1. Library state

      • two different views:
        1. build a container for each task
          • 會製造過多containers -> 安全問題、需要管理
        2. mounting a volume for libraries and assets into a common container
          • 避免製造太多containers
          • 需要更多時間來planing，要建一個smarter container -> 推薦用pipeline (Argo)
      1. Gravity of training data
      • Data Gravity: 當數據足夠大時，由於考量成本及隱私問題，幾乎不可能將龐大的資料搬移遠離原本被track的地方，因此服務和應用程序被拉向數據。
      1. Data security

      1. The way namespace is working in k8s:
        • driver 需要看到掛載在 PV 或 storage classes 上的 secret 才能去 access 到 storage ，但在共享的 namespace 中的 secret 在很多使用者的情況下很難保護 –> 建議：自己在建立時就小心的設置好，誰可以 access 到哪個 namespace 等等
      2. Notebook servers account:
        • 由於很多工作會是團隊分工，因此會希望 run training job 在 team namespace，代表存在在 profile namespace 的一些資源像 PV 也要在 team namespace 也可以使用 –> 建議用一些工具在profile namespace 建 volume 或 storage classes 來當team volume

  • How to Use Kubernetes to Build a Data Lake for AI Workloads - Peter MacKinnon & Uday Boppana, Red Hat (team3)

    • What is data lake?
      • A data lake is a centralized repository that allows you to store all your structured and unstructured data at any scale. You can store your data as-is, without having to first structure the data, and run different types of analytics—from dashboards and visualizations to big data processing, real-time analytics, and machine learning to guide better decisions.




    通過Rook部署完Ceph集群後，就可以提供Volume Claim給Kubernetes集群裡的App使用了。

    • kubectl

      1. command line管理工具
      2. 對 k8s 進行管理
      3. 對 rook 進行管理 （增刪改）

    • rook operator

      1. 由 kubectl 調用
      2. 整個 k8s 只有一個 rook-operator
      3. 對 ceph 創建過程中起到重要作用
      4. 初始化生成 mon key, user key, osd key 等祕鑰
      5. 根於 yaml 文件，生成 ceph 配置
      6. 在 ceph/rook 搭建過程中， 分發配置到 mon, mgr, osd, mds 等組件中
      7. 監控 ceph/rook 各個組件是否工作正常

    • rook agent

      1. 由 kubectl 調用
      2. 每個 k8s node 中都具有 rook agent
      3. 接受 rook operator 管理
      4. 對本機中的 ceph pod 進行管理

    • ceph

      • Ceph 是一個統一的分布式存儲系統，設計初衷是提供較好的性能、可靠性和可擴展性。
      • 特點
        • 高性能
          摒棄了傳統的集中式存儲元數據尋址的方案，採用 CRUSH 算法，數據分布均衡，並行度高
        • 高可用性
          • 副本數可以靈活控制
          • 支持故障域分隔，數據強一致性
          • 多種故障場景自動進行修復自愈
        • 高擴展性
          • 去中心化
          • 擴展靈活
          • 隨著節點增加而線性增長
        • 特性豐富
          • 支持三種存儲接口：塊存儲(block)、文件存儲(file)、對象存儲(object)
          • 支持自定義接口，支持多種語言驅動
      • 三種接口
        • Object：有原生的 API，而且也兼容 Swift 和 S3 的 API。
        • Block：支持精簡配置、快照、克隆
        • File：Posix 接口，支持快照
      • 在Ceph儲存中，資料都是以object為基本單位進行儲存的，每個object預設為4MB大小；若干個object屬於一個PG（Placement Group，歸置組）；而若干個PG又屬於一個OSD；一般來說，一個OSD對應於一塊磁碟。Ceph採用層級化的叢集結構（Hierarchical Cluster Map），並且使用者可自定義該叢集結構，而OSD正是這個層級化叢集結構的葉子節點。
        https://kknews.cc/code/amlvjrg.html
        https://www.itread01.com/content/1546343647.html
        https://kknews.cc/zh-tw/code/zp3zbnp.html
        https://kknews.cc/code/abgv6nn.html
        https://blog.csdn.net/liukuan73/article/details/84664922
        https://my.oschina.net/u/2306127/blog/1819630

  • Production Multi-node Jobs with Gang Scheduling, K8s, GPUs and RDMA - Madhukar Korupolu & Sanjay Chatterjee, NVIDIA (team3)

    • sync SGD
      • 同步隨機梯度下降法（Synchronous SGD）在優化的每輪迭代中，會等待所有的計算節點完成梯度計算，然後將每個工作節點上計算的隨機梯度進行彙總、平均並按照公式1更新模型。之後，工作節點接收更新之後的模型，並進入下一輪迭代。由於Sync SGD要等待所有的計算節點完成梯度計算，因此好比木桶效應，Sync SGD的計算速度會被運算效率最低的工作節點所拖累。
    • async SGD
      • 非同步隨機梯度下降法（Asynchronous SGD）在每輪迭代中，每個工作節點在計算出隨機梯度後直接更新到模型上，不再等待所有的計算節點完成梯度計算。因此，非同步隨機梯度下降法的迭代速度較快，也被廣泛應用到深度神經網路的訓練中。然而，Async SGD雖然快，但是用以更新模型的梯度是有延遲的，會對演算法的精度帶來影響。
        https://codertw.com/程式語言/394106/

    • Gang Scheduling Multi-Node Pods
      • Multi-node pods
        • 一個job需要多個pod在多個node上同時執行
      • Gang scheduler
        • 如果遇到一個job有太多pods塞不下的情況就先等待，然後先執行後面pod較少的job
      • Pod group
        • 如果遇到一個job有太多pods塞不下的情況，就先預留有空位的node直到node夠用

  • Pwned By Statistics: How Kubeflow & MLOps Can Help Secure Your ML Workloads - David Aronchick, Microsoft (team1)

  • Kubeflow 1.0 Update by a Kubeflow Community Product Manager - Josh Bottum, Arrikto (team2)

    • Kubeflow's Mission Statement : Makes it Easy for Everyone to Develop, Deploy & Manage a Portable, Distributed and Scalable ML system on Kubernetes.
    • Kubeflow's Components
      • kubeflow Jupyter Notebooks : isolation & authentication
      • Training Operators：to move the workloads to the approiate place at approiate time, allow you to distributed training, which speeds up your model processing time.
      • Workflow Building : simplify building a Kubeflow pipeline and deploy and run it.
      • Pipelines：a way to schedule, run and monitor a workflow that runs ML models. Workflow will help your schedule your new code & data instead of rebuild a new pipeline.
      • Metadata : artifacts & parameters outside the code to easily reproduce your model and understand what is necessary for your model.
      • Serving：put your model into production consistently, efficiently.

  • MLPerf Meets Kubernetes - Xinyuan Huang & Elvira Dzhuraeva, Cisco (team3)

    • MLPerf：它是一個標準，能夠公平並且有效衡量ML的硬體、軟體、服務

    • MLPerf trainging
      從以下八個面向來衡量model training過程的好壞，其中又以衡量訓練出相同品質的model所花的時間為主要方式。

    • MLPerf inference
      分成以下五個面向來衡量model的好壞，用品質跟效能作為衡量的標準，因此會根據環境不同而有所差異。



      在不同的情境下會使用不同的測量方式

    QPS：queries per second

    • MLPerf training on k8s

    • MLPerf inference on k8s

  • Is there a place for distributed storage for AI/ML? (team1)

  • Kubernetes Patterns - Roland Huß, Red Hat (team2)

    • patterns form a repeated solution to a certain set of problems.

    • foundational

      • managed lifecycle
      • predictable demands
      • health probe
      • automated placement
      • declarative deployment (how to perform application installations and upgrades by configuration)
        • rolled deployment(run both version, each time update a little bit)
        • fixed deployment(old version are all scale down, new go up)
        • Blue-Green Release(test if new version is ok, the service will switch to the new completely)
        • canary release(rolling out releases to a subset of users or servers.)

    • structural

      • init container
      • ambassador
        • how to decouple a container's access to the outside world
      • adapter
        • how to decouple access to a container from the outside world
        • monitoring container
      • sidecar
        • how to enhance the functionality of an application without changing it
        • runtime collaboration of containers (main & sidecar container)
        • connected via shared resources

    • configuration

      • configuration template
        • how to manage large and complex similar configuration data

    • behavioral

      • service discovery
        • how to discover and use services
        • internal
          • discovery through DNS lookups
          • Pods picked by label selector
        • external
          • node port
          • ingress
          • load balancer

    • advanced

      • image builder
      • elastic scale
      • operator
        • how to encapsulate operational knowledge into executable software
        • controller + CustomResourceDefinition(extend the kubernetes to your own type)
        • A Kubernetes operator is an application-specific controller that extends the functionality of the Kubernetes API to create, configure, and manage instances of complex applications on behalf of a Kubernetes user.
      • controller
        • how to get from the current state to a declared target state

2020/9/3~9/22 Kubernetes Advanced Concepts Part II

Extending Kubernetes

  • Custom resources (team1)

    https://www.notion.so/Custom-Resource-66fc4ed7f2164deeb2767e10900aa019

  • Device plugins (team2)

    • 開發理由：
      • 為了將程式碼分離，提供第三方解決方案提供者更靈活與彈性的開發流程
      • 早期k8s針對運算資源的分配時的資源選擇，只有 CPU 以及 Memory，但如今也發展出根據不同特性與需求的 device：GPU、FPGA…，device plugin就是提供了方便的方式讓這些 device 被加入到 kubernetes 的操作邏輯中。
    • 使用情境：
      • 官方列出了幾種情境
        • 想要使用特別的 device 裝置是官方沒有內建支援的，譬如 GPU, InfiniBand, FPGE 等
        • 可以在不撰寫任何 kubernetes 相關程式碼的情況下直接使用這些 devices
        • 希望有一個一致且相容的解決方案，可以讓使用者於不同的 kubernetes cluster中都能夠順利的使用這些跟硬體有關的 devices。
    • 實作原理：
      • Device Plugins 提供了一個 gRPC 介面給使用者實現其中function，並監聽節點的/var/lib/kubelet/device-plugins/目錄中的 gRPC Server Unix Socket。
      • Device Plugins 啟動時，透過 Kubelet註冊，並提供該 plugin 的 Unix Socket 名稱、API 版本號與插件資源名稱(vendor-domain/resource，例如 nvidia.com/gpu)，接著 Kubelet 會將這些資訊曝露到 Node 狀態以便 Scheduler 使用。
      • Device Plugins 啟動後，Kubelet會建立listAndWatch，來檢測設備的健康狀態、空閒狀態…
    service DevicePlugin {
      rpc GetDevicePluginOptions(Empty) returns (DevicePluginOptions) {}
      rpc ListAndWatch(Empty) returns (stream ListAndWatchResponse) {}
      rpc Allocate(AllocateRequest) returns (AllocateResponse) {}
      rpc GetPreferredAllocation(PreferredAllocationRequest) returns (PreferredAllocationResponse) {}
      rpc PreStartContainer(PreStartContainerRequest) returns (PreStartContainerResponse) {}
}

  • Operator pattern (team3)
    • 搭配了 CRD 與 Custom Controller 的客製化運作模式就叫做Operator Pattern
    • 動機
      • 模擬系統管理員
      • 自動化
    • Operator希望達到的方式是可以透過內部直接於kuberentes來溝通，並且透過程式化的方式將這些相關邏輯用程式撰寫來完成。
    • CRD
      • Custom Resources 就是所謂的 Custom Resources Definition(CRD) 框架下的產物，任何使用者都可以透過 CRD 的格式向 kubernetes 動態的創造一個全新資源，甚至可以使用 kubectl get 的方式來取得這些資源的資訊。
    • Controller
      • Informers: Informer的任務就是訂閱Resource的Add/Update/Delete事件，並接收事件的主要元件。
      • Workqueue: 前面提到的callback function當然可以獨立寫成三個相對應的function去執行動作。但是也提供另一種方法是，三個callback function皆是將物件放進Workqueue中，另外撰寫一個Controller Infinite Loop不斷從Queue中取得物件來進行 Real World = Desired World 的維護狀態邏輯
      • Control Loop:
        • 這個概念其實源自於 Kubernetes Control Plane
        • 對於 kubernetes 來說，master 以及各節點的 kubelet都扮演者 control plane 的角色，幫忙維護各式各樣的資源需求，其中的運作邏輯則是會運行一個無窮的迴圈，不停地監控所有叢集上的資源變化，譬如 Pod 的 Create,Delete,Terminated，接者根據使用者的需求來決定下一個步驟該怎麼做。而這些運作過程中，都可以直接去監聽各種 kubernetes 資源的變化。
        • 除了這些內建的資源之外，我們透過 CRD 動態創立的資源也可以使用一樣的方式
Last changed by 
 
K8S Study Group 2020
Study Kubernetes for Building AI Platform
0
1542

Read more

Installation Guides

Check List [ ] OS [ ] Docker [ ] Kubernetes [ ] Dynamic volume provisioner - NFS [ ] Kubeflow OS & Machines

Apr 12, 2022
Paper Studying: Distributed Systems

Time, Clocks, and the Ordering of Events in a Distributed System What are the main contributions of the paper? It discusses and defines the meaning of time in distributed systems. It proposes a distributed algorithm for synchronizing a system of logical clocks which can be used to totally order the events. The algorithm is then specialized for synchronizing physical clocks, and a bound is derived on how far out of synchrony the clocks can become. What is a distributed system? A distributed system consists of a collection of distinct processes which are spatially separated, and which communicate with one another by exchanging messages.

Sep 13, 2021
Roadmap

Setup Team Join the hackMD team Join the slack workspace Choose your partner (2 persons per team) for installation, assignments, etc. Prepare your own testbed Install OS, K8S, Kubeflow

Sep 9, 2021
Paper Studying: Deep Learning Systems

Excellent list of papers for machine learning systems Template: [Paper Title] Conference/Journal: The full name of the publisher Year: YYYY Presenter: Your Name Slides: link to your slides Brief Description: Summarize the main contribution or objective of the paper in 3~5 sentences. Pollux: Co-adaptive Cluster Scheduling for Goodput-Optimized Deep Learning

Sep 5, 2021
Read more from K8S Study Group 2020
Published on HackMD