Kubernetes面試必知必會(huì)（下）
點(diǎn)擊“程序員面試吧”，選擇“星標(biāo)??”
點(diǎn)擊文末“閱讀原文”解鎖資料！
資料專區(qū)：超全K8s實(shí)戰(zhàn)手冊(cè)
《深入淺出Kubernetes項(xiàng)目實(shí)戰(zhàn)手冊(cè)》，幫助你一次搞懂 6 個(gè)核心原理，吃透基礎(chǔ)理論，一次學(xué)會(huì) 6 個(gè)典型問題的華麗操作！點(diǎn)擊文末閱讀原文免費(fèi)下載。
簡(jiǎn)述Kubernetes鏡像的下載策略？
K8s的鏡像下載策略有三種：Always、Never、IFNotPresent。
Always：鏡像標(biāo)簽為latest時(shí)，總是從指定的倉庫中獲取鏡像。
Never：禁止從倉庫中下載鏡像，也就是說只能使用本地鏡像。
IfNotPresent：僅當(dāng)本地沒有對(duì)應(yīng)鏡像時(shí)，才從目標(biāo)倉庫中下載。
默認(rèn)的鏡像下載策略是：當(dāng)鏡像標(biāo)簽是latest時(shí)，默認(rèn)策略是Always；當(dāng)鏡像標(biāo)簽是自定義時(shí)（也就是標(biāo)簽不是latest），那么默認(rèn)策略是IfNotPresent。
簡(jiǎn)述Kubernetes的負(fù)載均衡器？
負(fù)載均衡器是暴露服務(wù)的最常見和標(biāo)準(zhǔn)方式之一。
根據(jù)工作環(huán)境使用兩種類型的負(fù)載均衡器，即內(nèi)部負(fù)載均衡器或外部負(fù)載均衡器。內(nèi)部負(fù)載均衡器自動(dòng)平衡負(fù)載并使用所需配置分配容器，而外部負(fù)載均衡器將流量從外部負(fù)載引導(dǎo)至后端容器。
簡(jiǎn)述Kubernetes各模塊如何與API Server通信？
Kubernetes API Server作為集群的核心，負(fù)責(zé)集群各功能模塊之間的通信。集群內(nèi)的各個(gè)功能模塊通過API Server將信息存入etcd，當(dāng)需要獲取和操作這些數(shù)據(jù)時(shí)，則通過API Server提供的REST接口（用GET、LIST或WATCH方法）來實(shí)現(xiàn)，從而實(shí)現(xiàn)各模塊之間的信息交互。
如kubelet進(jìn)程與API Server的交互：每個(gè)Node上的kubelet每隔一個(gè)時(shí)間周期，就會(huì)調(diào)用一次API Server的REST接口報(bào)告自身狀態(tài)，API Server在接收到這些信息后，會(huì)將節(jié)點(diǎn)狀態(tài)信息更新到etcd中。
如kube-controller-manager進(jìn)程與API Server的交互：kube-controller-manager中的Node Controller模塊通過API Server提供的Watch接口實(shí)時(shí)監(jiān)控Node的信息，并做相應(yīng)處理。
如kube-scheduler進(jìn)程與API Server的交互：Scheduler通過API Server的Watch接口監(jiān)聽到新建Pod副本的信息后，會(huì)檢索所有符合該P(yáng)od要求的Node列表，開始執(zhí)行Pod調(diào)度邏輯，在調(diào)度成功后將Pod綁定到目標(biāo)節(jié)點(diǎn)上。
簡(jiǎn)述Kubernetes Scheduler作用及實(shí)現(xiàn)原理？
Kubernetes Scheduler是負(fù)責(zé)Pod調(diào)度的重要功能模塊，Kubernetes Scheduler在整個(gè)系統(tǒng)中承擔(dān)了“承上啟下”的重要功能，“承上”是指它負(fù)責(zé)接收Controller Manager創(chuàng)建的新Pod，為其調(diào)度至目標(biāo)Node；“啟下”是指調(diào)度完成后，目標(biāo)Node上的kubelet服務(wù)進(jìn)程接管后繼工作，負(fù)責(zé)Pod接下來生命周期。
Kubernetes Scheduler的作用是將待調(diào)度的Pod（API新創(chuàng)建的Pod、Controller Manager為補(bǔ)足副本而創(chuàng)建的Pod等）按照特定的調(diào)度算法和調(diào)度策略綁定（Binding）到集群中某個(gè)合適的Node上，并將綁定信息寫入etcd中。
在整個(gè)調(diào)度過程中涉及三個(gè)對(duì)象，分別是待調(diào)度Pod列表、可用Node列表，以及調(diào)度算法和策略。
Kubernetes Scheduler通過調(diào)度算法調(diào)度為待調(diào)度Pod列表中的每個(gè)Pod從Node列表中選擇一個(gè)最適合的Node來實(shí)現(xiàn)Pod的調(diào)度。隨后，目標(biāo)節(jié)點(diǎn)上的kubelet通過API Server監(jiān)聽到Kubernetes Scheduler產(chǎn)生的Pod綁定事件，然后獲取對(duì)應(yīng)的Pod清單，下載Image鏡像并啟動(dòng)容器。
簡(jiǎn)述Kubernetes Scheduler使用哪兩種算法將Pod綁定到worker節(jié)點(diǎn)？
Kubernetes Scheduler根據(jù)如下兩種調(diào)度算法將 Pod 綁定到最合適的工作節(jié)點(diǎn)：
預(yù)選（Predicates）：輸入是所有節(jié)點(diǎn)，輸出是滿足預(yù)選條件的節(jié)點(diǎn)。kube-scheduler根據(jù)預(yù)選策略過濾掉不滿足策略的Nodes。如果某節(jié)點(diǎn)的資源不足或者不滿足預(yù)選策略的條件則無法通過預(yù)選。如“Node的label必須與Pod的Selector一致”。
優(yōu)選（Priorities）：輸入是預(yù)選階段篩選出的節(jié)點(diǎn)，優(yōu)選會(huì)根據(jù)優(yōu)先策略為通過預(yù)選的Nodes進(jìn)行打分排名，選擇得分最高的Node。例如，資源越富裕、負(fù)載越小的Node可能具有越高的排名。
簡(jiǎn)述Kubernetes kubelet的作用？
在Kubernetes集群中，在每個(gè)Node（又稱Worker）上都會(huì)啟動(dòng)一個(gè)kubelet服務(wù)進(jìn)程。該進(jìn)程用于處理Master下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理Pod及Pod中的容器。每個(gè)kubelet進(jìn)程都會(huì)在API Server上注冊(cè)節(jié)點(diǎn)自身的信息，定期向Master匯報(bào)節(jié)點(diǎn)資源的使用情況，并通過cAdvisor監(jiān)控容器和節(jié)點(diǎn)資源。
簡(jiǎn)述Kubernetes kubelet監(jiān)控Worker節(jié)點(diǎn)資源是使用什么組件來實(shí)現(xiàn)的？
kubelet使用cAdvisor對(duì)worker節(jié)點(diǎn)資源進(jìn)行監(jiān)控。在 Kubernetes 系統(tǒng)中，cAdvisor 已被默認(rèn)集成到 kubelet 組件內(nèi)，當(dāng) kubelet 服務(wù)啟動(dòng)時(shí)，它會(huì)自動(dòng)啟動(dòng) cAdvisor 服務(wù)，然后 cAdvisor 會(huì)實(shí)時(shí)采集所在節(jié)點(diǎn)的性能指標(biāo)及在節(jié)點(diǎn)上運(yùn)行的容器的性能指標(biāo)。
簡(jiǎn)述Kubernetes如何保證集群的安全性？
Kubernetes通過一系列機(jī)制來實(shí)現(xiàn)集群的安全控制，主要有如下不同的維度：
基礎(chǔ)設(shè)施方面：保證容器與其所在宿主機(jī)的隔離；
權(quán)限方面：
最小權(quán)限原則：合理限制所有組件的權(quán)限，確保組件只執(zhí)行它被授權(quán)的行為，通過限制單個(gè)組件的能力來限制它的權(quán)限范圍。
用戶權(quán)限：劃分普通用戶和管理員的角色。
集群方面：
API Server的認(rèn)證授權(quán)：Kubernetes集群中所有資源的訪問和變更都是通過Kubernetes API Server來實(shí)現(xiàn)的，因此需要建議采用更安全的HTTPS或Token來識(shí)別和認(rèn)證客戶端身份（Authentication），以及隨后訪問權(quán)限的授權(quán)（Authorization）環(huán)節(jié)。
API Server的授權(quán)管理：通過授權(quán)策略來決定一個(gè)API調(diào)用是否合法。對(duì)合法用戶進(jìn)行授權(quán)并且隨后在用戶訪問時(shí)進(jìn)行鑒權(quán)，建議采用更安全的RBAC方式來提升集群安全授權(quán)。
敏感數(shù)據(jù)引入Secret機(jī)制：對(duì)于集群敏感數(shù)據(jù)建議使用Secret方式進(jìn)行保護(hù)。
AdmissionControl（準(zhǔn)入機(jī)制）：對(duì)kubernetes api的請(qǐng)求過程中，順序?yàn)椋合冉?jīng)過認(rèn)證 & 授權(quán)，然后執(zhí)行準(zhǔn)入操作，最后對(duì)目標(biāo)對(duì)象進(jìn)行操作。
簡(jiǎn)述Kubernetes準(zhǔn)入機(jī)制？
在對(duì)集群進(jìn)行請(qǐng)求時(shí)，每個(gè)準(zhǔn)入控制代碼都按照一定順序執(zhí)行。如果有一個(gè)準(zhǔn)入控制拒絕了此次請(qǐng)求，那么整個(gè)請(qǐng)求的結(jié)果將會(huì)立即返回，并提示用戶相應(yīng)的error信息。
準(zhǔn)入控制（AdmissionControl）準(zhǔn)入控制本質(zhì)上為一段準(zhǔn)入代碼，在對(duì)kubernetes api的請(qǐng)求過程中，順序?yàn)椋合冉?jīng)過認(rèn)證 & 授權(quán)，然后執(zhí)行準(zhǔn)入操作，最后對(duì)目標(biāo)對(duì)象進(jìn)行操作。常用組件（控制代碼）如下：
AlwaysAdmit：允許所有請(qǐng)求
AlwaysDeny：禁止所有請(qǐng)求，多用于測(cè)試環(huán)境。
ServiceAccount：它將serviceAccounts實(shí)現(xiàn)了自動(dòng)化，它會(huì)輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會(huì)自動(dòng)添加一個(gè)default，并確保pod的serviceAccount始終存在。
LimitRanger：觀察所有的請(qǐng)求，確保沒有違反已經(jīng)定義好的約束條件，這些條件定義在namespace中LimitRange對(duì)象中。
NamespaceExists：觀察所有的請(qǐng)求，如果請(qǐng)求嘗試創(chuàng)建一個(gè)不存在的namespace，則這個(gè)請(qǐng)求被拒絕。
簡(jiǎn)述Kubernetes RBAC及其特點(diǎn)（優(yōu)勢(shì)）？
RBAC是基于角色的訪問控制，是一種基于個(gè)人用戶的角色來管理對(duì)計(jì)算機(jī)或網(wǎng)絡(luò)資源的訪問的方法。
相對(duì)于其他授權(quán)模式，RBAC具有如下優(yōu)勢(shì)：
對(duì)集群中的資源和非資源權(quán)限均有完整的覆蓋。
整個(gè)RBAC完全由幾個(gè)API對(duì)象完成， 同其他API對(duì)象一樣， 可以用kubectl或API進(jìn)行操作。
可以在運(yùn)行時(shí)進(jìn)行調(diào)整，無須重新啟動(dòng)API Server。
簡(jiǎn)述Kubernetes Secret作用？
Secret對(duì)象，主要作用是保管私密數(shù)據(jù)，比如密碼、OAuth Tokens、SSH Keys等信息。將這些私密信息放在Secret對(duì)象中比直接放在Pod或Docker Image中更安全，也更便于使用和分發(fā)。
簡(jiǎn)述Kubernetes Secret有哪些使用方式？
創(chuàng)建完secret之后，可通過如下三種方式使用：
在創(chuàng)建Pod時(shí)，通過為Pod指定Service Account來自動(dòng)使用該Secret。
通過掛載該Secret到Pod來使用它。
在Docker鏡像下載時(shí)使用，通過指定Pod的spc.ImagePullSecrets來引用它。
簡(jiǎn)述Kubernetes PodSecurityPolicy機(jī)制？
Kubernetes PodSecurityPolicy是為了更精細(xì)地控制Pod對(duì)資源的使用方式以及提升安全策略。在開啟PodSecurityPolicy準(zhǔn)入控制器后，Kubernetes默認(rèn)不允許創(chuàng)建任何Pod，需要?jiǎng)?chuàng)建PodSecurityPolicy策略和相應(yīng)的RBAC授權(quán)策略（Authorizing Policies），Pod才能創(chuàng)建成功。
簡(jiǎn)述Kubernetes PodSecurityPolicy機(jī)制能實(shí)現(xiàn)哪些安全策略？
在PodSecurityPolicy對(duì)象中可以設(shè)置不同字段來控制Pod運(yùn)行時(shí)的各種安全策略，常見的有：
特權(quán)模式：privileged是否允許Pod以特權(quán)模式運(yùn)行。
宿主機(jī)資源：控制Pod對(duì)宿主機(jī)資源的控制，如hostPID：是否允許Pod共享宿主機(jī)的進(jìn)程空間。
用戶和組：設(shè)置運(yùn)行容器的用戶ID（范圍）或組（范圍）。
提升權(quán)限：AllowPrivilegeEscalation：設(shè)置容器內(nèi)的子進(jìn)程是否可以提升權(quán)限，通常在設(shè)置非root用戶（MustRunAsNonRoot）時(shí)進(jìn)行設(shè)置。
SELinux：進(jìn)行SELinux的相關(guān)配置。
簡(jiǎn)述Kubernetes網(wǎng)絡(luò)模型？
Kubernetes網(wǎng)絡(luò)模型中每個(gè)Pod都擁有一個(gè)獨(dú)立的IP地址，并假定所有Pod都在一個(gè)可以直接連通的、扁平的網(wǎng)絡(luò)空間中。所以不管它們是否運(yùn)行在同一個(gè)Node（宿主機(jī)）中，都要求它們可以直接通過對(duì)方的IP進(jìn)行訪問。設(shè)計(jì)這個(gè)原則的原因是，用戶不需要額外考慮如何建立Pod之間的連接，也不需要考慮如何將容器端口映射到主機(jī)端口等問題。
同時(shí)為每個(gè)Pod都設(shè)置一個(gè)IP地址的模型使得同一個(gè)Pod內(nèi)的不同容器會(huì)共享同一個(gè)網(wǎng)絡(luò)命名空間，也就是同一個(gè)Linux網(wǎng)絡(luò)協(xié)議棧。這就意味著同一個(gè)Pod內(nèi)的容器可以通過localhost來連接對(duì)方的端口。
在Kubernetes的集群里，IP是以Pod為單位進(jìn)行分配的。一個(gè)Pod內(nèi)部的所有容器共享一個(gè)網(wǎng)絡(luò)堆棧（相當(dāng)于一個(gè)網(wǎng)絡(luò)命名空間，它們的IP地址、網(wǎng)絡(luò)設(shè)備、配置等都是共享的）。
簡(jiǎn)述Kubernetes CNI模型？
CNI提供了一種應(yīng)用容器的插件化網(wǎng)絡(luò)解決方案，定義對(duì)容器網(wǎng)絡(luò)進(jìn)行操作和配置的規(guī)范，通過插件的形式對(duì)CNI接口進(jìn)行實(shí)現(xiàn)。CNI僅關(guān)注在創(chuàng)建容器時(shí)分配網(wǎng)絡(luò)資源，和在銷毀容器時(shí)刪除網(wǎng)絡(luò)資源。在CNI模型中只涉及兩個(gè)概念：容器和網(wǎng)絡(luò)。
容器（Container）：是擁有獨(dú)立Linux網(wǎng)絡(luò)命名空間的環(huán)境，例如使用Docker或rkt創(chuàng)建的容器。容器需要擁有自己的Linux網(wǎng)絡(luò)命名空間，這是加入網(wǎng)絡(luò)的必要條件。
網(wǎng)絡(luò)（Network）：表示可以互連的一組實(shí)體，這些實(shí)體擁有各自獨(dú)立、唯一的IP地址，可以是容器、物理機(jī)或者其他網(wǎng)絡(luò)設(shè)備（比如路由器）等。
對(duì)容器網(wǎng)絡(luò)的設(shè)置和操作都通過插件（Plugin）進(jìn)行具體實(shí)現(xiàn)，CNI插件包括兩種類型：CNI Plugin和IPAM（IP Address Management）Plugin。CNI Plugin負(fù)責(zé)為容器配置網(wǎng)絡(luò)資源，IPAM Plugin負(fù)責(zé)對(duì)容器的IP地址進(jìn)行分配和管理。IPAM Plugin作為CNI Plugin的一部分，與CNI Plugin協(xié)同工作。
簡(jiǎn)述Kubernetes網(wǎng)絡(luò)策略？
為實(shí)現(xiàn)細(xì)粒度的容器間網(wǎng)絡(luò)訪問隔離策略，Kubernetes引入Network Policy。
Network Policy的主要功能是對(duì)Pod間的網(wǎng)絡(luò)通信進(jìn)行限制和準(zhǔn)入控制，設(shè)置允許訪問或禁止訪問的客戶端Pod列表。Network Policy定義網(wǎng)絡(luò)策略，配合策略控制器（Policy Controller）進(jìn)行策略的實(shí)現(xiàn)。
簡(jiǎn)述Kubernetes網(wǎng)絡(luò)策略原理？
Network Policy的工作原理主要為：policy controller需要實(shí)現(xiàn)一個(gè)API Listener，監(jiān)聽用戶設(shè)置的Network Policy定義，并將網(wǎng)絡(luò)訪問規(guī)則通過各Node的Agent進(jìn)行實(shí)際設(shè)置（Agent則需要通過CNI網(wǎng)絡(luò)插件實(shí)現(xiàn)）。
簡(jiǎn)述Kubernetes中flannel的作用？
Flannel可以用于Kubernetes底層網(wǎng)絡(luò)的實(shí)現(xiàn)，主要作用有：
它能協(xié)助Kubernetes，給每一個(gè)Node上的Docker容器都分配互相不沖突的IP地址。
它能在這些IP地址之間建立一個(gè)覆蓋網(wǎng)絡(luò)（Overlay Network），通過這個(gè)覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動(dòng)地傳遞到目標(biāo)容器內(nèi)。
簡(jiǎn)述Kubernetes Calico網(wǎng)絡(luò)組件實(shí)現(xiàn)原理？
Calico是一個(gè)基于BGP的純?nèi)龑拥木W(wǎng)絡(luò)方案，與OpenStack、Kubernetes、AWS、GCE等云平臺(tái)都能夠良好地集成。
Calico在每個(gè)計(jì)算節(jié)點(diǎn)都利用Linux Kernel實(shí)現(xiàn)了一個(gè)高效的vRouter來負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)。每個(gè)vRouter都通過BGP協(xié)議把在本節(jié)點(diǎn)上運(yùn)行的容器的路由信息向整個(gè)Calico網(wǎng)絡(luò)廣播，并自動(dòng)設(shè)置到達(dá)其他節(jié)點(diǎn)的路由轉(zhuǎn)發(fā)規(guī)則。
Calico保證所有容器之間的數(shù)據(jù)流量都是通過IP路由的方式完成互聯(lián)互通的。Calico節(jié)點(diǎn)組網(wǎng)時(shí)可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)（L2或者L3），不需要額外的NAT、隧道或者Overlay Network，沒有額外的封包解包，能夠節(jié)約CPU運(yùn)算，提高網(wǎng)絡(luò)效率。
簡(jiǎn)述Kubernetes共享存儲(chǔ)的作用？
Kubernetes對(duì)于有狀態(tài)的容器應(yīng)用或者對(duì)數(shù)據(jù)需要持久化的應(yīng)用，因此需要更加可靠的存儲(chǔ)來保存應(yīng)用產(chǎn)生的重要數(shù)據(jù)，以便容器應(yīng)用在重建之后仍然可以使用之前的數(shù)據(jù)。因此需要使用共享存儲(chǔ)。
簡(jiǎn)述Kubernetes數(shù)據(jù)持久化的方式有哪些？
Kubernetes通過數(shù)據(jù)持久化來持久化保存重要數(shù)據(jù)，常見的方式有：
EmptyDir（空目錄）：沒有指定要掛載宿主機(jī)上的某個(gè)目錄，直接由Pod內(nèi)保部映射到宿主機(jī)上。類似于docker中的manager volume。
場(chǎng)景：
只需要臨時(shí)將數(shù)據(jù)保存在磁盤上，比如在合并/排序算法中；
作為兩個(gè)容器的共享存儲(chǔ)。
特性：
同個(gè)pod里面的不同容器，共享同一個(gè)持久化目錄，當(dāng)pod節(jié)點(diǎn)刪除時(shí)，volume的數(shù)據(jù)也會(huì)被刪除。
emptyDir的數(shù)據(jù)持久化的生命周期和使用的pod一致，一般是作為臨時(shí)存儲(chǔ)使用。
Hostpath：將宿主機(jī)上已存在的目錄或文件掛載到容器內(nèi)部。類似于docker中的bind mount掛載方式。
特性：增加了pod與節(jié)點(diǎn)之間的耦合。
PersistentVolume（簡(jiǎn)稱PV）：如基于NFS服務(wù)的PV，也可以基于GFS的PV。它的作用是統(tǒng)一數(shù)據(jù)持久化目錄，方便管理。
簡(jiǎn)述Kubernetes PV和PVC？
PV是對(duì)底層網(wǎng)絡(luò)共享存儲(chǔ)的抽象，將共享存儲(chǔ)定義為一種“資源”。
PVC則是用戶對(duì)存儲(chǔ)資源的一個(gè)“申請(qǐng)”。
簡(jiǎn)述Kubernetes PV生命周期內(nèi)的階段？
某個(gè)PV在生命周期中可能處于以下4個(gè)階段（Phaes）之一。
Available：可用狀態(tài)，還未與某個(gè)PVC綁定。
Bound：已與某個(gè)PVC綁定。
Released：綁定的PVC已經(jīng)刪除，資源已釋放，但沒有被集群回收。
Failed：自動(dòng)資源回收失敗。
簡(jiǎn)述Kubernetes所支持的存儲(chǔ)供應(yīng)模式？
Kubernetes支持兩種資源的存儲(chǔ)供應(yīng)模式：靜態(tài)模式（Static）和動(dòng)態(tài)模式（Dynamic）。
靜態(tài)模式：集群管理員手工創(chuàng)建許多PV，在定義PV時(shí)需要將后端存儲(chǔ)的特性進(jìn)行設(shè)置。
動(dòng)態(tài)模式：集群管理員無須手工創(chuàng)建PV，而是通過StorageClass的設(shè)置對(duì)后端存儲(chǔ)進(jìn)行描述，標(biāo)記為某種類型。此時(shí)要求PVC對(duì)存儲(chǔ)的類型進(jìn)行聲明，系統(tǒng)將自動(dòng)完成PV的創(chuàng)建及與PVC的綁定。
簡(jiǎn)述Kubernetes CSI模型？
Kubernetes CSI是Kubernetes推出與容器對(duì)接的存儲(chǔ)接口標(biāo)準(zhǔn)，存儲(chǔ)提供方只需要基于標(biāo)準(zhǔn)接口進(jìn)行存儲(chǔ)插件的實(shí)現(xiàn)，就能使用Kubernetes的原生存儲(chǔ)機(jī)制為容器提供存儲(chǔ)服務(wù)。CSI使得存儲(chǔ)提供方的代碼能和Kubernetes代碼徹底解耦，部署也與Kubernetes核心組件分離，顯然，存儲(chǔ)插件的開發(fā)由提供方自行維護(hù)，就能為Kubernetes用戶提供更多的存儲(chǔ)功能，也更加安全可靠。
CSI包括CSI Controller和CSI Node：
CSI Controller的主要功能是提供存儲(chǔ)服務(wù)視角對(duì)存儲(chǔ)資源和存儲(chǔ)卷進(jìn)行管理和操作。
CSI Node的主要功能是對(duì)主機(jī)（Node）上的Volume進(jìn)行管理和操作。
簡(jiǎn)述Kubernetes Worker節(jié)點(diǎn)加入集群的過程？
通常需要對(duì)Worker節(jié)點(diǎn)進(jìn)行擴(kuò)容，從而將應(yīng)用系統(tǒng)進(jìn)行水平擴(kuò)展。主要過程如下：
在該Node上安裝Docker、kubelet和kube-proxy服務(wù)；
然后配置kubelet和kubeproxy的啟動(dòng)參數(shù)，將Master URL指定為當(dāng)前Kubernetes集群Master的地址，最后啟動(dòng)這些服務(wù)；
通過kubelet默認(rèn)的自動(dòng)注冊(cè)機(jī)制，新的Worker將會(huì)自動(dòng)加入現(xiàn)有的Kubernetes集群中；
Kubernetes Master在接受了新Worker的注冊(cè)之后，會(huì)自動(dòng)將其納入當(dāng)前集群的調(diào)度范圍。
簡(jiǎn)述Kubernetes Pod如何實(shí)現(xiàn)對(duì)節(jié)點(diǎn)的資源控制？
Kubernetes集群里的節(jié)點(diǎn)提供的資源主要是計(jì)算資源，計(jì)算資源是可計(jì)量的能被申請(qǐng)、分配和使用的基礎(chǔ)資源。當(dāng)前Kubernetes集群中的計(jì)算資源主要包括CPU、GPU及Memory。CPU與Memory是被Pod使用的，因此在配置Pod時(shí)可以通過參數(shù)CPU Request及Memory Request為其中的每個(gè)容器指定所需使用的CPU與Memory量，Kubernetes會(huì)根據(jù)Request的值去查找有足夠資源的Node來調(diào)度此Pod。
通常，一個(gè)程序所使用的CPU與Memory是一個(gè)動(dòng)態(tài)的量，確切地說，是一個(gè)范圍，跟它的負(fù)載密切相關(guān)：負(fù)載增加時(shí)，CPU和Memory的使用量也會(huì)增加。
簡(jiǎn)述Kubernetes Requests和Limits如何影響Pod的調(diào)度？
當(dāng)一個(gè)Pod創(chuàng)建成功時(shí)，Kubernetes調(diào)度器（Scheduler）會(huì)為該P(yáng)od選擇一個(gè)節(jié)點(diǎn)來執(zhí)行。對(duì)于每種計(jì)算資源（CPU和Memory）而言，每個(gè)節(jié)點(diǎn)都有一個(gè)能用于運(yùn)行Pod的最大容量值。調(diào)度器在調(diào)度時(shí)，首先要確保調(diào)度后該節(jié)點(diǎn)上所有Pod的CPU和內(nèi)存的Requests總和，不超過該節(jié)點(diǎn)能提供給Pod使用的CPU和Memory的最大容量值。
簡(jiǎn)述Kubernetes Metric Service？
在Kubernetes從1.10版本后采用Metrics Server作為默認(rèn)的性能數(shù)據(jù)采集和監(jiān)控，主要用于提供核心指標(biāo)（Core Metrics），包括Node、Pod的CPU和內(nèi)存使用指標(biāo)。
對(duì)其他自定義指標(biāo)（Custom Metrics）的監(jiān)控則由Prometheus等組件來完成。
簡(jiǎn)述Kubernetes中，如何使用EFK實(shí)現(xiàn)日志的統(tǒng)一管理？
在Kubernetes集群環(huán)境中，通常一個(gè)完整的應(yīng)用或服務(wù)涉及組件過多，建議對(duì)日志系統(tǒng)進(jìn)行集中化管理，通常采用EFK實(shí)現(xiàn)。
EFK是 Elasticsearch、Fluentd 和 Kibana 的組合，其各組件功能如下：
Elasticsearch：是一個(gè)搜索引擎，負(fù)責(zé)存儲(chǔ)日志并提供查詢接口；
Fluentd：負(fù)責(zé)從 Kubernetes 搜集日志，每個(gè)node節(jié)點(diǎn)上面的fluentd監(jiān)控并收集該節(jié)點(diǎn)上面的系統(tǒng)日志，并將處理過后的日志信息發(fā)送給Elasticsearch；
Kibana：提供了一個(gè) Web GUI，用戶可以瀏覽和搜索存儲(chǔ)在 Elasticsearch 中的日志。
通過在每臺(tái)node上部署一個(gè)以DaemonSet方式運(yùn)行的fluentd來收集每臺(tái)node上的日志。Fluentd將docker日志目錄/var/lib/docker/containers和/var/log目錄掛載到Pod中，然后Pod會(huì)在node節(jié)點(diǎn)的/var/log/pods目錄中創(chuàng)建新的目錄，可以區(qū)別不同的容器日志輸出，該目錄下有一個(gè)日志文件鏈接到/var/lib/docker/contianers目錄下的容器日志輸出。
簡(jiǎn)述Kubernetes如何進(jìn)行優(yōu)雅的節(jié)點(diǎn)關(guān)機(jī)維護(hù)？
由于Kubernetes節(jié)點(diǎn)運(yùn)行大量Pod，因此在進(jìn)行關(guān)機(jī)維護(hù)之前，建議先使用kubectl drain將該節(jié)點(diǎn)的Pod進(jìn)行驅(qū)逐，然后進(jìn)行關(guān)機(jī)維護(hù)。
簡(jiǎn)述Kubernetes集群聯(lián)邦？
Kubernetes集群聯(lián)邦可以將多個(gè)Kubernetes集群作為一個(gè)集群進(jìn)行管理。因此，可以在一個(gè)數(shù)據(jù)中心/云中創(chuàng)建多個(gè)Kubernetes集群，并使用集群聯(lián)邦在一個(gè)地方控制/管理所有集群。
原文鏈接：https://www.yuque.com/docs/share/d3dd1e8e-6828-4da7-9e30-6a4f45c6fa8e
|免費(fèi)提升專區(qū)|
|掃碼直達(dá)|
點(diǎn)擊左下角閱讀原文獲取資料！
