快速理解一下物件之間的關係

K8s將所有工作節點上的資源都整合到一個虛擬的大平台上, 透過 Master 針對個別的Pod開放CPU, Memory和I/O等項目,提供這些Pod運行所需的資源。其中負責抽象化資源與調度資源的是K8s Master,負責接收與回應client端請求的是API Server, API Server提供Restful接口, client端可以透過 kubectl 或介面操作來對API Server發出請求讀取K8s物件描述檔或監控資源的分配狀況。

圖片參考書:【Kubernetes 進階實踐】

當client需要建置某一個服務時, 會由client 向API Server 發起請求建立一個Pod Controller, Pod Controller 會根據相關訊息向API Server 請求建立對應數量的Pod對象, 並由K8s Master調度指派到工作節點上運行, 接著client還需要再建立一個Service作為這些Pod固定的訪問入口, 最後client才能透過服務名稱或clientIP對目標服務進行訪問。

Pod

Pod是K8s最小的運作單位, 他們各自獨立, 每個Pod會依照其需求由 K8s Master動態分配資源。它是一個單一運行實體, 由一個或多個容器組成, 裡面的容器會共享所分配到的資源, 但是Pod與Pod之間資源獨立不共享;應用時可以由一個主容器+Ｎ個輔容器來使用, 相依性高的容器可以放在一起。

K8s的網路模型會將所有Pod的IP設定在同個網段,Pod之間可以利用IP進行溝通, 就像是運作在同一個區網中的多台主機;而同一個Pod裡面的容器會共用同一個IP跟Port, 並分享相同的context。
創建Pod的時候可以使用Pod Preset 為Pod注入特定的訊息, 包括ConfigMap, Secret或環境變數等,這樣就不需要為每個Pod模板提供所有的訊息。

如果要讓pod與pod之間共享數據可以透過掛volume來完成,在pod被重啟或刪除後,volume中的數據仍舊不會受到影響。

Kubenetes Master 會在工作節點上調度Pod, 並在工作節點上指向某個 image registry去下載映像檔, 再把狀態保存在etcd中, 並透過API Server共享出去;建置環境時,如果Pod裡面運行的實體需要起多個Pod的時候, 會透過 Controller 對這些Pod進行管理, 目前Pod可以自行設定的資源項目有 CPU 和 Memory, 資源的設定比例會影響到Pod的擴展跟縮減, 如果設定太高會造成pod難以調度, 太低就可能會一直擴展新的Pod, 所以資源的設定在測試階段都要仔細的評估。

Controller

Controller 可以依照工作負載實現方式的不同分為Replication Controller, Deployment, StatefulSet, DaemonSet和Job等,其中 Deployment 是最常用的實現方式, K8s透過API Server 監視這些Controller, 由 Controller 創建的 Pod 會被 Scheduler 調度到某一個工作節點運行, 等到容器正常終止或是資源耗盡後即會刪除。
Pod本身並不具備自我修復能力, 當Pod被刪除後會透過Pod Controller來實踐滾動更新或重啟, 它會根據設定的pod數量, 模板和Label Selector 在新的工作節點上重建新的實體; Label Selector 是Pod Controller在統計Pod數量的依據, Pod Controller會對每個Pod標籤進行檢查, 和Label Selector 相符的Pod才會被統計到。

遇到單Pod的負載超載時, K8s cluster中需要有部署HeapSter或Prometheus這一類的監控才能透過 HorizontalPodAutoscaler(HPA) 計算出適合的Pod數量; K8s 中的每個工作節點都有 cAdvisor 在蒐集資源利用的相關資訊, 這些資訊由HeapSter統整之後, 可以透過API Controller取得數據, 而HPA也是基於這些數據去監控容器健康狀態來操作Controller做出動態伸縮擴展pod數量的決策。

• Label Selector 的 Labels:
  Labels 是讓使用者在K8s的object 加上具有意義或關聯的識別功能, 可以隨時添加或修改, 他對K8s核心並沒有意義,K8s上的每個object(ex: Pod)都可以定義一組key-value的標籤, 每組key對於對應的object必須是唯一的。

Service

圖片參考書:【Kubernetes 進階實踐】

由於Pod在重啟後無法保證IP不異動, 所以服務彼此溝通時若是依賴在Pod身上會使得維護變得很麻煩, 於是設計了Service作為代理的角色。Service 是建構在Pod上面的一個中間層, 它為存在生命週期的Pod提供固定的訪問接口。 client發起請求後會由Service自動進行流量分發把請求調度到後面的Pod, 它能監控Pod的健康狀態把請求分發到可用的Pod上面, Service在挑選 Pod 時跟 Pod Controller 一樣需要透過Label Selector的定義。
Service IP 也稱為 Cluster IP, 他使用的網段和 Pod 不一樣, 但一樣是透過系統動態分配的, K8s cluster內的pod都可以直接對Cluster IP 提出請求, 但是 K8s cluster外的請求則需要透過每個工作節點上的NodePort轉達到對應的Service。

• Service 常用類型
  內對內: ClusterIP
  外對內: NodePort, LoadBalancer
  內對外: ExternalName

今日小結

今天先快速看一下K8s的物件關係, 讓腦袋裡先有幾個K8s角色關聯, 為了避免走歪一步就走錯路的狀況, 預計接下來幾天會先補完大部分的觀念再開始實作, 這過程中如果有發現錯誤或缺漏的部分會再隨時回來修正跟補充。