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

Kubernetes核心組件解析

眾所周知,Kubernetes是目前最為火熱的容器編排工具之一,其背後有如此多的追隨者必然是有原因的。首先Kubernetes非常輕量,通常Kubernetes都是以容器作為載體,而容器本來就具有輕量級秒級部署的特點;再者Kubernetes有火熱的開源社區,自從Kubernetes加入CNCF(Cloud Native Computing Foundation,雲原生計算基金會)後,來自世界各地的許多容器開發者參與其中,其中不乏有像Redhat、IBM、華為等大廠的開發人員,因此良好的生態圈成為了最受關註的原因之一。
在Kubernetes中部署應用是一件容易的事,因其有著彈性伸縮,橫向擴展的優勢並同時提供負載均衡能力以及良好的自愈性(自動部署、自動重啟、自動複製、自動擴展等),那麼這些Kubernetes的優勢在集群中又是如何被體現出來的呢?

圖 1
Kubernetes的架構分為Master和Node兩部分,如圖1所示。由上圖可以看出這兩部分由五種主要的組件構成,它們之間協同工作從而完成整個集群的管理,這五種組件分別為API Server、Controller Manager、Scheduler、Kubelet、etcd。本文主要從一個簡單的Pod工作流出發,涉及到架構中的組件並深入講解其工作機制,下麵先簡單介紹下Kubernetes中組件和資源物件的基本概念。
  • Pod:Kubernetes中運行應用或服務的最小單元,其設計理念是支持多個容器在一個Pod中共享網絡地址和檔案系統

  • Service:訪問Pod的代理抽象服務,主要用於集群內部的服務發現和負載均衡

  • Replication Controller:用於伸縮Pod副本數量的組件

  • API Server:對以上1、2、3資源物件進行增、刪、改、查的Rest API服務器

  • Scheduler:集群中資源物件的調度控制器

  • Controller Manager:負責集群中資源物件管理同步的組件

  • etcd:分佈式鍵值對(k,v)儲存服務,儲存整個集群的狀態信息

  • Kubelet:負責維護Pod容器的生命周期

  • Label:用於Service及Replication Controller 與Pod關聯的標簽

假設此Kubernetes環境包含一個Master節點,若干個Node節點。後面說明一律按照此環境作為假設。接下來給大家展示一個簡單的Pod工作流,如圖2所示: 
(1)提交請求:用戶通常提交一個yaml檔案,向API Server發送請求創建一個Pod, yaml檔案含有此Pod的詳細信息,包含此Pod運行副本數、鏡像、Labels、名稱,端口暴露情況等。API Server接收到請求後將yaml檔案中的spec資料存入etcd中;
(2)資源狀態同步:這一步涉及到Replication組件,Replication組件監控著資料庫中的資料變化,對已有的Pod進行數量上的同步;
(3)資源分配:Scheduler會檢查Etcd資料庫中記錄的沒有被分配的Pod,將此類Pod分配至具有運行能力的Node節點中,並更新Etcd資料庫中的Pod分配情況;
(4)新建容器:kubernetes集群節點中的Kubelet對Etcd資料庫中的Pod部署狀態進行同步,標的Node節點上的Kubelet將Pod相關yaml檔案中的spec資料遞給後面的容器運行時引擎(如Docker等),後者負責Pod容器的運行停止和更新;Kubelet會通過容器運行時引擎獲取Pod的狀態並將信息更新至API Server,最後寫入etcd中;
(5)節點通訊:Kube-proxy負責各節點中Pod的網絡通信,包括服務發現和負載均衡。

圖 2
從以上Kubernetes工作流可看出,從客戶端發送創建Pod請求到Pod最終部署至節點期間參與的主要組件有API Server、 Controller-Manager、 Scheduler、 Kubelet、etcd。
etcd組件在整個Pod工作流中主要為其它四個組件提供組件狀態儲存,不多做解釋。下麵將分別對其它四個組件的工作機制予以具體說明。

一、API Server


API Server組件在如上Pod工作流中體現的功能主要分為以下幾個部分:
  1. 為整個Pod工作流提供了資源物件(Pod,Deployment,Service等)的增刪改查以及用於集群管理的Rest API接口,集群管理主要包括認證授權,集群狀態管理和資料校驗等。

  2. 提供集群中各組件的通信以及交互的功能。

  3. 提供資源配額控制入口功能。

  4. 安全的訪問控制機制。

