歡迎光臨
每天分享高質量文章

Kubernetes內部組件工作原理介紹

本篇文章講述了Kubernetes內部組件的工作原理,及創建Pod的流程。如果你是運維人員或者是Kubernetes的使用者,你可以不需要知道Kubernetes的內部工作原理,但是如果你想理解Kubernetes內部的工作原理,這篇文章非常適合你。
讀這篇文章的前提是,你已經大致瞭解並會運用Kubernetes。這篇文章不會去描述什麼是Kubernetes及其組件(如:Pod、Node、Kubelet)。
本篇將討論Kubernetes核心組件及這些核心組件是如何讓Kubernetes 對“爵士樂即興演奏”。通常將像Kubernetes這樣的通用系統稱為容器的 “管弦樂編排”。但是管弦樂編排,必須有一個預先計劃的指揮家。因此,這並不是Kubernetes的一個好的描述。相反,Kubernetes更像是爵士樂即興演奏,有一系列演員互相配合協調完成演奏。
接下來,開始介紹每個核心組件的功能。然後將看一個典型的調度和啟動一個Pod的流程。

Datastore:etcd

etcd是Kubernetes的儲存狀態的資料庫。雖然Kubernetes系統中有重要的記憶體快取,但etcd被認為是記錄系統狀態。
etcd的快速總結:它是一個集群分佈式資料庫,它可以提供分佈式資料的一致性。這類的系統(如ZooKeeper、Consul)是在Google開發的chubby系統之後形成的,這些系統也稱為”鎖服務器”,因為他們可以實現分佈式鎖。etcd和chubby的資料模型是一個簡單的層次化的Key,並儲存了簡單的非結構化value,這看起來像是一個檔案系統。有意思的是,在Google,chubby被頻繁用於為實現訪問本地檔案和物件儲存的功能的抽象檔案接口。然而,分佈式資料庫的高度一致性,提供了資料的嚴格寫入順序並允許client原子性的對資料做更新操作。
可靠的系統的狀態管理是任何系統中非常困難的一件事情。在分佈式系統中,它是更加困難的,因為它引入了一致性演算法,如raft或paxos。通過使用etcd,Kubernetes可以專註系統的其他部分。
etcd的watch機制是Kubernetes工作的關鍵。系統允許client去執行輕量級的對於Key值變化事件的訂閱。當要watch的資料發生變化時,client會立即得到通知。這可以用作分佈式系統組件之間的協調機制。 一個組件一旦寫入etcd,其他組件可以立即對該變化作出反應。
etcd的訊息機制正好和PubSub訊息佇列機制相反。在許多訊息佇列系統系統中,topic不儲存真正的用戶資料,但發佈到這些topic的訊息含有豐富的資料。對於像Etcd這樣的系統,Key(類似於主題)儲存了真實的資料而訊息(資料變化通知)不含獨特的豐富訊息。換句話說,對於訊息佇列來說,topic很簡單,而像etcd則正好相反。(譯者認為此處概括的非常準確)


Policy Layer:API Server

Kubernetes的核心組件是API Server,它是Kubernetes系統和etcd直接對話的唯一組件。實際上,etcd是API Server的實現細節,理論上也可以用其他分佈式儲存系統來支持Kubernetes。
API Server是一個策略組件,提供對etcd的過濾訪問。它的作用本質上是相對通用的,目前正在被分解處理。因此,API Server也可以用於其他系統的控制平面。
API Server的主要貨物是資源,通過暴露簡單的REST API向外提供服務。這些資源有一個標準結構可以實現一些擴展功能。無論如何,API Server,允許各類組件創建、讀取、寫入、更新和監視資源。
API Server的具體的功能:
  1. 認證和授權。Kubernetes有一個可插拔的認證系統。有一些內置的用戶認證機制和授權這些用戶訪問資源。此外,還有一些方法可用於向外部服務提供這些服務。這種可擴展性是Kubernetes構建的核心功能。

  2. API Server運行一組可以拒絕或修改請求的準入控制器。 這些允許策略被應用並設置預設值。 這是確保在API Server客戶端仍在等待請求確認時進入系統的資料有效性的關鍵。 雖然這些準入控制器目前正在編譯到API Server中,但目前正在進行的工作是使其成為另一種可擴展性機制。

  3. API Server有助於API版本控制。API版本的一個關鍵問題是允許資源的欄位的改變,欄位添加,棄用,重新組織和以其他方式轉換。 API Server在etcd中儲存資源的“true”表示,並根據滿足的API版本轉換/呈現該資源。 自專案早期開始,規劃版本控制和API的發展一直是Kubernetes的一項重要工作。

