K8S工做原理

kubernetes(k8s)是docker容器用來編排和管理的工具

 

咱們經過kubectl向k8s Master發出指令。kubernetes Master主要是提供API Server、Scheduler、Controller組件，接收kubectl的命令，從Node節點獲取Node的資源信息，併發出調度任務。Node節點提供kubelet、kube-proxy，每一個node節點都安裝docker，是實際的執行者。kubernetes不負責網絡，因此通常是用flannel或者weave。etcd負責服務發現和node信息存儲

 

 

 

 

具體信息

開始介紹每一個核心組件的功能。而後將看一個典型的調度和啓動一個Pod的流程。

 

 

1. 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則正好相反。（譯者認爲此處歸納的很是準確）
2. 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的具體的功能：
認證和受權。Kubernetes有一個可插拔的認證系統。有一些內置的用戶認證機制和受權這些用戶訪問資源。此外，還有一些方法可用於向外部服務提供這些服務。這種可擴展性是Kubernetes構建的核心功能。
API Server運行一組能夠拒絕或修改請求的准入控制器。 這些容許策略被應用並設置默認值。 這是確保在API Server客戶端仍在等待請求確認時進入系統的數據有效性的關鍵。 雖然這些准入控制器目前正在編譯到API Server中，但目前正在進行的工做是使其成爲另外一種可擴展性機制。
API Server 有助於API 版本控制。API 版本的一個關鍵問題是容許資源的字段的改變，字段添加，棄用，從新組織和以其餘方式轉換。 API Server在Etcd中存儲資源的"true"表示，並根據知足的API版本轉換/呈現該資源。 自項目早期開始，規劃版本控制和API的發展一直是Kubernetes的一項重要工做。
API Server 一個重要特性是支持watch機制。這意味着API Server的客戶端可使用與Etcd相同的協調模式。Kubernetes中的大多數協調包括寫入另外一個組件正在監視的API服務器資源的組件。 第二個組件將對幾乎當即發生的變化作出反應。
3. 業務邏輯：Controller Manager and Scheduler
這些是經過API Server 進行協調的組件。這些稱爲Controller Manager和Scheduler的組件綁定到單獨的服務器Master上
Scheduler組件將作許多事情讓系統工做：
查找未分配給節點的Pod(未綁定的Pod)；
檢查集羣的狀態（緩存在內存中）；
選擇具備空閒空間並知足其餘約束條件的節點; 
將pod綁定到該節點。
Controller Manager 組件，實現ReplicaSet的行爲。（ReplicaSet能夠確保任什麼時候候均可以運行一個Pod模板的副本數量）。控制器將根據資源中的選擇器 監控ReplicaSet 資源和一組Pod。爲了保持在ReplicaSet中穩定的一組Pod，控制器將建立、銷燬Pod。
4.Node Agent: Kubelet
每個Node上都有一個Agent。這也像其餘組件同樣對API Server進行身份驗證。Agent負責監視綁定到其節點的一組Pod，並確保這些Pod正常運行，而且能實時返回這些Pod的運行狀態。
5.典型的流程
爲幫助理解，建立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內的容器。