以下是API Server的工作原理圖,如圖3所示:

圖 3
在Kubernetes集群中,API Server運行在Master節點上,預設開放兩個端口,分別為本地端口8080(非認證或授權的http請求通過該端口訪問API Server)和安全端口6443( 該端口用於接收https請求並且用於token檔案或客戶端證書及HTTP Basic的認證同時用於基於策略的授權),Kubernetes中預設為不啟動https安全訪問控制。 
集群組件間通信
API Server在整個Pod工作流中主要負責各個組件間的通信,Scheduler,Controller Manager,Kubelet通過API Server將資源物件信息存入etcd中,當各組件需要這些資料時又通過API Server的Rest接口來實現信息交互,以下分別說明:
1、Kubelet與API Server
在Pod工作流中,位於集群中每個Node節點上的Kubelet會定期呼叫API Server的Rest接口去告知當前自身狀態,API Sever接收到狀態信息後,將其更新至etcd中,Kubelet也同時通過API Server的Watch接口去監聽Pod信息,從而對各個Node節點上的Pod進行管理,主要監聽信息如表1所示:

監聽信息

Kubelet 執行

是否有新的Pod被系結到Node節點

執行Pod對應容器的創建和啟動

是否有Pod物件被刪除

刪除Node上相應Pod容器

是否有修改Pod信息

修改Node上Pod的信息

表 1
2、kube-controller-manager與API Server
Controller Manager包含許多控制器,例如Endpoint Controller、Replication Controller、Service Account Controller等, 具體會在後面Controller Manager部分說明,這些控制器通過API Server提供的接口去實時監控當前Kubernetes集群中每個資源物件的狀態變化並將最新的信息儲存在etcd中,當集群中發生各種故障導致系統發生變化時,各個控制器會從etcd中獲取資源物件信息並嘗試將系統狀態修複至理想狀態。
3、kube-scheduler與API Server
Scheduler通過API Server的Watch接口監聽Master節點新建的Pod副本信息並檢索所有符合該Pod要求的Node串列同時執行調度邏輯,成功後將Pod系結在標的節點處。
由於在集群中各組件頻繁對API Server進行訪問,各組件採用了快取機制來緩解請求量,各組件定時從API Server獲取資源物件信息並將其儲存在本地快取中,所以組件大部分時間是通過訪問快取資料來獲得信息的。


二、Controller Manager

Controller Manager在Pod工作流中起著管理和控制整個集群的作用,主要對資源物件進行管理,當Node節點中運行的Pod物件或是Node自身發生意外或故障時,Controller Manager會及時發現並處理,以確保整個集群處於理想工作狀態。
Controller Manager組成如圖4所示:

圖 4
由圖4我們可以看出Controller Manager由8個不同的控制器組成。以下主要對Replication Controller、Endpoint Controller予以說明。
1、Replication Controller
Replication Controller稱為副本控制器,在Pod工作流中主要用於保證集群中Replication Controller所關聯的Pod副本數始終保持在預期值,比如若發生節點故障的情況導致Pod被意外殺死,Replication Controller會重新調度保證集群仍然運行指定副本數,另外還可通過調整Replication Controller中spec.replicas屬性值來實現擴容或縮容。
2、Endpoint Controller
Endpoint用來表示kubernetes集群中Service對應的後端Pod副本的訪問地址,Endpoint Controller則是用來生成和維護Endpoints物件的控制器,其主要負責監聽Service和對應Pod副本變化。如果監測到Service被刪除,則刪除和該Service同名的Endpoints物件;如果監測到新的Service被創建或是被修改,則根據該Service信息獲得相關的Pod串列,然後創建或更新對應的Endpoints物件;如果監測到Pod的事件,則更新它對應的Service的Endpoints物件。圖5所示為Service、Endpoint、Pod的關係:

圖 5


三、Scheduler

Scheduler在整個Pod工作流中負責調度Pod到具體的Node節點,Scheduler通過API Server監聽Pod狀態,如果有待調度的Pod,則根據Scheduler Controller中的預選策略和優選策略給各個預備Node節點打分排序,最後將Pod調度到分數最高的Node上,然後由Node中的Kubelet組件負責Pod的啟停。當然如果部署的Pod指定了NodeName屬性,Scheduler會根據NodeName屬性值調度Pod到指定Node節點。
整個調度流程分為兩步,如圖6所示:

