【K8s】Kubernetes架構理解

　　抽空學習了一下Kubernetes，感受和大數據領域內集羣的資源管理、任務調度等有殊途同歸之處，簡單總結一下備忘。

【概念】

　　Kubernetes是一個工業級的容器編排平臺，單詞有點長，經常使用K8s代稱。

　　其主要功能有：

• 調度：例如，部署Pod時，將Pod部署到較爲空閒的機器節點。
• 自動恢復：例如，機器節點健康檢查，將故障機器節點上的Pod遷移到正常機器節點上。　　
• 彈性伸縮：例如，業務負載檢查，當CPU/內存使用率太高，或Pod服務響應時間過長等預置前置條件知足時，自動擴容。

 PS: 　　

　　Pod是一組關係很是密切的容器的集合，例如容器間須要進行直接文件交換、共享某些Namespace、之間有很是頻繁的RPC調用等。Pod纔是K8s的原子調度單位，而不是容器。

 

【官方架構】

【理解】

　　官方的這個圖是K8s的技術架構，其實在技術架構以前，應該有個更簡化的K8s的邏輯架構作基礎。理解輸出以下：

  

• etcd：

　　是一個分佈式存儲組件，用來存儲的集羣全部狀態，還具有事件訂閱和監聽、Leader 選舉的能力。

　　事件訂閱和監聽：其餘各個組件通訊，都並非互相調用API來完成的，而是把狀態寫入etcd，其餘組件經過訂閱etcd中的狀態監聽變化，而後作後續的處理，而後再一次把更新的數據寫入etcd。

　　Leader 選舉：組件好比Scheduler，爲了作實現高可用，經過etcd從多個(一般是3個)實例裏面選舉出來一個作Master，其餘都是Standby。

 

• API Server：

　　上述etcd並非直接被訪問，而是經過API Server代理後被訪問。API Server至關於API網關，將對etcd接口的調用封裝爲標準的RESTFul API。

　　此外，API Server還實現了一些附加功能，例如身份認證、緩存等。

 

• Controller Manager：

　　實現任務調度。直接請求Kubernetes作調度的都是任務，例如Deployment、Deamon Set或者Job，每個任務請求發送給Kubernetes 以後，都是由 Controller Manager 來處理的。

　　每一種任務類型對應一個 Controller Manager，例如：Deployment對應Deployment Controller,ReplicaSet對應ReplicaSet Controller。

 

• Scheduler：

　　實現資源調度。Controller Manager會把任務對資源Pod的要求，寫入到etcd。Scheduler監聽到有新的資源Pod要求被調度，會根據整個集羣的各個節點的資源狀況，將Pod分配到較爲空閒合適的節點上。

 

• Kubelet：

　　是一個Agent，運行在每個節點上，它會監聽etcd中的Pod的信息，發現有分配給它所在節點的Pod須要運行，就在節點上運行相應的Pod，而且把狀態更新回到etcd。

 

• Kubectl：

　　是一個提供給用戶的命令行工具，用戶經過它調用API Server，發送請求寫入狀態到etcd，或者查詢etcd中的狀態。

 

【舉例】

 　　假如要運行一個多個實例的Nginx，那麼在 Kubernetes內部，流程以下： 

1. 經過 kubectl 命令行，建立一個包含Nginx 的Deployment對象。kubectl會調用 API Server 往 etcd裏面寫入一個Deployment 對象。
2. Deployment Controller監聽到有新的 Deployment 對象被寫入，就獲取到對象信息，根據對象信息來作任務調度，建立對應的 Replica Set 對象。
3. Replica Set Controller 監聽到有新的對象被建立，也讀取到對象信息來作任務調度，建立對應的 Pod 。
4. Scheduler監聽到有新的Pod被建立，讀取到 Pod 對象信息，根據集羣狀態將 Pod 調度到某一個節點上，而後更新 Pod（內部操做是將 Pod 和節點綁定）。
5. Kubelet 監聽到當前的節點被指定了新的 Pod，就根據對象信息運行 Pod。