API Server一個重要特性是支持watch機制。這意味著API Server的客戶端可以使用與etcd相同的協調樣式。Kubernetes中的大多數協調包括寫入另一個組件正在監視的API服務器資源的組件。 第二個組件將對幾乎立即發生的變化做出反應。


業務邏輯:Controller Manager and Scheduler

這些是通過API Server進行協調的組件。這些稱為Controller Manager和Scheduler的組件系結到單獨的服務器Master上。
Scheduler組件將做許多事情讓系統工作:
  1. 查找未分配給節點的Pod(未系結的Pod);

  2. 檢查集群的狀態(快取在記憶體中);

  3. 選擇具有空閑空間並滿足其他約束條件的節點;

  4. 將pod系結到該節點。

Controller Manager組件,實現ReplicaSet的行為。(ReplicaSet可以確保任何時候都可以運行一個Pod模板的副本數量)。控制器將根據資源中的選擇器 監控ReplicaSet 資源和一組Pod。為了保持在ReplicaSet中穩定的一組Pod,控制器將創建、銷毀Pod。


Node Agent:Kubelet

每一個Node上都有一個Agent。這也像其他組件一樣對API Server進行身份驗證。Agent負責監視系結到其節點的一組Pod,並確保這些Pod正常運行,並且能實時傳回這些Pod的運行狀態。


典型的流程

為幫助理解,創建Pod的整個流程,時序圖如下:

這個時序圖展示了創建pod的流程,基本的流程如下:
  1. 用戶提交創建Pod的請求,可以通過API Server的REST API ,也可用Kubectl命令列工具,支持Json和Yaml兩種格式;

  2. API Server處理用戶請求,儲存Pod資料到etcd;

  3. Schedule通過和API Server的watch機制,查看到新的Pod,嘗試為Pod系結Node;

  4. 過濾主機:調度器用一組規則過濾掉不符合要求的主機,比如Pod指定了所需要的資源,那麼就要過濾掉資源不夠的主機;

  5. 主機打分:對第一步篩選出的符合要求的主機進行打分,在主機打分階段,調度器會考慮一些整體優化策略,比如把一個Replication Controller的副本分佈到不同的主機上,使用最低負載的主機等;

  6. 選擇主機:選擇打分最高的主機,進行binding操作,結果儲存到etcd中;

  7. Kubelet根據調度結果執行Pod創建操作: 系結成功後,會啟動container,docker run,scheduler會呼叫API Server的API在etcd中創建一個bound pod物件,描述在一個工作節點上系結運行的所有pod信息。運行在每個工作節點上的Kubelet也會定期與etcd同步bound pod信息,一旦發現應該在該工作節點上運行的bound pod物件沒有更新,則呼叫Docker API創建並啟動pod內的容器。

總結

通過使用API Server作為中心協調點,Kubernetes能夠以松耦合的方式,實現組件相互交互。 希望讀完此文,你可以對Kubernetes創建Pod的原理有更深入的認識。
原文鏈接:https://blog.heptio.com/core-kubernetes-jazz-improv-over-orchestration-a7903ea92ca

Kubernetes入門與進階實戰培訓

本次培訓內容包括:Docker基礎、容器技術、Docker鏡像、資料共享與持久化、Docker三駕馬車、Docker實踐、Kubernetes基礎、Pod基礎與進階、常用物件操作、服務發現、Helm、Kubernetes核心組件原理分析、Kubernetes服務質量保證、調度詳解與應用場景、網絡、基於Kubernetes的CI/CD、基於Kubernetes的配置管理等,點擊瞭解具體培訓內容

5月11日正式上課,點擊閱讀原文鏈接即可報名。
赞(0)

分享創造快樂