Kubernetes 核心原理 之一.doc

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