圖 6
第一步預選策略(Predicates)
預選策略的主要工作機制是遍歷所有當前Kubernetes集群中的Node,按照具體的預選策略選出符合要求的Node串列;如果沒有符合的Node節點,則該Pod會被暫時掛起,直到有Node節點能滿足條件。通用的預選策略篩選規則有:PodFitsResources、PodFitsHostPorts、HostName、MatchNodeSelector。
第二步優選策略(priorities)
有了第一步預選策略的篩選後,再根據優選策略給待選Node節點打分,最終選擇一個分值最高的節點去部署Pod。Kubernetes用一組優先級函式處理每一個待選的主機。每一個優先級函式會傳回一個0-10的分數,分數越高表示節點越適應需求,同時每一個函式也會對應一個表示權重的值。最終主機的得分用以下公式計算得出:
FinalScoreNode =(weight1 priorityFunc1)+(weight2 priorityFunc2)+ … +(weightn * priorityFuncn)
典型的優選策略規則
1、LeastRequestedPriority
如果新的 Pod 要分配一個Node節點,這個節點的優先級就由節點空閑的那部分與總容量的比值((總容量-節點上Pod的容量總和-新Pod的容量)/總容量)來決定。cpu和 memory權重相當,比值最大的Node節點得分最高。這個優先級函式起到了按照資源消耗來跨Node節點分配 Pods 的作用。計算公式如下:
FinalScoreNode = cpu((capacity – sum(requested))10 / capacity)+ memory((capacity – sum(requested))10 / capacity)/ 2
2、BalancedResourceAllocation
優先從備選節點串列中選擇各項資源使用率最均衡的Node節點。BalancedResourceAllocation 必須和 LeastRequestedPriority同時使用而不能單獨使用,它們分別計算主機上的cpu和memory的比重,Node節點分值由cpu比重和memory比重的“距離”決定。計算公式如下:
FinalScoreNode = 10 – abs(cpuFraction-memoryFraction)*10
3、SelectorSpreadPriority
對於屬於同一個 Service、Replication Controller的Pod,儘量分散在不同的Node上。如調度一個Pod的時候,先查找Pod對應的Service或Replication Controller,然後查找Service或Replication Controller中已存在的Pod,Node節點上運行的已存在的Pod越少,Node的打分越高。


四、Kubelet

簡而言之,Kubelet在Pod工作流中是為保證它所在的節點Pod能夠正常工作,核心為監聽API Server,當發現節點的Pod配置發生變化則根據最新的配置執行相應的動作,保證Pod在理想的預期狀態,其中對Pod進行啟停更新操作用到的是容器運行時(Docker、Rocket、LXD)。另外Kubelet也負責Volume(CVI)和網絡(CNI)的管理。
在Pod工作流中,當Pod被分配至Node節點後Kubelet就去管理此Pod的生命周期,流程如下:

圖 7


五、總結

以上是對Kubernetes四個重要組件API Server、Controller Manager、Scheduler、Kubelet工作機制的解析,相信大家讀完以後對這四種組件一定有了自己的見解,筆者建議在Kubernetes環境中部署應用前一定要理解kubernetes的組件架構,這樣不僅有益於集群出現問題時的故障排查,也有助於個人理解Kubernetes機制。
Kubernetes版本迭代十分頻繁,目前已更新到v 1.11,以上關於Kubernetes相關特性在之後的版本中可能會被棄用或更改,筆者的觀點也只限於v1.11及之前的版本,希望感興趣的同學們密切關註官方文件的更新狀況以獲取最新訊息。
本文轉載自公眾號:綠盟科技研究通訊,點擊查看原文

Kubernetes專案實戰訓練營

Kubernetes專案實戰訓練將於2018年8月17日在深圳開課,3天時間帶你系統掌握Kubernetes本次培訓包括:Docker介紹、Docker鏡像、網絡、儲存、容器安全;Kubernetes架構、設計理念、常用物件、網絡、儲存、網絡隔離、服務發現與負載均衡;Kubernetes核心組件、Pod、插件、微服務、雲原生、Kubernetes Operator、集群災備、Helm等,點擊下方圖片查看詳情。

赞(0)

分享創造快樂

© 2021 知識星球   网站地图