Kubernetes 核心原理 之一.doc

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