Kubernetes 核心原理 之一.doc

學(xué)習(xí)資料收集于網(wǎng)絡(luò)，僅供參考Kubernetes 核心原理 之一/chenmeng729970897/article/details/75634420Kubernetes API Server原理分析Kubernetes API Server概述Kubernetes API Server提供了Kubernetes各類資源對象如，（如Pod、RC、Service等）的增、刪、改、查以及watch等http接口，成為集群內(nèi)各個功能模塊之間數(shù)據(jù)交互和通信中心的樞紐，是整個系統(tǒng)的數(shù)據(jù)總線和數(shù)據(jù)中心。除此之外，它還有以下特性： 是集群管理的API入口 是資源配額控制的入口 提供了完備的集群安全機制Kubernetes API Server通過一個kube-apiserver的進程提供服務(wù)，該進程運行在Master節(jié)點上。通常我們可以通過Kubernetes API Server交互，他們之前的接口是Rest調(diào)用。Kubernetes Proxy API接口Kubernetes Proxy API代理REST請求，Kubernetes API Server把收到的REST請求轉(zhuǎn)發(fā)到某個Node上的Kubernetes守護進程的REST端口上，由該Kubernetes進程負責響應(yīng)。集群功能模塊之間的通信集群內(nèi)每個功能模塊，通過API Server將信息存入etcd，當需要獲取和操作這些數(shù)據(jù)時，則通過API Server提供的REST接口來實現(xiàn)，從而實現(xiàn)了各個模塊之間的信息交互。kubernetes結(jié)構(gòu)圖如下：Control Manager原理Control Manager作為集群內(nèi)部的股哪里控制中心，負責集群內(nèi)的Node、Pod副本、服務(wù)端點（EndPoint）、命名空間（Namespace）、服務(wù)帳號、資源定額等管理，的那個某個Node意外宕機時，Control Manager會及時發(fā)現(xiàn)此故障并執(zhí)行自動化修復(fù)流程，確保集群始終處于預(yù)期的工作狀態(tài)。Control Manager結(jié)構(gòu)圖：Replication ControllerReplication Controller用于確保在任何時候一個集群中一個RC所關(guān)聯(lián)的Pod副本數(shù)量保持在預(yù)設(shè)值。如果發(fā)現(xiàn)Pod的副本數(shù)量超過預(yù)設(shè)值，則Replication Controller會銷毀一些Pod副本，反之，Replication Controller會自動創(chuàng)建新的Pod副本，直到符合條件的Pod副本數(shù)量達到預(yù)設(shè)值。Node ControllerNode Controller通過API Server實時獲取Node的相關(guān)信息，實現(xiàn)管理和監(jiān)控集群的中的每個Node節(jié)點的相關(guān)信息，ResourceQuota Controller資源配額管理這一高級功能，資源配額管理確保指定的系統(tǒng)資源對象在任何時候都不會超量占用系統(tǒng)物理資源目前Kubernetes支持如下三個層次的資源管理配額管理： 容器級別，可以對CPU和Memory進行限制 Pod級別，可以對一個Pod里面的所有容器的可用資源進行限制 Namespace級別，為Namespace(多租戶）級別的資源限制，包括： Pod數(shù)量； Replication Controller 數(shù)量； Service數(shù)量； ResourceQuota數(shù)量； Secret數(shù)量； 可持有的PV（Presistent Volume）數(shù)量。Namwspace Control用戶可以創(chuàng)建新的API Server可以創(chuàng)建新的Namespace并保存在etcd中，Namespace Controller定時可以通過API Server讀取這些Namespace信息并保存到etcd中Service Controller與Endpoint ControllerService、Endpoints與Pod的關(guān)系，如圖：Endpoints表示一個Service對應(yīng)的所有的Pod副本的訪問地址，而Endpoints Controller,就是負責生成和維護所有Endpoints對象的控制器，它負責監(jiān)聽Service和對應(yīng)的Pod副本的變化，如果監(jiān)聽到Service被刪除，則刪除和該Service同名的Endpoints對象。Node上的kube-proxy進程讀取每個Service的Endpoints,實現(xiàn)了Service的負載均衡功能。Scheduler原理分析Kubernetes Scheduler的作用是將待調(diào)度的Pod(API創(chuàng)建的Pod、Controller Manager為彌補副本而創(chuàng)建的Pod等）按照特定的調(diào)度算法和調(diào)度策略綁定到集群中某個合適的Node上，并將綁定信息寫入etcd。在調(diào)度過程中涉及三個對象：待調(diào)度列表、可用Node列表、以及調(diào)度算法和策略。目標節(jié)點上的kubelets通過API Server監(jiān)聽到Kubernetes Scheduler產(chǎn)生的Pod綁定事件，然后獲取對應(yīng)的Pod清單，下載Image鏡像，并啟動容器。Scheduler流程，如下圖：Kubernetes Scheduler 當前提供的調(diào)度流程分為以下幾步： 預(yù)選調(diào)度過程 確定最優(yōu)節(jié)點Kubernetes Scheduler的調(diào)度流程是通過插件方式加載的“調(diào)度算法提供者”，具體實現(xiàn)的，func RegisterAlgorithmProvider(name string, predicatekeys, priorityKeys, util.StringSet)它包含三個參數(shù)，name string為參數(shù)名，predicateKeys,參數(shù)為算法用到的預(yù)選策略集合，priorityKeys為算法用到的優(yōu)選策略集合。Kubernetes 運行機制分析在Kubenetes集群中，在每個Node節(jié)點上都會啟動一個kublet服務(wù)進程，該進程用于處理Master節(jié)點下發(fā)到本節(jié)點的任務(wù)，管理Pod及Pod里面的容。 每個kubelet進程會在API Server上注冊節(jié)點自身信息，定期向Master節(jié)點匯報資源的使用情況，并通過cAdvisor監(jiān)控容器和節(jié)點資源。節(jié)點管理節(jié)點通過設(shè)置kubelet的啟動參數(shù)，”register-node”, 來決定是否向API Server注冊自己。Pod 管理kublet通過以下幾種方式獲取自身Node上所要運行的Pod清單： 文件： kubelet啟動參數(shù)，”config”指定的配置文件目錄下的文件。通過file-check-frequency設(shè)置檢查該文件目錄的時間間隔，默認為20s。 HTTP站點（URL）: 通過”manifest-url”,參數(shù)設(shè)置 API Server: kublet通過API Server監(jiān)聽etcd目錄，同步Pod列表。容器健康檢查Pod通過兩類指針來檢查容器的狀態(tài)。一個是LivenessProbe指針，用于判斷容器是否健康，如果LivenessProbe探測指針不健康，則kubernetes將刪除該容器，并根據(jù)容器的重啟策略作相應(yīng)處理。另一類是，ReadinessProbe指針，用于判斷容器是否啟動完成，并且準備接受請求。cAdvisor 資源監(jiān)控在kubernetes集群中,應(yīng)用程序的級別可以在不同的級別上監(jiān)測到，這些級別包括：容器、Pod、Service和整個集群，cAdvisor是一個開源的分析容器資源使用率和功能特性的代理工具。在kubernetes項目中，cAdvisor被集成到kubernetes代碼中。kube-proxy 運行機制分析kubernetes在創(chuàng)建服務(wù)時會分配一個虛擬的IP地址，客戶端通過這個虛擬的IP地址來訪問服務(wù)，而服務(wù)則負責把請求轉(zhuǎn)發(fā)到后端的Pod上。深入分析集群安全機制kubernetes通過一系列機制來實現(xiàn)集群的安全機制，其中包括API Server的認證授權(quán)、準入控制機制及保護敏感的信息的Secret機制等。集群的安全性必須考慮主機的如下幾個目標： 保證容器與所在主機的隔離 限制容器給基礎(chǔ)設(shè)施及其他容器帶來消極影響的能力 最小權(quán)限原則 明確組件間邊界的劃分 劃分普通用戶和管理員的角色 在必要的時候允許將管理員權(quán)限賦值給普通用戶 允許擁有”Secret”數(shù)據(jù)（Keys,Certs, Passwords)的應(yīng)用在集群中運行API Server 認證Kubernetes集群中所有資源的訪問和變更都是通過Kubernetes API Server的REST API來實現(xiàn)的，所以集群的安全的關(guān)鍵就在于識別并認證客戶端身份以及隨后訪問權(quán)限的授權(quán)。kubernetes集群提供了3種級別的客戶端身份認證方式。 最嚴格的HTTPS證書認證：基于CA證書簽名的雙向數(shù)字證書認證方式。 HTTP Token認證： 通過一個Token來識別合法用戶 HTTP Base認證： 通過用戶名+密碼的方式認證這里需要一個CA證書，CA認證涉及諸多的概念，比如根證書、自簽名證書、密鑰、私鑰、加密算法及HTTPS等。下面講述SSL協(xié)議的流程，有助于CA認證和kubernetes CA認證的配置過程的理解。SSL雙向認證大概包含下面幾個步驟：1. HTTP 通信雙方的服務(wù)器向CA機構(gòu)申請證書，CA機構(gòu)下發(fā)根證書、服務(wù)端證書以及私鑰給申請者。2. HTTP 通信雙方的客戶端向CA機構(gòu)申請證書，CA機構(gòu)下發(fā)根證書、客戶端證書以及私鑰給申請者。3. 客戶端向服務(wù)器發(fā)送請求，服務(wù)端下發(fā)服務(wù)端證書給客戶端，客戶端收到證書后，通過私鑰解密證書，并利用服務(wù)端證書中的公鑰認證信息比較證書里面的信息，如域名和公鑰與服務(wù)器剛剛發(fā)送的相關(guān)消息是否一致，如果一致，則客戶端認可這個服務(wù)器的合法身份。4. 客戶端發(fā)送客戶端證書給服務(wù)器，服務(wù)器收到證書后，通過私鑰解密證書，獲得客戶端證書公鑰，并用該公鑰認證證書信息，確認客戶端是否合法。5. 客戶端通過隨機密鑰加密信息，并發(fā)送加密后的信息給服務(wù)端，服務(wù)端和客戶端協(xié)商好加密方案后，客戶端會產(chǎn)生一個隨機的密鑰，客戶端通過協(xié)商好的方案，加密該隨機密鑰，并發(fā)送該隨機密鑰到服務(wù)端。服務(wù)端接收到這個密鑰后，雙方通信的所有內(nèi)容都通過該隨機密鑰加密。HTTP Token的認證是用一個很長的特殊編碼方式的并且難以被模仿的字符串-Token來表明客戶身份的一種方式。在通常情況下，Token是一個很復(fù)雜的字符串，比如我們用私鑰簽名一個字符串后的數(shù)據(jù)就當作一個Token，每個Token對應(yīng)一個用戶名，存儲在API Server能訪問的一個文件中，當客戶端發(fā)起API調(diào)用請求時，需要在HTTP Header里面放入Token，這樣一來API Server就能識別合法用戶和非法用戶了。API Server授權(quán)授權(quán)就是對不同用戶進行授權(quán)。API Server目前支持以下幾種授權(quán)策略（通過API Server的啟動參數(shù)，”authorization_mode”設(shè)置）。 AlwaysDeny， 拒絕所有請求 AlwaysAllow，接受所有請求 ABACABAC模式的授權(quán)，有以下四個基本屬性： 用戶名 是否是只讀請求 被訪問的是哪類資源 被訪問的對象所屬的Namespace當我們?yōu)锳PI Server啟用ABAC模式時，需要指定授權(quán)策略文件的路徑和名字，授權(quán)策略里面的每一行都是一個Map類型的Json對象，稱為被訪問對象。我們可以通過設(shè)置”訪問策略對象”的如下屬性來確定對象的授權(quán)行為。 user (用戶名): 為字符串類型，該字符串類型的用戶名來源于Token文件或基本認證文件中的用戶名字段的值 readonly(只讀標識）：為布爾類型，當它的值為True時，表明該策略允許Get通過 resource（資源）: 為字符串類型，來自與URL的資源, 例如”Pods” namespace（命名空間): 為字符串類型，表明該策略允許訪問某個Namespace的資源。如：kubelet 只能訪問Pod的只讀API:“user”:”kubelet”,”resource”:”pods”,”readonly”:true;客戶端發(fā)起API Server調(diào)用時，API Server內(nèi)部先要進行用戶認證，接下來執(zhí)行鑒權(quán)流程，鑒權(quán)流程通過之前提到的”授權(quán)策略”來決定一個API調(diào)用是否合法，當API Server接收到請求后，會讀取請求中的數(shù)據(jù)，會生成一個”訪問策略對象”，然后用這個訪問策略的對象和授權(quán)策略文件中所有”訪問策略對象”逐條匹配，如果至少有一個策略對象被匹配上，測該請求被鑒權(quán)通過，否則終止API調(diào)用流程、并返回客戶端錯誤調(diào)用碼。Admission Control 準入機制Admission Control配有一個”準入控制器”，發(fā)送給API Server的任何請求都需要通過列表中每個準入控制其的檢查，檢查不通過，則API Server拒絕執(zhí)行該請求。Service AccountService Accoun