簡(jiǎn)述ETCD及其特點(diǎn)？

etcd 是 CoreOS 團(tuán)隊(duì)發(fā)起的開源項(xiàng)目，是一個(gè)管理配置信息和服務(wù)發(fā)現(xiàn)（service discovery）的項(xiàng)目，它的目標(biāo)是構(gòu)建一個(gè)高可用的分布式鍵值（key-value）數(shù)據(jù)庫(kù)，基于 Go 語(yǔ)言實(shí)現(xiàn)。

特點(diǎn)：

簡(jiǎn)單：支持 REST 風(fēng)格的 HTTP+JSON API

安全：支持 HTTPS 方式的訪問(wèn)

快速：支持并發(fā) 1k/s 的寫操作

可靠：支持分布式結(jié)構(gòu)，基于 Raft 的一致性算法，Raft 是一套通過(guò)選舉主節(jié)點(diǎn)來(lái)實(shí)現(xiàn)分布式系統(tǒng)一致性的算法。

簡(jiǎn)述ETCD適應(yīng)的場(chǎng)景？

etcd基于其優(yōu)秀的特點(diǎn)，可廣泛的應(yīng)用于以下場(chǎng)景：

服務(wù)發(fā)現(xiàn)(Service Discovery)：服務(wù)發(fā)現(xiàn)主要解決在同一個(gè)分布式集群中的進(jìn)程或服務(wù)，要如何才能找到對(duì)方并建立連接。本質(zhì)上來(lái)說(shuō)，服務(wù)發(fā)現(xiàn)就是想要了解集群中是否有進(jìn)程在監(jiān)聽udp或tcp端口，并且通過(guò)名字就可以查找和連接。

消息發(fā)布與訂閱：在分布式系統(tǒng)中，最適用的一種組件間通信方式就是消息發(fā)布與訂閱。即構(gòu)建一個(gè)配置共享中心，數(shù)據(jù)提供者在這個(gè)配置中心發(fā)布消息，而消息使用者則訂閱他們關(guān)心的主題，一旦主題有消息發(fā)布，就會(huì)實(shí)時(shí)通知訂閱者。通過(guò)這種方式可以做到分布式系統(tǒng)配置的集中式管理與動(dòng)態(tài)更新。 應(yīng)用中用到的一些配置信息放到etcd上進(jìn)行集中管理。

負(fù)載均衡：在分布式系統(tǒng)中，為了保證服務(wù)的高可用以及數(shù)據(jù)的一致性，通常都會(huì)把數(shù)據(jù)和服務(wù)部署多份，以此達(dá)到對(duì)等服務(wù)，即使其中的某一個(gè)服務(wù)失效了，也不影響使用。etcd本身分布式架構(gòu)存儲(chǔ)的信息訪問(wèn)支持負(fù)載均衡。etcd集群化以后，每個(gè)etcd的核心節(jié)點(diǎn)都可以處理用戶的請(qǐng)求。所以，把數(shù)據(jù)量小但是訪問(wèn)頻繁的消息數(shù)據(jù)直接存儲(chǔ)到etcd中也可以實(shí)現(xiàn)負(fù)載均衡的效果。

分布式通知與協(xié)調(diào)：與消息發(fā)布和訂閱類似，都用到了etcd中的Watcher機(jī)制，通過(guò)注冊(cè)與異步通知機(jī)制，實(shí)現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，從而對(duì)數(shù)據(jù)變更做到實(shí)時(shí)處理。

分布式鎖：因?yàn)閑tcd使用Raft算法保持了數(shù)據(jù)的強(qiáng)一致性，某次操作存儲(chǔ)到集群中的值必然是全局一致的，所以很容易實(shí)現(xiàn)分布式鎖。鎖服務(wù)有兩種使用方式，一是保持獨(dú)占，二是控制時(shí)序。

集群監(jiān)控與Leader競(jìng)選：通過(guò)etcd來(lái)進(jìn)行監(jiān)控實(shí)現(xiàn)起來(lái)非常簡(jiǎn)單并且實(shí)時(shí)性強(qiáng)。

簡(jiǎn)述HAProxy及其特性？

HAProxy是可提供高可用性、負(fù)載均衡以及基于TCP和HTTP應(yīng)用的代理，是免費(fèi)、快速并且可靠的一種解決方案。HAProxy非常適用于并發(fā)大（并發(fā)達(dá)1w以上）web站點(diǎn)，這些站點(diǎn)通常又需要會(huì)話保持或七層處理。HAProxy的運(yùn)行模式使得它可以很簡(jiǎn)單安全的整合至當(dāng)前的架構(gòu)中，同時(shí)可以保護(hù)web服務(wù)器不被暴露到網(wǎng)絡(luò)上。

HAProxy的主要特性有：

可靠性和穩(wěn)定性非常好，可以與硬件級(jí)的F5負(fù)載均衡設(shè)備相媲美；

最高可以同時(shí)維護(hù)40000-50000個(gè)并發(fā)連接，單位時(shí)間內(nèi)處理的最大請(qǐng)求數(shù)為20000個(gè)，最大處理能力可達(dá)10Git/s；

支持多達(dá)8種負(fù)載均衡算法，同時(shí)也支持會(huì)話保持；

支持虛機(jī)主機(jī)功能，從而實(shí)現(xiàn)web負(fù)載均衡更加靈活；

支持連接拒絕、全透明代理等獨(dú)特的功能；

擁有強(qiáng)大的ACL支持，用于訪問(wèn)控制；

其獨(dú)特的彈性二叉樹數(shù)據(jù)結(jié)構(gòu)，使數(shù)據(jù)結(jié)構(gòu)的復(fù)雜性上升到了0(1)，即數(shù)據(jù)的查尋速度不會(huì)隨著數(shù)據(jù)條目的增加而速度有所下降；

支持客戶端的keepalive功能，減少客戶端與haproxy的多次三次握手導(dǎo)致資源浪費(fèi)，讓多個(gè)請(qǐng)求在一個(gè)tcp連接中完成；

支持TCP加速，零復(fù)制功能，類似于mmap機(jī)制；

支持響應(yīng)池（response buffering）；

支持RDP協(xié)議；

基于源的粘性，類似nginx的ip_hash功能，把來(lái)自同一客戶端的請(qǐng)求在一定時(shí)間內(nèi)始終調(diào)度到上游的同一服務(wù)器；

更好統(tǒng)計(jì)數(shù)據(jù)接口，其web接口顯示后端集群中各個(gè)服務(wù)器的接收、發(fā)送、拒絕、錯(cuò)誤等數(shù)據(jù)的統(tǒng)計(jì)信息；

詳細(xì)的健康狀態(tài)檢測(cè)，web接口中有關(guān)于對(duì)上游服務(wù)器的健康檢測(cè)狀態(tài)，并提供了一定的管理功能；

基于流量的健康評(píng)估機(jī)制；

基于http認(rèn)證；

基于命令行的管理接口；

日志分析器，可對(duì)日志進(jìn)行分析。

簡(jiǎn)述HAProxy常見的負(fù)載均衡策略？

HAProxy負(fù)載均衡策略非常多，常見的有如下8種：

roundrobin：表示簡(jiǎn)單的輪詢。

static-rr：表示根據(jù)權(quán)重。

leastconn：表示最少連接者先處理。

source：表示根據(jù)請(qǐng)求的源IP，類似Nginx的IP_hash機(jī)制。

ri：表示根據(jù)請(qǐng)求的URI。

rl_param：表示根據(jù)HTTP請(qǐng)求頭來(lái)鎖定每一次HTTP請(qǐng)求。

rdp-cookie(name)：表示根據(jù)據(jù)cookie(name)來(lái)鎖定并哈希每一次TCP請(qǐng)求。

簡(jiǎn)述負(fù)載均衡四層和七層的區(qū)別？

四層負(fù)載均衡器也稱為4層交換機(jī)，主要通過(guò)分析IP層及TCP/UDP層的流量實(shí)現(xiàn)基于IP加端口的負(fù)載均衡，如常見的LVS、F5等；

七層負(fù)載均衡器也稱為7層交換機(jī)，位于OSI的最高層，即應(yīng)用層，此負(fù)載均衡器支持多種協(xié)議，如HTTP、FTP、SMTP等。7層負(fù)載均衡器可根據(jù)報(bào)文內(nèi)容，配合一定的負(fù)載均衡算法來(lái)選擇后端服務(wù)器，即“內(nèi)容交換器”。如常見的HAProxy、Nginx。

簡(jiǎn)述LVS、Nginx、HAproxy的什么異同？

相同：
三者都是軟件負(fù)載均衡產(chǎn)品。

區(qū)別：

LVS基于Linux操作系統(tǒng)實(shí)現(xiàn)軟負(fù)載均衡，而HAProxy和Nginx是基于第三方應(yīng)用實(shí)現(xiàn)的軟負(fù)載均衡；

LVS是可實(shí)現(xiàn)4層的IP負(fù)載均衡技術(shù)，無(wú)法實(shí)現(xiàn)基于目錄、URL的轉(zhuǎn)發(fā)。而HAProxy和Nginx都可以實(shí)現(xiàn)4層和7層技術(shù)，HAProxy可提供TCP和HTTP應(yīng)用的負(fù)載均衡綜合解決方案；

LVS因?yàn)楣ぷ髟贗SO模型的第四層，其狀態(tài)監(jiān)測(cè)功能單一，而HAProxy在狀監(jiān)測(cè)方面功能更豐富、強(qiáng)大，可支持端口、URL、腳本等多種狀態(tài)檢測(cè)方式；

HAProxy功能強(qiáng)大，但整體性能低于4層模式的LVS負(fù)載均衡。

Nginx主要用于Web服務(wù)器或緩存服務(wù)器。

簡(jiǎn)述Heartbeat？

Heartbeat是Linux-HA項(xiàng)目中的一個(gè)組件，它提供了心跳檢測(cè)和資源接管、集群中服務(wù)的監(jiān)測(cè)、失效切換等功能。heartbeat最核心的功能包括兩個(gè)部分，心跳監(jiān)測(cè)和資源接管。心跳監(jiān)測(cè)可以通過(guò)網(wǎng)絡(luò)鏈路和串口進(jìn)行，而且支持冗余鏈路，它們之間相互發(fā)送報(bào)文來(lái)告訴對(duì)方自己當(dāng)前的狀態(tài)，如果在指定的時(shí)間內(nèi)未收到對(duì)方發(fā)送的報(bào)文，那么就認(rèn)為對(duì)方失效，這時(shí)需啟動(dòng)資源接管模塊來(lái)接管運(yùn)行在對(duì)方主機(jī)上的資源或者服務(wù)。

簡(jiǎn)述Keepalived及其工作原理？

Keepalived 是一個(gè)基于VRRP協(xié)議來(lái)實(shí)現(xiàn)的LVS服務(wù)高可用方案，可以解決靜態(tài)路由出現(xiàn)的單點(diǎn)故障問(wèn)題。

在一個(gè)LVS服務(wù)集群中通常有主服務(wù)器（MASTER）和備份服務(wù)器（BACKUP）兩種角色的服務(wù)器，但是對(duì)外表現(xiàn)為一個(gè)虛擬IP，主服務(wù)器會(huì)發(fā)送VRRP通告信息給備份服務(wù)器，當(dāng)備份服務(wù)器收不到VRRP消息的時(shí)候，即主服務(wù)器異常的時(shí)候，備份服務(wù)器就會(huì)接管虛擬IP，繼續(xù)提供服務(wù)，從而保證了高可用性。

簡(jiǎn)述Keepalived體系主要模塊及其作用？

keepalived體系架構(gòu)中主要有三個(gè)模塊，分別是core、check和vrrp。

core模塊為keepalived的核心，負(fù)責(zé)主進(jìn)程的啟動(dòng)、維護(hù)及全局配置文件的加載和解析。

vrrp模塊是來(lái)實(shí)現(xiàn)VRRP協(xié)議的。

check負(fù)責(zé)健康檢查，常見的方式有端口檢查及URL檢查。

簡(jiǎn)述Keepalived如何通過(guò)健康檢查來(lái)保證高可用？

Keepalived工作在TCP/IP模型的第三、四和五層，即網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。

網(wǎng)絡(luò)層，Keepalived采用ICMP協(xié)議向服務(wù)器集群中的每個(gè)節(jié)點(diǎn)發(fā)送一個(gè)ICMP的數(shù)據(jù)包，如果某個(gè)節(jié)點(diǎn)沒(méi)有返回響應(yīng)數(shù)據(jù)包，則認(rèn)為此節(jié)點(diǎn)發(fā)生了故障，Keepalived將報(bào)告次節(jié)點(diǎn)失效，并從服務(wù)器集群中剔除故障節(jié)點(diǎn)。

傳輸層，Keepalived利用TCP的端口連接和掃描技術(shù)來(lái)判斷集群節(jié)點(diǎn)是否正常。如常見的web服務(wù)默認(rèn)端口80，ssh默認(rèn)端口22等。Keepalived一旦在傳輸層探測(cè)到相應(yīng)端口沒(méi)用響應(yīng)數(shù)據(jù)返回，則認(rèn)為此端口發(fā)生異常，從而將此端口對(duì)應(yīng)的節(jié)點(diǎn)從服務(wù)器集群中剔除。

應(yīng)用層，可以運(yùn)行FTP、telnet、smtp、dns等各種不同類型的高層協(xié)議，Keepalived的運(yùn)行方式也更加全面化和復(fù)雜化，用戶可以通過(guò)自定義Keepalived的工作方式，來(lái)設(shè)定監(jiān)測(cè)各種程序或服務(wù)是否正常，若監(jiān)測(cè)結(jié)果與設(shè)定的正常結(jié)果不一致，將此服務(wù)對(duì)應(yīng)的節(jié)點(diǎn)從服務(wù)器集群中剔除。

Keepalived通過(guò)完整的健康檢查機(jī)制，保證集群中的所有節(jié)點(diǎn)均有效從而實(shí)現(xiàn)高可用。

簡(jiǎn)述LVS的概念及其作用？

LVS是linux virtual server的簡(jiǎn)寫linux虛擬服務(wù)器，是一個(gè)虛擬的服務(wù)器集群系統(tǒng)，可以在unix/linux平臺(tái)下實(shí)現(xiàn)負(fù)載均衡集群功能。

LVS的主要作用是：通過(guò)LVS提供的負(fù)載均衡技術(shù)實(shí)現(xiàn)一個(gè)高性能、高可用的服務(wù)器群集。因此LVS主要可以實(shí)現(xiàn)：

把單臺(tái)計(jì)算機(jī)無(wú)法承受的大規(guī)模的并發(fā)訪問(wèn)或數(shù)據(jù)流量分擔(dān)到多臺(tái)節(jié)點(diǎn)設(shè)備上分別處理，減少用戶等待響應(yīng)的時(shí)間，提升用戶體驗(yàn)。

單個(gè)重負(fù)載的運(yùn)算分擔(dān)到多臺(tái)節(jié)點(diǎn)設(shè)備上做并行處理，每個(gè)節(jié)點(diǎn)設(shè)備處理結(jié)束后，將結(jié)果匯總，返回給用戶，系統(tǒng)處理能力得到大幅度提高。

7*24小時(shí)的服務(wù)保證，任意一個(gè)或多個(gè)設(shè)備節(jié)點(diǎn)設(shè)備宕機(jī)，不能影響到業(yè)務(wù)。在負(fù)載均衡集群中，所有計(jì)算機(jī)節(jié)點(diǎn)都應(yīng)該提供相同的服務(wù)，集群負(fù)載均衡獲取所有對(duì)該服務(wù)的如站請(qǐng)求。

簡(jiǎn)述LVS的工作模式及其工作過(guò)程？

LVS 有三種負(fù)載均衡的模式，分別是VS/NAT（nat 模式）、VS/DR（路由模式）、VS/TUN（隧道模式）。

NAT模式（VS-NAT）

原理：首先負(fù)載均衡器接收到客戶的請(qǐng)求數(shù)據(jù)包時(shí)，根據(jù)調(diào)度算法決定將請(qǐng)求發(fā)送給哪個(gè)后端的真實(shí)服務(wù)器（RS）。然后負(fù)載均衡器就把客戶端發(fā)送的請(qǐng)求數(shù)據(jù)包的目標(biāo)IP地址及端口改成后端真實(shí)服務(wù)器的IP地址（RIP）。真實(shí)服務(wù)器響應(yīng)完請(qǐng)求后，查看默認(rèn)路由，把響應(yīng)后的數(shù)據(jù)包發(fā)送給負(fù)載均衡器，負(fù)載均衡器在接收到響應(yīng)包后，把包的源地址改成虛擬地址（VIP）然后發(fā)送回給客戶端。

優(yōu)點(diǎn)：集群中的服務(wù)器可以使用任何支持TCP/IP的操作系統(tǒng)，只要負(fù)載均衡器有一個(gè)合法的IP地址。

缺點(diǎn)：擴(kuò)展性有限，當(dāng)服務(wù)器節(jié)點(diǎn)增長(zhǎng)過(guò)多時(shí)，由于所有的請(qǐng)求和應(yīng)答都需要經(jīng)過(guò)負(fù)載均衡器，因此負(fù)載均衡器將成為整個(gè)系統(tǒng)的瓶頸。

IP隧道模式（VS-TUN）

原理：首先負(fù)載均衡器接收到客戶的請(qǐng)求數(shù)據(jù)包時(shí)，根據(jù)調(diào)度算法決定將請(qǐng)求發(fā)送給哪個(gè)后端的真實(shí)服務(wù)器（RS）。然后負(fù)載均衡器就把客戶端發(fā)送的請(qǐng)求報(bào)文封裝一層IP隧道（T-IP）轉(zhuǎn)發(fā)到真實(shí)服務(wù)器（RS）。真實(shí)服務(wù)器響應(yīng)完請(qǐng)求后，查看默認(rèn)路由，把響應(yīng)后的數(shù)據(jù)包直接發(fā)送給客戶端，不需要經(jīng)過(guò)負(fù)載均衡器。

優(yōu)點(diǎn)：負(fù)載均衡器只負(fù)責(zé)將請(qǐng)求包分發(fā)給后端節(jié)點(diǎn)服務(wù)器，而RS將應(yīng)答包直接發(fā)給用戶。所以，減少了負(fù)載均衡器的大量數(shù)據(jù)流動(dòng)，負(fù)載均衡器不再是系統(tǒng)的瓶頸，也能處理很巨大的請(qǐng)求量。

缺點(diǎn)：隧道模式的RS節(jié)點(diǎn)需要合法IP，這種方式需要所有的服務(wù)器支持“IP Tunneling”。

直接路由模式（VS-DR）

原理：首先負(fù)載均衡器接收到客戶的請(qǐng)求數(shù)據(jù)包時(shí)，根據(jù)調(diào)度算法決定將請(qǐng)求發(fā)送給哪個(gè)后端的真實(shí)服務(wù)器（RS）。然后負(fù)載均衡器就把客戶端發(fā)送的請(qǐng)求數(shù)據(jù)包的目標(biāo)MAC地址改成后端真實(shí)服務(wù)器的MAC地址（R-MAC）。真實(shí)服務(wù)器響應(yīng)完請(qǐng)求后，查看默認(rèn)路由，把響應(yīng)后的數(shù)據(jù)包直接發(fā)送給客戶端，不需要經(jīng)過(guò)負(fù)載均衡器。

優(yōu)點(diǎn)：負(fù)載均衡器只負(fù)責(zé)將請(qǐng)求包分發(fā)給后端節(jié)點(diǎn)服務(wù)器，而RS將應(yīng)答包直接發(fā)給用戶。所以，減少了負(fù)載均衡器的大量數(shù)據(jù)流動(dòng)，負(fù)載均衡器不再是系統(tǒng)的瓶頸，也能處理很巨大的請(qǐng)求量。

缺點(diǎn)：需要負(fù)載均衡器與真實(shí)服務(wù)器RS都有一塊網(wǎng)卡連接到同一物理網(wǎng)段上，必須在同一個(gè)局域網(wǎng)環(huán)境。

簡(jiǎn)述LVS調(diào)度器常見算法（均衡策略）？

LVS調(diào)度器用的調(diào)度方法基本分為兩類：

固定調(diào)度算法：rr，wrr，dh，sh

rr：輪詢算法，將請(qǐng)求依次分配給不同的rs節(jié)點(diǎn)，即RS節(jié)點(diǎn)中均攤分配。適合于RS所有節(jié)點(diǎn)處理性能接近的情況。

wrr：加權(quán)輪訓(xùn)調(diào)度，依據(jù)不同RS的權(quán)值分配任務(wù)。權(quán)值較高的RS將優(yōu)先獲得任務(wù)，并且分配到的連接數(shù)將比權(quán)值低的RS更多。相同權(quán)值的RS得到相同數(shù)目的連接數(shù)。

dh：目的地址哈希調(diào)度（destination hashing）以目的地址為關(guān)鍵字查找一個(gè)靜態(tài)hash表來(lái)獲得所需RS。

sh：源地址哈希調(diào)度（source hashing）以源地址為關(guān)鍵字查找一個(gè)靜態(tài)hash表來(lái)獲得需要的RS。

動(dòng)態(tài)調(diào)度算法：wlc，lc，lblc，lblcr

wlc：加權(quán)最小連接數(shù)調(diào)度，假設(shè)各臺(tái)RS的權(quán)值依次為Wi，當(dāng)前tcp連接數(shù)依次為Ti，依次去Ti/Wi為最小的RS作為下一個(gè)分配的RS。

lc：最小連接數(shù)調(diào)度（least-connection），IPVS表存儲(chǔ)了所有活動(dòng)的連接。LB會(huì)比較將連接請(qǐng)求發(fā)送到當(dāng)前連接最少的RS。

lblc：基于地址的最小連接數(shù)調(diào)度（locality-based least-connection）：將來(lái)自同一個(gè)目的地址的請(qǐng)求分配給同一臺(tái)RS，此時(shí)這臺(tái)服務(wù)器是尚未滿負(fù)荷的。否則就將這個(gè)請(qǐng)求分配給連接數(shù)最小的RS，并以它作為下一次分配的首先考慮。

簡(jiǎn)述LVS、Nginx、HAProxy各自優(yōu)缺點(diǎn)？

Nginx的優(yōu)點(diǎn)：

工作在網(wǎng)絡(luò)的7層之上，可以針對(duì)http應(yīng)用做一些分流的策略，比如針對(duì)域名、目錄結(jié)構(gòu)。Nginx正則規(guī)則比HAProxy更為強(qiáng)大和靈活。

Nginx對(duì)網(wǎng)絡(luò)穩(wěn)定性的依賴非常小，理論上能ping通就就能進(jìn)行負(fù)載功能，LVS對(duì)網(wǎng)絡(luò)穩(wěn)定性依賴比較大，穩(wěn)定要求相對(duì)更高。

Nginx安裝和配置、測(cè)試比較簡(jiǎn)單、方便，有清晰的日志用于排查和管理，LVS的配置、測(cè)試就要花比較長(zhǎng)的時(shí)間了。

可以承擔(dān)高負(fù)載壓力且穩(wěn)定，一般能支撐幾萬(wàn)次的并發(fā)量，負(fù)載度比LVS相對(duì)小些。

Nginx可以通過(guò)端口檢測(cè)到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁(yè)返回的狀態(tài)碼、超時(shí)等等。

Nginx不僅僅是一款優(yōu)秀的負(fù)載均衡器/反向代理軟件，它同時(shí)也是功能強(qiáng)大的Web應(yīng)用服務(wù)器。

Nginx作為Web反向加速緩存越來(lái)越成熟了，速度比傳統(tǒng)的Squid服務(wù)器更快，很多場(chǎng)景下都將其作為反向代理加速器。

Nginx作為靜態(tài)網(wǎng)頁(yè)和圖片服務(wù)器，這方面的性能非常優(yōu)秀，同時(shí)第三方模塊也很多。

Nginx的缺點(diǎn)：

Nginx僅能支持http、https和Email協(xié)議，這樣就在適用范圍上面小些。

對(duì)后端服務(wù)器的健康檢查，只支持通過(guò)端口來(lái)檢測(cè)，不支持通過(guò)url來(lái)檢測(cè)。

不支持Session的直接保持，需要通過(guò)ip_hash來(lái)解決。

LVS的優(yōu)點(diǎn)：

抗負(fù)載能力強(qiáng)、是工作在網(wǎng)絡(luò)4層之上僅作分發(fā)之用，沒(méi)有流量的產(chǎn)生。因此負(fù)載均衡軟件里的性能最強(qiáng)的，對(duì)內(nèi)存和cpu資源消耗比較低。

LVS工作穩(wěn)定，因?yàn)槠浔旧砜关?fù)載能力很強(qiáng)，自身有完整的雙機(jī)熱備方案。

無(wú)流量，LVS只分發(fā)請(qǐng)求，而流量并不從它本身出去，這點(diǎn)保證了均衡器IO的性能不會(huì)收到大流量的影響。

應(yīng)用范圍較廣，因?yàn)長(zhǎng)VS工作在4層，所以它幾乎可對(duì)所有應(yīng)用做負(fù)載均衡，包括http、數(shù)據(jù)庫(kù)等。

LVS的缺點(diǎn)是：

軟件本身不支持正則表達(dá)式處理，不能做動(dòng)靜分離。相對(duì)來(lái)說(shuō)，Nginx/HAProxy+Keepalived則具有明顯的優(yōu)勢(shì)。

如果是網(wǎng)站應(yīng)用比較龐大的話，LVS/DR+Keepalived實(shí)施起來(lái)就比較復(fù)雜了。相對(duì)來(lái)說(shuō)，Nginx/HAProxy+Keepalived就簡(jiǎn)單多了。

HAProxy的優(yōu)點(diǎn)：

HAProxy也是支持虛擬主機(jī)的。

HAProxy的優(yōu)點(diǎn)能夠補(bǔ)充Nginx的一些缺點(diǎn)，比如支持Session的保持，Cookie的引導(dǎo)，同時(shí)支持通過(guò)獲取指定的url來(lái)檢測(cè)后端服務(wù)器的狀態(tài)。

HAProxy跟LVS類似，本身就只是一款負(fù)載均衡軟件，單純從效率上來(lái)講HAProxy會(huì)比Nginx有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于Nginx的。

HAProxy支持TCP協(xié)議的負(fù)載均衡轉(zhuǎn)發(fā)。

簡(jiǎn)述代理服務(wù)器的概念及其作用？

代理服務(wù)器是一個(gè)位于客戶端和原始（資源）服務(wù)器之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理服務(wù)器發(fā)送一個(gè)請(qǐng)求并指定目標(biāo)原始服務(wù)器，然后代理服務(wù)器向原始服務(wù)器轉(zhuǎn)交請(qǐng)求并將獲得的內(nèi)容返回給客戶端。

其主要作用有：

資源獲取：代替客戶端實(shí)現(xiàn)從原始服務(wù)器的資源獲取；

加速訪問(wèn)：代理服務(wù)器可能離原始服務(wù)器更近，從而起到一定的加速作用；

緩存作用：代理服務(wù)器保存從原始服務(wù)器所獲取的資源，從而實(shí)現(xiàn)客戶端快速的獲取；

隱藏真實(shí)地址：代理服務(wù)器代替客戶端去獲取原始服務(wù)器資源，從而隱藏客戶端真實(shí)信息。

簡(jiǎn)述高可用集群可通過(guò)哪兩個(gè)維度衡量高可用性，各自含義是什么？

RTO（Recovery Time Objective）：RTO指服務(wù)恢復(fù)的時(shí)間，最佳的情況是 0，即服務(wù)立即恢復(fù)；最壞是無(wú)窮大，即服務(wù)永遠(yuǎn)無(wú)法恢復(fù)；

RPO（Recovery Point Objective）：RPO 指指當(dāng)災(zāi)難發(fā)生時(shí)允許丟失的數(shù)據(jù)量，0 意味著使用同步的數(shù)據(jù)，大于 0 意味著有數(shù)據(jù)丟失，如“RPO=1 d”指恢復(fù)時(shí)使用一天前的數(shù)據(jù)，那么一天之內(nèi)的數(shù)據(jù)就丟失了。因此，恢復(fù)的最佳情況是 RTO = RPO = 0，幾乎無(wú)法實(shí)現(xiàn)。

簡(jiǎn)述什么是CAP理論？

CAP理論指出了在分布式系統(tǒng)中需要滿足的三個(gè)條件，主要包括：

Consistency（一致性）：所有節(jié)點(diǎn)在同一時(shí)間具有相同的數(shù)據(jù)；

Availability（可用性）：保證每個(gè)請(qǐng)求不管成功或者失敗都有響應(yīng)；

Partition tolerance（分區(qū)容錯(cuò)性）：系統(tǒng)中任意信息的丟失或失敗不影響系統(tǒng)的繼續(xù)運(yùn)行。

CAP 理論的核心是：一個(gè)分布式系統(tǒng)不可能同時(shí)很好的滿足一致性，可用性和分區(qū)容錯(cuò)性這三個(gè)需求，最多只能同時(shí)較好的滿足兩個(gè)。

簡(jiǎn)述什么是ACID理論？

原子性(Atomicity)：整體不可分割性，要么全做要不全不做；

一致性(Consistency)：事務(wù)執(zhí)行前、后數(shù)據(jù)庫(kù)狀態(tài)均一致；

隔離性(Isolation)：在事務(wù)未提交前，它操作的數(shù)據(jù)，對(duì)其它用戶不可見；

持久性 (Durable)：一旦事務(wù)成功，將進(jìn)行永久的變更，記錄與redo日志。

簡(jiǎn)述什么是Kubernetes？

Kubernetes是一個(gè)全新的基于容器技術(shù)的分布式系統(tǒng)支撐平臺(tái)。是Google開源的容器集群管理系統(tǒng)（谷歌內(nèi)部:Borg）。在Docker技術(shù)的基礎(chǔ)上，為容器化的應(yīng)用提供部署運(yùn)行、資源調(diào)度、服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)伸縮等一系列完整功能，提高了大規(guī)模容器集群管理的便捷性。并且具有完備的集群管理能力，多層次的安全防護(hù)和準(zhǔn)入機(jī)制、多租戶應(yīng)用支撐能力、透明的服務(wù)注冊(cè)和發(fā)現(xiàn)機(jī)制、內(nèi)建智能負(fù)載均衡器、強(qiáng)大的故障發(fā)現(xiàn)和自我修復(fù)能力、服務(wù)滾動(dòng)升級(jí)和在線擴(kuò)容能力、可擴(kuò)展的資源自動(dòng)調(diào)度機(jī)制以及多粒度的資源配額管理能力。

簡(jiǎn)述Kubernetes和Docker的關(guān)系？

Docker 提供容器的生命周期管理和，Docker 鏡像構(gòu)建運(yùn)行時(shí)容器。它的主要優(yōu)點(diǎn)是將將軟件/應(yīng)用程序運(yùn)行所需的設(shè)置和依賴項(xiàng)打包到一個(gè)容器中，從而實(shí)現(xiàn)了可移植性等優(yōu)點(diǎn)。

Kubernetes 用于關(guān)聯(lián)和編排在多個(gè)主機(jī)上運(yùn)行的容器。

簡(jiǎn)述Kubernetes中什么是Minikube、Kubectl、Kubelet？

Minikube?是一種可以在本地輕松運(yùn)行一個(gè)單節(jié)點(diǎn) Kubernetes 群集的工具。

Kubectl?是一個(gè)命令行工具，可以使用該工具控制Kubernetes集群管理器，如檢查群集資源，創(chuàng)建、刪除和更新組件，查看應(yīng)用程序。

Kubelet?是一個(gè)代理服務(wù)，它在每個(gè)節(jié)點(diǎn)上運(yùn)行，并使從服務(wù)器與主服務(wù)器通信。

簡(jiǎn)述Kubernetes常見的部署方式？

常見的Kubernetes部署方式有：

kubeadm：也是推薦的一種部署方式；

二進(jìn)制：

minikube：在本地輕松運(yùn)行一個(gè)單節(jié)點(diǎn) Kubernetes 群集的工具。

簡(jiǎn)述Kubernetes如何實(shí)現(xiàn)集群管理？

在集群管理方面，Kubernetes將集群中的機(jī)器劃分為一個(gè)Master節(jié)點(diǎn)和一群工作節(jié)點(diǎn)Node。其中，在Master節(jié)點(diǎn)運(yùn)行著集群管理相關(guān)的一組進(jìn)程kube-apiserver、kube-controller-manager和kube-scheduler，這些進(jìn)程實(shí)現(xiàn)了整個(gè)集群的資源管理、Pod調(diào)度、彈性伸縮、安全控制、系統(tǒng)監(jiān)控和糾錯(cuò)等管理能力，并且都是全自動(dòng)完成的。

簡(jiǎn)述Kubernetes的優(yōu)勢(shì)、適應(yīng)場(chǎng)景及其特點(diǎn)？

Kubernetes作為一個(gè)完備的分布式系統(tǒng)支撐平臺(tái)，其主要優(yōu)勢(shì)：

容器編排

輕量級(jí)

開源

彈性伸縮

負(fù)載均衡

Kubernetes常見場(chǎng)景：

快速部署應(yīng)用

快速擴(kuò)展應(yīng)用

無(wú)縫對(duì)接新的應(yīng)用功能

節(jié)省資源，優(yōu)化硬件資源的使用

Kubernetes相關(guān)特點(diǎn)：

可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）。

可擴(kuò)展: 模塊化,、插件化、可掛載、可組合。

自動(dòng)化: 自動(dòng)部署、自動(dòng)重啟、自動(dòng)復(fù)制、自動(dòng)伸縮/擴(kuò)展。

簡(jiǎn)述Kubernetes的缺點(diǎn)或當(dāng)前的不足之處？

Kubernetes當(dāng)前存在的缺點(diǎn)（不足）如下：

安裝過(guò)程和配置相對(duì)困難復(fù)雜。

管理服務(wù)相對(duì)繁瑣。

運(yùn)行和編譯需要很多時(shí)間。

它比其他替代品更昂貴。

對(duì)于簡(jiǎn)單的應(yīng)用程序來(lái)說(shuō)，可能不需要涉及Kubernetes即可滿足。

簡(jiǎn)述Kubernetes相關(guān)基礎(chǔ)概念？

master：k8s集群的管理節(jié)點(diǎn)，負(fù)責(zé)管理集群，提供集群的資源數(shù)據(jù)訪問(wèn)入口。擁有Etcd存儲(chǔ)服務(wù)（可選），運(yùn)行Api Server進(jìn)程，Controller Manager服務(wù)進(jìn)程及Scheduler服務(wù)進(jìn)程。

node（worker）：Node（worker）是Kubernetes集群架構(gòu)中運(yùn)行Pod的服務(wù)節(jié)點(diǎn)，是Kubernetes集群操作的單元，用來(lái)承載被分配Pod的運(yùn)行，是Pod運(yùn)行的宿主機(jī)。運(yùn)行docker eninge服務(wù)，守護(hù)進(jìn)程kunelet及負(fù)載均衡器kube-proxy。

pod：運(yùn)行于Node節(jié)點(diǎn)上，若干相關(guān)容器的組合。Pod內(nèi)包含的容器運(yùn)行在同一宿主機(jī)上，使用相同的網(wǎng)絡(luò)命名空間、IP地址和端口，能夠通過(guò)localhost進(jìn)行通信。Pod是Kurbernetes進(jìn)行創(chuàng)建、調(diào)度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個(gè)Pod可以包含一個(gè)容器或者多個(gè)相關(guān)容器。

label：Kubernetes中的Label實(shí)質(zhì)是一系列的Key/Value鍵值對(duì)，其中key與value可自定義。Label可以附加到各種資源對(duì)象上，如Node、Pod、Service、RC等。一個(gè)資源對(duì)象可以定義任意數(shù)量的Label，同一個(gè)Label也可以被添加到任意數(shù)量的資源對(duì)象上去。Kubernetes通過(guò)Label Selector（標(biāo)簽選擇器）查詢和篩選資源對(duì)象。

Replication Controller：Replication Controller用來(lái)管理Pod的副本，保證集群中存在指定數(shù)量的Pod副本。集群中副本的數(shù)量大于指定數(shù)量，則會(huì)停止指定數(shù)量之外的多余容器數(shù)量。反之，則會(huì)啟動(dòng)少于指定數(shù)量個(gè)數(shù)的容器，保證數(shù)量不變。Replication Controller是實(shí)現(xiàn)彈性伸縮、動(dòng)態(tài)擴(kuò)容和滾動(dòng)升級(jí)的核心。

Deployment：Deployment在內(nèi)部使用了RS來(lái)實(shí)現(xiàn)目的，Deployment相當(dāng)于RC的一次升級(jí)，其最大的特色為可以隨時(shí)獲知當(dāng)前Pod的部署進(jìn)度。

HPA（Horizontal Pod Autoscaler）：Pod的橫向自動(dòng)擴(kuò)容，也是Kubernetes的一種資源，通過(guò)追蹤分析RC控制的所有Pod目標(biāo)的負(fù)載變化情況，來(lái)確定是否需要針對(duì)性的調(diào)整Pod副本數(shù)量。

Service：Service定義了Pod的邏輯集合和訪問(wèn)該集合的策略，是真實(shí)服務(wù)的抽象。Service提供了一個(gè)統(tǒng)一的服務(wù)訪問(wèn)入口以及服務(wù)代理和發(fā)現(xiàn)機(jī)制，關(guān)聯(lián)多個(gè)相同Label的Pod，用戶不需要了解后臺(tái)Pod是如何運(yùn)行。

Volume：Volume是Pod中能夠被多個(gè)容器訪問(wèn)的共享目錄，Kubernetes中的Volume是定義在Pod上，可以被一個(gè)或多個(gè)Pod中的容器掛載到某個(gè)目錄下。

Namespace：Namespace用于實(shí)現(xiàn)多租戶的資源隔離，可將集群內(nèi)部的資源對(duì)象分配到不同的Namespace中，形成邏輯上的不同項(xiàng)目、小組或用戶組，便于不同的Namespace在共享使用整個(gè)集群的資源的同時(shí)還能被分別管理。

簡(jiǎn)述Kubernetes集群相關(guān)組件？

Kubernetes Master控制組件，調(diào)度管理整個(gè)系統(tǒng)（集群），包含如下組件:

Kubernetes API Server：作為Kubernetes系統(tǒng)的入口，其封裝了核心對(duì)象的增刪改查操作，以RESTful API接口方式提供給外部客戶和內(nèi)部組件調(diào)用，集群內(nèi)各個(gè)功能模塊之間數(shù)據(jù)交互和通信的中心樞紐。

Kubernetes Scheduler：為新建立的Pod進(jìn)行節(jié)點(diǎn)(node)選擇(即分配機(jī)器)，負(fù)責(zé)集群的資源調(diào)度。

Kubernetes Controller：負(fù)責(zé)執(zhí)行各種控制器，目前已經(jīng)提供了很多控制器來(lái)保證Kubernetes的正常運(yùn)行。

Replication Controller：管理維護(hù)Replication Controller，關(guān)聯(lián)Replication Controller和Pod，保證Replication Controller定義的副本數(shù)量與實(shí)際運(yùn)行Pod數(shù)量一致。

Node Controller：管理維護(hù)Node，定期檢查Node的健康狀態(tài)，標(biāo)識(shí)出(失效|未失效)的Node節(jié)點(diǎn)。

Namespace Controller：管理維護(hù)Namespace，定期清理無(wú)效的Namespace，包括Namesapce下的API對(duì)象，比如Pod、Service等。

Service Controller：管理維護(hù)Service，提供負(fù)載以及服務(wù)代理。

EndPoints Controller：管理維護(hù)Endpoints，關(guān)聯(lián)Service和Pod，創(chuàng)建Endpoints為Service的后端，當(dāng)Pod發(fā)生變化時(shí)，實(shí)時(shí)更新Endpoints。

Service Account Controller：管理維護(hù)Service Account，為每個(gè)Namespace創(chuàng)建默認(rèn)的Service Account，同時(shí)為Service Account創(chuàng)建Service Account Secret。

Persistent Volume Controller：管理維護(hù)Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進(jìn)行綁定，為釋放的Persistent Volume執(zhí)行清理回收。

Daemon Set Controller：管理維護(hù)Daemon Set，負(fù)責(zé)創(chuàng)建Daemon Pod，保證指定的Node上正常的運(yùn)行Daemon Pod。

Deployment Controller：管理維護(hù)Deployment，關(guān)聯(lián)Deployment和Replication Controller，保證運(yùn)行指定數(shù)量的Pod。當(dāng)Deployment更新時(shí)，控制實(shí)現(xiàn)Replication Controller和Pod的更新。

Job Controller：管理維護(hù)Job，為Jod創(chuàng)建一次性任務(wù)Pod，保證完成Job指定完成的任務(wù)數(shù)目

Pod Autoscaler Controller：實(shí)現(xiàn)Pod的自動(dòng)伸縮，定時(shí)獲取監(jiān)控?cái)?shù)據(jù)，進(jìn)行策略匹配，當(dāng)滿足條件時(shí)執(zhí)行Pod的伸縮動(dòng)作。

簡(jiǎn)述Kubernetes RC的機(jī)制？

Replication Controller用來(lái)管理Pod的副本，保證集群中存在指定數(shù)量的Pod副本。當(dāng)定義了RC并提交至Kubernetes集群中之后，Master節(jié)點(diǎn)上的Controller Manager組件獲悉，并同時(shí)巡檢系統(tǒng)中當(dāng)前存活的目標(biāo)Pod，并確保目標(biāo)Pod實(shí)例的數(shù)量剛好等于此RC的期望值，若存在過(guò)多的Pod副本在運(yùn)行，系統(tǒng)會(huì)停止一些Pod，反之則自動(dòng)創(chuàng)建一些Pod。

簡(jiǎn)述Kubernetes Replica Set 和 Replication Controller 之間有什么區(qū)別？

Replica Set 和 Replication Controller 類似，都是確保在任何給定時(shí)間運(yùn)行指定數(shù)量的 Pod 副本。不同之處在于RS 使用基于集合的選擇器，而 Replication Controller 使用基于權(quán)限的選擇器。

簡(jiǎn)述kube-proxy作用？

kube-proxy 運(yùn)行在所有節(jié)點(diǎn)上，它監(jiān)聽 apiserver 中 service 和 endpoint 的變化情況，創(chuàng)建路由規(guī)則以提供服務(wù) IP 和負(fù)載均衡功能。簡(jiǎn)單理解此進(jìn)程是Service的透明代理兼負(fù)載均衡器，其核心功能是將到某個(gè)Service的訪問(wèn)請(qǐng)求轉(zhuǎn)發(fā)到后端的多個(gè)Pod實(shí)例上。

簡(jiǎn)述kube-proxy iptables原理？

Kubernetes從1.2版本開始，將iptables作為kube-proxy的默認(rèn)模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過(guò)API Server的Watch接口實(shí)時(shí)跟蹤Service與Endpoint的變更信息，并更新對(duì)應(yīng)的iptables規(guī)則，Client的請(qǐng)求流量則通過(guò)iptables的NAT機(jī)制“直接路由”到目標(biāo)Pod。

簡(jiǎn)述kube-proxy ipvs原理？

IPVS在Kubernetes1.11中升級(jí)為GA穩(wěn)定版。IPVS則專門用于高性能負(fù)載均衡，并使用更高效的數(shù)據(jù)結(jié)構(gòu)（Hash表），允許幾乎無(wú)限的規(guī)模擴(kuò)張，因此被kube-proxy采納為最新模式。

在IPVS模式下，使用iptables的擴(kuò)展ipset，而不是直接調(diào)用iptables來(lái)生成規(guī)則鏈。iptables規(guī)則鏈?zhǔn)且粋€(gè)線性的數(shù)據(jù)結(jié)構(gòu)，ipset則引入了帶索引的數(shù)據(jù)結(jié)構(gòu)，因此當(dāng)規(guī)則很多時(shí)，也可以很高效地查找和匹配。

可以將ipset簡(jiǎn)單理解為一個(gè)IP（段）的集合，這個(gè)集合的內(nèi)容可以是IP地址、IP網(wǎng)段、端口等，iptables可以直接添加規(guī)則對(duì)這個(gè)“可變的集合”進(jìn)行操作，這樣做的好處在于可以大大減少iptables規(guī)則的數(shù)量，從而減少性能損耗。

簡(jiǎn)述kube-proxy ipvs和iptables的異同？

iptables與IPVS都是基于Netfilter實(shí)現(xiàn)的，但因?yàn)槎ㄎ徊煌哂兄举|(zhì)的差別：iptables是為防火墻而設(shè)計(jì)的；IPVS則專門用于高性能負(fù)載均衡，并使用更高效的數(shù)據(jù)結(jié)構(gòu)（Hash表），允許幾乎無(wú)限的規(guī)模擴(kuò)張。

與iptables相比，IPVS擁有以下明顯優(yōu)勢(shì)：

1、為大型集群提供了更好的可擴(kuò)展性和性能；

2、支持比iptables更復(fù)雜的復(fù)制均衡算法（最小負(fù)載、最少連接、加權(quán)等）；

3、支持服務(wù)器健康檢查和連接重試等功能；

4、可以動(dòng)態(tài)修改ipset的集合，即使iptables的規(guī)則正在使用這個(gè)集合。

簡(jiǎn)述Kubernetes中什么是靜態(tài)Pod？

靜態(tài)pod是由kubelet進(jìn)行管理的僅存在于特定Node的Pod上，他們不能通過(guò)API Server進(jìn)行管理，無(wú)法與ReplicationController、Deployment或者DaemonSet進(jìn)行關(guān)聯(lián)，并且kubelet無(wú)法對(duì)他們進(jìn)行健康檢查。靜態(tài)Pod總是由kubelet進(jìn)行創(chuàng)建，并且總是在kubelet所在的Node上運(yùn)行。

簡(jiǎn)述Kubernetes中Pod可能位于的狀態(tài)？

Pending：API Server已經(jīng)創(chuàng)建該P(yáng)od，且Pod內(nèi)還有一個(gè)或多個(gè)容器的鏡像沒(méi)有創(chuàng)建，包括正在下載鏡像的過(guò)程。

Running：Pod內(nèi)所有容器均已創(chuàng)建，且至少有一個(gè)容器處于運(yùn)行狀態(tài)、正在啟動(dòng)狀態(tài)或正在重啟狀態(tài)。

Succeeded：Pod內(nèi)所有容器均成功執(zhí)行退出，且不會(huì)重啟。

Failed：Pod內(nèi)所有容器均已退出，但至少有一個(gè)容器退出為失敗狀態(tài)。

Unknown：由于某種原因無(wú)法獲取該P(yáng)od狀態(tài)，可能由于網(wǎng)絡(luò)通信不暢導(dǎo)致。

簡(jiǎn)述Kubernetes創(chuàng)建一個(gè)Pod的主要流程？

Kubernetes中創(chuàng)建一個(gè)Pod涉及多個(gè)組件之間聯(lián)動(dòng)，主要流程如下：

1、客戶端提交Pod的配置信息（可以是yaml文件定義的信息）到kube-apiserver。

2、Apiserver收到指令后，通知給controller-manager創(chuàng)建一個(gè)資源對(duì)象。

3、Controller-manager通過(guò)api-server將pod的配置信息存儲(chǔ)到ETCD數(shù)據(jù)中心中。

4、Kube-scheduler檢測(cè)到pod信息會(huì)開始調(diào)度預(yù)選，會(huì)先過(guò)濾掉不符合Pod資源配置要求的節(jié)點(diǎn)，然后開始調(diào)度調(diào)優(yōu)，主要是挑選出更適合運(yùn)行pod的節(jié)點(diǎn)，然后將pod的資源配置單發(fā)送到node節(jié)點(diǎn)上的kubelet組件上。

5、Kubelet根據(jù)scheduler發(fā)來(lái)的資源配置單運(yùn)行pod，運(yùn)行成功后，將pod的運(yùn)行信息返回給scheduler，scheduler將返回的pod運(yùn)行狀況的信息存儲(chǔ)到etcd數(shù)據(jù)中心。

簡(jiǎn)述Kubernetes中Pod的重啟策略？

Pod重啟策略（RestartPolicy）應(yīng)用于Pod內(nèi)的所有容器，并且僅在Pod所處的Node上由kubelet進(jìn)行判斷和重啟操作。當(dāng)某個(gè)容器異常退出或者健康檢查失敗時(shí)，kubelet將根據(jù)RestartPolicy的設(shè)置來(lái)進(jìn)行相應(yīng)操作。

Pod的重啟策略包括Always、OnFailure和Never，默認(rèn)值為Always。

Always：當(dāng)容器失效時(shí)，由kubelet自動(dòng)重啟該容器；

OnFailure：當(dāng)容器終止運(yùn)行且退出碼不為0時(shí)，由kubelet自動(dòng)重啟該容器；

Never：不論容器運(yùn)行狀態(tài)如何，kubelet都不會(huì)重啟該容器。

同時(shí)Pod的重啟策略與控制方式關(guān)聯(lián)，當(dāng)前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接管理kubelet管理（靜態(tài)Pod）。

不同控制器的重啟策略限制如下：

RC和DaemonSet：必須設(shè)置為Always，需要保證該容器持續(xù)運(yùn)行；

Job：OnFailure或Never，確保容器執(zhí)行完成后不再重啟；

kubelet：在Pod失效時(shí)重啟，不論將RestartPolicy設(shè)置為何值，也不會(huì)對(duì)Pod進(jìn)行健康檢查。

簡(jiǎn)述Kubernetes中Pod的健康檢查方式？

對(duì)Pod的健康檢查可以通過(guò)兩類探針來(lái)檢查：LivenessProbe和ReadinessProbe。

LivenessProbe探針：用于判斷容器是否存活（running狀態(tài)），如果LivenessProbe探針探測(cè)到容器不健康，則kubelet將殺掉該容器，并根據(jù)容器的重啟策略做相應(yīng)處理。若一個(gè)容器不包含LivenessProbe探針，kubelet認(rèn)為該容器的LivenessProbe探針?lè)祷刂涤糜谑恰癝uccess”。

ReadineeProbe探針：用于判斷容器是否啟動(dòng)完成（ready狀態(tài)）。如果ReadinessProbe探針探測(cè)到失敗，則Pod的狀態(tài)將被修改。Endpoint Controller將從Service的Endpoint中刪除包含該容器所在Pod的Eenpoint。

startupProbe探針：?jiǎn)?dòng)檢查機(jī)制，應(yīng)用一些啟動(dòng)緩慢的業(yè)務(wù)，避免業(yè)務(wù)長(zhǎng)時(shí)間啟動(dòng)而被上面兩類探針kill掉。

簡(jiǎn)述Kubernetes Pod的LivenessProbe探針的常見方式？

kubelet定期執(zhí)行LivenessProbe探針來(lái)診斷容器的健康狀態(tài)，通常有以下三種方式：

ExecAction：在容器內(nèi)執(zhí)行一個(gè)命令，若返回碼為0，則表明容器健康。

TCPSocketAction：通過(guò)容器的IP地址和端口號(hào)執(zhí)行TCP檢查，若能建立TCP連接，則表明容器健康。

HTTPGetAction：通過(guò)容器的IP地址、端口號(hào)及路徑調(diào)用HTTP Get方法，若響應(yīng)的狀態(tài)碼大于等于200且小于400，則表明容器健康。

簡(jiǎn)述Kubernetes Pod的常見調(diào)度方式？

Kubernetes中，Pod通常是容器的載體，主要有如下常見調(diào)度方式：

Deployment或RC：該調(diào)度策略主要功能就是自動(dòng)部署一個(gè)容器應(yīng)用的多份副本，以及持續(xù)監(jiān)控副本的數(shù)量，在集群內(nèi)始終維持用戶指定的副本數(shù)量。

NodeSelector：定向調(diào)度，當(dāng)需要手動(dòng)指定將Pod調(diào)度到特定Node上，可以通過(guò)Node的標(biāo)簽（Label）和Pod的nodeSelector屬性相匹配。

NodeAffinity親和性調(diào)度：親和性調(diào)度機(jī)制極大的擴(kuò)展了Pod的調(diào)度能力，目前有兩種節(jié)點(diǎn)親和力表達(dá)：

requiredDuringSchedulingIgnoredDuringExecution：硬規(guī)則，必須滿足指定的規(guī)則，調(diào)度器才可以調(diào)度Pod至Node上（類似nodeSelector，語(yǔ)法不同）。

preferredDuringSchedulingIgnoredDuringExecution：軟規(guī)則，優(yōu)先調(diào)度至滿足的Node的節(jié)點(diǎn)，但不強(qiáng)求，多個(gè)優(yōu)先級(jí)規(guī)則還可以設(shè)置權(quán)重值。

Taints和Tolerations（污點(diǎn)和容忍）：

Taint：使Node拒絕特定Pod運(yùn)行；

Toleration：為Pod的屬性，表示Pod能容忍（運(yùn)行）標(biāo)注了Taint的Node。

簡(jiǎn)述Kubernetes初始化容器（init container）？

init container的運(yùn)行方式與應(yīng)用容器不同，它們必須先于應(yīng)用容器執(zhí)行完成，當(dāng)設(shè)置了多個(gè)init container時(shí)，將按順序逐個(gè)運(yùn)行，并且只有前一個(gè)init container運(yùn)行成功后才能運(yùn)行后一個(gè)init container。當(dāng)所有init container都成功運(yùn)行后，Kubernetes才會(huì)初始化Pod的各種信息，并開始創(chuàng)建和運(yùn)行應(yīng)用容器。

簡(jiǎn)述Kubernetes deployment升級(jí)過(guò)程？

初始創(chuàng)建Deployment時(shí)，系統(tǒng)創(chuàng)建了一個(gè)ReplicaSet，并按用戶的需求創(chuàng)建了對(duì)應(yīng)數(shù)量的Pod副本。

當(dāng)更新Deployment時(shí)，系統(tǒng)創(chuàng)建了一個(gè)新的ReplicaSet，并將其副本數(shù)量擴(kuò)展到1，然后將舊ReplicaSet縮減為2。

之后，系統(tǒng)繼續(xù)按照相同的更新策略對(duì)新舊兩個(gè)ReplicaSet進(jìn)行逐個(gè)調(diào)整。

最后，新的ReplicaSet運(yùn)行了對(duì)應(yīng)個(gè)新版本Pod副本，舊的ReplicaSet副本數(shù)量則縮減為0。

簡(jiǎn)述Kubernetes deployment升級(jí)策略？

在Deployment的定義中，可以通過(guò)spec.strategy指定Pod更新的策略，目前支持兩種策略：Recreate（重建）和RollingUpdate（滾動(dòng)更新），默認(rèn)值為RollingUpdate。

Recreate：設(shè)置spec.strategy.type=Recreate，表示Deployment在更新Pod時(shí)，會(huì)先殺掉所有正在運(yùn)行的Pod，然后創(chuàng)建新的Pod。

RollingUpdate：設(shè)置spec.strategy.type=RollingUpdate，表示Deployment會(huì)以滾動(dòng)更新的方式來(lái)逐個(gè)更新Pod。同時(shí)，可以通過(guò)設(shè)置spec.strategy.rollingUpdate下的兩個(gè)參數(shù)（maxUnavailable和maxSurge）來(lái)控制滾動(dòng)更新的過(guò)程。

簡(jiǎn)述Kubernetes DaemonSet類型的資源特性？

DaemonSet資源對(duì)象會(huì)在每個(gè)Kubernetes集群中的節(jié)點(diǎn)上運(yùn)行，并且每個(gè)節(jié)點(diǎn)只能運(yùn)行一個(gè)pod，這是它和deployment資源對(duì)象的最大也是唯一的區(qū)別。因此，在定義yaml文件中，不支持定義replicas。

它的一般使用場(chǎng)景如下：

在去做每個(gè)節(jié)點(diǎn)的日志收集工作。

監(jiān)控每個(gè)節(jié)點(diǎn)的的運(yùn)行狀態(tài)。

簡(jiǎn)述Kubernetes自動(dòng)擴(kuò)容機(jī)制？

Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器實(shí)現(xiàn)基于CPU使用率進(jìn)行自動(dòng)Pod擴(kuò)縮容的功能。HPA控制器周期性地監(jiān)測(cè)目標(biāo)Pod的資源性能指標(biāo)，并與HPA資源對(duì)象中的擴(kuò)縮容條件進(jìn)行對(duì)比，在滿足條件時(shí)對(duì)Pod副本數(shù)量進(jìn)行調(diào)整。

HPA原理

Kubernetes中的某個(gè)Metrics Server（Heapster或自定義Metrics Server）持續(xù)采集所有Pod副本的指標(biāo)數(shù)據(jù)。HPA控制器通過(guò)Metrics Server的API（Heapster的API或聚合API）獲取這些數(shù)據(jù)，基于用戶定義的擴(kuò)縮容規(guī)則進(jìn)行計(jì)算，得到目標(biāo)Pod副本數(shù)量。

當(dāng)目標(biāo)Pod副本數(shù)量與當(dāng)前副本數(shù)量不同時(shí)，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）發(fā)起scale操作，調(diào)整Pod的副本數(shù)量，完成擴(kuò)縮容操作。

簡(jiǎn)述Kubernetes Service類型？

通過(guò)創(chuàng)建Service，可以為一組具有相同功能的容器應(yīng)用提供一個(gè)統(tǒng)一的入口地址，并且將請(qǐng)求負(fù)載分發(fā)到后端的各個(gè)容器應(yīng)用上。 其主要類型有：

ClusterIP：虛擬的服務(wù)IP地址，該地址用于Kubernetes集群內(nèi)部的Pod訪問(wèn)，在Node上kube-proxy通過(guò)設(shè)置的iptables規(guī)則進(jìn)行轉(zhuǎn)發(fā)；

NodePort：使用宿主機(jī)的端口，使能夠訪問(wèn)各Node的外部客戶端通過(guò)Node的IP地址和端口號(hào)就能訪問(wèn)服務(wù)；

LoadBalancer：使用外接負(fù)載均衡器完成到服務(wù)的負(fù)載分發(fā)，需要在spec.status.loadBalancer字段指定外部負(fù)載均衡器的IP地址，通常用于公有云。

簡(jiǎn)述Kubernetes Service分發(fā)后端的策略？

Service負(fù)載分發(fā)的策略有：RoundRobin和SessionAffinity

RoundRobin：默認(rèn)為輪詢模式，即輪詢將請(qǐng)求轉(zhuǎn)發(fā)到后端的各個(gè)Pod上。

SessionAffinity：基于客戶端IP地址進(jìn)行會(huì)話保持的模式，即第1次將某個(gè)客戶端發(fā)起的請(qǐng)求轉(zhuǎn)發(fā)到后端的某個(gè)Pod上，之后從相同的客戶端發(fā)起的請(qǐng)求都將被轉(zhuǎn)發(fā)到后端相同的Pod上。

簡(jiǎn)述Kubernetes Headless Service？

在某些應(yīng)用場(chǎng)景中，若需要人為指定負(fù)載均衡器，不使用Service提供的默認(rèn)負(fù)載均衡的功能，或者應(yīng)用程序希望知道屬于同組服務(wù)的其他實(shí)例。Kubernetes提供了Headless Service來(lái)實(shí)現(xiàn)這種功能，即不為Service設(shè)置ClusterIP（入口IP地址），僅通過(guò)Label Selector將后端的Pod列表返回給調(diào)用的客戶端。

簡(jiǎn)述Kubernetes外部如何訪問(wèn)集群內(nèi)的服務(wù)？

對(duì)于Kubernetes，集群外的客戶端默認(rèn)情況，無(wú)法通過(guò)Pod的IP地址或者Service的虛擬IP地址:虛擬端口號(hào)進(jìn)行訪問(wèn)。通常可以通過(guò)以下方式進(jìn)行訪問(wèn)Kubernetes集群內(nèi)的服務(wù)：

映射Pod到物理機(jī)：將Pod端口號(hào)映射到宿主機(jī)，即在Pod中采用hostPort方式，以使客戶端應(yīng)用能夠通過(guò)物理機(jī)訪問(wèn)容器應(yīng)用。

映射Service到物理機(jī)：將Service端口號(hào)映射到宿主機(jī)，即在Service中采用nodePort方式，以使客戶端應(yīng)用能夠通過(guò)物理機(jī)訪問(wèn)容器應(yīng)用。

映射Sercie到LoadBalancer：通過(guò)設(shè)置LoadBalancer映射到云服務(wù)商提供的LoadBalancer地址。這種用法僅用于在公有云服務(wù)提供商的云平臺(tái)上設(shè)置Service的場(chǎng)景。

簡(jiǎn)述Kubernetes ingress？

Kubernetes的Ingress資源對(duì)象，用于將不同URL的訪問(wèn)請(qǐng)求轉(zhuǎn)發(fā)到后端不同的Service，以實(shí)現(xiàn)HTTP層的業(yè)務(wù)路由機(jī)制。

Kubernetes使用了Ingress策略和Ingress Controller，兩者結(jié)合并實(shí)現(xiàn)了一個(gè)完整的Ingress負(fù)載均衡器。使用Ingress進(jìn)行負(fù)載分發(fā)時(shí)，Ingress Controller基于Ingress規(guī)則將客戶端請(qǐng)求直接轉(zhuǎn)發(fā)到Service對(duì)應(yīng)的后端Endpoint（Pod）上，從而跳過(guò)kube-proxy的轉(zhuǎn)發(fā)功能，kube-proxy不再起作用，全過(guò)程為：ingress controller + ingress 規(guī)則 ----> services。

同時(shí)當(dāng)Ingress Controller提供的是對(duì)外服務(wù)，則實(shí)際上實(shí)現(xiàn)的是邊緣路由器的功能。

簡(jiǎn)述Kubernetes鏡像的下載策略？

K8s的鏡像下載策略有三種：Always、Never、IFNotPresent。

Always：鏡像標(biāo)簽為latest時(shí)，總是從指定的倉(cāng)庫(kù)中獲取鏡像。

Never：禁止從倉(cāng)庫(kù)中下載鏡像，也就是說(shuō)只能使用本地鏡像。

IfNotPresent：僅當(dāng)本地沒(méi)有對(duì)應(yīng)鏡像時(shí)，才從目標(biāo)倉(cāng)庫(kù)中下載。
默認(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è)功能模塊通過(guò)API Server將信息存入etcd，當(dāng)需要獲取和操作這些數(shù)據(jù)時(shí)，則通過(guò)API Server提供的REST接口（用GET、LIST或WATCH方法）來(lái)實(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模塊通過(guò)API Server提供的Watch接口實(shí)時(shí)監(jiān)控Node的信息，并做相應(yīng)處理。

如kube-scheduler進(jìn)程與API Server的交互：Scheduler通過(guò)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接下來(lái)生命周期。

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)度過(guò)程中涉及三個(gè)對(duì)象，分別是待調(diào)度Pod列表、可用Node列表，以及調(diào)度算法和策略。

Kubernetes Scheduler通過(guò)調(diào)度算法調(diào)度為待調(diào)度Pod列表中的每個(gè)Pod從Node列表中選擇一個(gè)最適合的Node來(lái)實(shí)現(xiàn)Pod的調(diào)度。隨后，目標(biāo)節(jié)點(diǎn)上的kubelet通過(guò)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ù)選策略過(guò)濾掉不滿足策略的Nodes。如果某節(jié)點(diǎn)的資源不足或者不滿足預(yù)選策略的條件則無(wú)法通過(guò)預(yù)選。如“Node的label必須與Pod的Selector一致”。

優(yōu)選（Priorities）：輸入是預(yù)選階段篩選出的節(jié)點(diǎn)，優(yōu)選會(huì)根據(jù)優(yōu)先策略為通過(guò)預(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)資源的使用情況，并通過(guò)cAdvisor監(jiān)控容器和節(jié)點(diǎn)資源。

簡(jiǎn)述Kubernetes kubelet監(jiān)控Worker節(jié)點(diǎn)資源是使用什么組件來(lái)實(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通過(guò)一系列機(jī)制來(lái)實(shí)現(xiàn)集群的安全控制，主要有如下不同的維度：

基礎(chǔ)設(shè)施方面：保證容器與其所在宿主機(jī)的隔離；

權(quán)限方面：

最小權(quán)限原則：合理限制所有組件的權(quán)限，確保組件只執(zhí)行它被授權(quán)的行為，通過(guò)限制單個(gè)組件的能力來(lái)限制它的權(quán)限范圍。

用戶權(quán)限：劃分普通用戶和管理員的角色。

集群方面：

API Server的認(rèn)證授權(quán)：Kubernetes集群中所有資源的訪問(wèn)和變更都是通過(guò)Kubernetes API Server來(lái)實(shí)現(xiàn)的，因此需要建議采用更安全的HTTPS或Token來(lái)識(shí)別和認(rèn)證客戶端身份（Authentication），以及隨后訪問(wèn)權(quán)限的授權(quán)（Authorization）環(huán)節(jié)。

API Server的授權(quán)管理：通過(guò)授權(quán)策略來(lái)決定一個(gè)API調(diào)用是否合法。對(duì)合法用戶進(jìn)行授權(quán)并且隨后在用戶訪問(wèn)時(shí)進(jìn)行鑒權(quán)，建議采用更安全的RBAC方式來(lái)提升集群安全授權(quán)。

敏感數(shù)據(jù)引入Secret機(jī)制：對(duì)于集群敏感數(shù)據(jù)建議使用Secret方式進(jìn)行保護(hù)。

AdmissionControl（準(zhǔn)入機(jī)制）：對(duì)kubernetes api的請(qǐng)求過(guò)程中，順序?yàn)椋合冉?jīng)過(guò)認(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)求過(guò)程中，順序?yàn)椋合冉?jīng)過(guò)認(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沒(méi)有serviceAccount屬性，它會(huì)自動(dòng)添加一個(gè)default，并確保pod的serviceAccount始終存在。

LimitRanger：觀察所有的請(qǐng)求，確保沒(méi)有違反已經(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是基于角色的訪問(wèn)控制，是一種基于個(gè)人用戶的角色來(lái)管理對(duì)計(jì)算機(jī)或網(wǎng)絡(luò)資源的訪問(wèn)的方法。

相對(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)整，無(wú)須重新啟動(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之后，可通過(guò)如下三種方式使用：

在創(chuàng)建Pod時(shí)，通過(guò)為Pod指定Service Account來(lái)自動(dòng)使用該Secret。

通過(guò)掛載該Secret到Pod來(lái)使用它。

在Docker鏡像下載時(shí)使用，通過(guò)指定Pod的spc.ImagePullSecrets來(lái)引用它。

簡(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è)置不同字段來(lái)控制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ī)）中，都要求它們可以直接通過(guò)對(duì)方的IP進(jìn)行訪問(wèn)。設(shè)計(jì)這個(gè)原則的原因是，用戶不需要額外考慮如何建立Pod之間的連接，也不需要考慮如何將容器端口映射到主機(jī)端口等問(wèn)題。

同時(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)的容器可以通過(guò)localhost來(lái)連接對(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ī)范，通過(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è)置和操作都通過(guò)插件（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ò)訪問(wèn)隔離策略，Kubernetes引入Network Policy。

Network Policy的主要功能是對(duì)Pod間的網(wǎng)絡(luò)通信進(jìn)行限制和準(zhǔn)入控制，設(shè)置允許訪問(wèn)或禁止訪問(wèn)的客戶端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ò)訪問(wèn)規(guī)則通過(guò)各Node的Agent進(jìn)行實(shí)際設(shè)置（Agent則需要通過(guò)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），通過(guò)這個(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來(lái)負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)。每個(gè)vRouter都通過(guò)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ù)流量都是通過(guò)IP路由的方式完成互聯(lián)互通的。Calico節(jié)點(diǎn)組網(wǎng)時(shí)可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)（L2或者L3），不需要額外的NAT、隧道或者Overlay Network，沒(méi)有額外的封包解包，能夠節(jié)約CPU運(yùn)算，提高網(wǎng)絡(luò)效率。

簡(jiǎn)述Kubernetes共享存儲(chǔ)的作用？

Kubernetes對(duì)于有狀態(tài)的容器應(yīng)用或者對(duì)數(shù)據(jù)需要持久化的應(yīng)用，因此需要更加可靠的存儲(chǔ)來(lái)保存應(yīng)用產(chǎn)生的重要數(shù)據(jù)，以便容器應(yīng)用在重建之后仍然可以使用之前的數(shù)據(jù)。因此需要使用共享存儲(chǔ)。

簡(jiǎn)述Kubernetes數(shù)據(jù)持久化的方式有哪些？

Kubernetes通過(guò)數(shù)據(jù)持久化來(lái)持久化保存重要數(shù)據(jù)，常見的方式有：

EmptyDir（空目錄）：沒(méi)有指定要掛載宿主機(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)刪除，資源已釋放，但沒(méi)有被集群回收。

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)模式：集群管理員無(wú)須手工創(chuàng)建PV，而是通過(guò)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)加入集群的過(guò)程？

通常需要對(duì)Worker節(jié)點(diǎn)進(jìn)行擴(kuò)容，從而將應(yīng)用系統(tǒng)進(jìn)行水平擴(kuò)展。主要過(guò)程如下：

1、在該Node上安裝Docker、kubelet和kube-proxy服務(wù)；

2、然后配置kubelet和kubeproxy的啟動(dòng)參數(shù)，將Master URL指定為當(dāng)前Kubernetes集群Master的地址，最后啟動(dòng)這些服務(wù)；

3、通過(guò)kubelet默認(rèn)的自動(dòng)注冊(cè)機(jī)制，新的Worker將會(huì)自動(dòng)加入現(xiàn)有的Kubernetes集群中；

4、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í)可以通過(guò)參數(shù)CPU Request及Memory Request為其中的每個(gè)容器指定所需使用的CPU與Memory量，Kubernetes會(huì)根據(jù)Request的值去查找有足夠資源的Node來(lái)調(diào)度此Pod。

通常，一個(gè)程序所使用的CPU與Memory是一個(gè)動(dòng)態(tài)的量，確切地說(shuō)，是一個(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)來(lái)執(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總和，不超過(guò)該節(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等組件來(lái)完成。

簡(jiǎn)述Kubernetes中，如何使用EFK實(shí)現(xiàn)日志的統(tǒng)一管理？

在Kubernetes集群環(huán)境中，通常一個(gè)完整的應(yīng)用或服務(wù)涉及組件過(guò)多，建議對(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)日志，并將處理過(guò)后的日志信息發(fā)送給Elasticsearch；

Kibana：提供了一個(gè) Web GUI，用戶可以瀏覽和搜索存儲(chǔ)在 Elasticsearch 中的日志。

通過(guò)在每臺(tái)node上部署一個(gè)以DaemonSet方式運(yùn)行的fluentd來(lái)收集每臺(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è)地方控制/管理所有集群。

簡(jiǎn)述Helm及其優(yōu)勢(shì)？

Helm?是 Kubernetes 的軟件包管理工具。類似 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一樣。

Helm能夠?qū)⒁唤MK8S資源打包統(tǒng)一管理, 是查找、共享和使用為Kubernetes構(gòu)建的軟件的最佳方式。

Helm中通常每個(gè)包稱為一個(gè)Chart，一個(gè)Chart是一個(gè)目錄（一般情況下會(huì)將目錄進(jìn)行打包壓縮，形成name-version.tgz格式的單一文件，方便傳輸和存儲(chǔ)）。

Helm優(yōu)勢(shì)

在 Kubernetes中部署一個(gè)可以使用的應(yīng)用，需要涉及到很多的 Kubernetes 資源的共同協(xié)作。使用helm則具有如下優(yōu)勢(shì)：

統(tǒng)一管理、配置和更新這些分散的 k8s 的應(yīng)用資源文件；

分發(fā)和復(fù)用一套應(yīng)用模板；

將應(yīng)用的一系列資源當(dāng)做一個(gè)軟件包管理。

對(duì)于應(yīng)用發(fā)布者而言，可以通過(guò) Helm 打包應(yīng)用、管理應(yīng)用依賴關(guān)系、管理應(yīng)用版本并發(fā)布應(yīng)用到軟件倉(cāng)庫(kù)。

對(duì)于使用者而言，使用 Helm 后不用需要編寫復(fù)雜的應(yīng)用部署文件，可以以簡(jiǎn)單的方式在 Kubernetes 上查找、安裝、升級(jí)、回滾、卸載應(yīng)用程序。

簡(jiǎn)述OpenShift及其特性？

OpenShift是一個(gè)容器應(yīng)用程序平臺(tái)，用于在安全的、可伸縮的資源上部署新應(yīng)用程序，而配置和管理開銷最小。

OpenShift構(gòu)建于Red Hat Enterprise Linux、Docker和Kubernetes之上，為企業(yè)級(jí)應(yīng)用程序提供了一個(gè)安全且可伸縮的多租戶操作系統(tǒng)，同時(shí)還提供了集成的應(yīng)用程序運(yùn)行時(shí)和庫(kù)。

其主要特性：

自助服務(wù)平臺(tái)：OpenShift允許開發(fā)人員使用Source-to-Image(S2I)從模板或自己的源代碼管理存儲(chǔ)庫(kù)創(chuàng)建應(yīng)用程序。系統(tǒng)管理員可以為用戶和項(xiàng)目定義資源配額和限制，以控制系統(tǒng)資源的使用。

多語(yǔ)言支持：OpenShift支持Java、Node.js、PHP、Perl以及直接來(lái)自Red Hat的Ruby。OpenShift還支持中間件產(chǎn)品，如Apache httpd、Apache Tomcat、JBoss EAP、ActiveMQ和Fuse。

自動(dòng)化：OpenShift提供應(yīng)用程序生命周期管理功能，當(dāng)上游源或容器映像發(fā)生更改時(shí)，可以自動(dòng)重新構(gòu)建和重新部署容器。根據(jù)調(diào)度和策略擴(kuò)展或故障轉(zhuǎn)移應(yīng)用程序。

用戶界面：OpenShift提供用于部署和監(jiān)視應(yīng)用程序的web UI，以及用于遠(yuǎn)程管理應(yīng)用程序和資源的CLi。

協(xié)作：OpenShift允許在組織內(nèi)或與更大的社區(qū)共享項(xiàng)目。

可伸縮性和高可用性：OpenShift提供了容器多租戶和一個(gè)分布式應(yīng)用程序平臺(tái)，其中包括彈性，高可用性，以便應(yīng)用程序能夠在物理機(jī)器宕機(jī)等事件中存活下來(lái)。OpenShift提供了對(duì)容器健康狀況的自動(dòng)發(fā)現(xiàn)和自動(dòng)重新部署。

容器可移植性：在OpenShift中，應(yīng)用程序和服務(wù)使用標(biāo)準(zhǔn)容器映像進(jìn)行打包，組合應(yīng)用程序使用Kubernetes進(jìn)行管理。這些映像可以部署到基于這些基礎(chǔ)技術(shù)的其他平臺(tái)上。

開源：沒(méi)有廠商鎖定。

安全性：OpenShift使用SELinux提供多層安全性、基于角色的訪問(wèn)控制以及與外部身份驗(yàn)證系統(tǒng)(如LDAP和OAuth)集成的能力。

動(dòng)態(tài)存儲(chǔ)管理：OpenShift使用Kubernetes持久卷和持久卷聲明的方式為容器數(shù)據(jù)提供靜態(tài)和動(dòng)態(tài)存儲(chǔ)管理

基于云(或不基于云)：可以在裸機(jī)服務(wù)器、活來(lái)自多個(gè)供應(yīng)商的hypervisor和大多數(shù)IaaS云提供商上部署OpenShift容器平臺(tái)。

企業(yè)級(jí)：Red Hat支持OpenShift、選定的容器映像和應(yīng)用程序運(yùn)行時(shí)。可信的第三方容器映像、運(yùn)行時(shí)和應(yīng)用程序由Red Hat認(rèn)證。可以在OpenShift提供的高可用性的強(qiáng)化安全環(huán)境中運(yùn)行內(nèi)部或第三方應(yīng)用程序。

日志聚合和metrics：可以在中心節(jié)點(diǎn)收集、聚合和分析部署在OpenShift上的應(yīng)用程序的日志信息。OpenShift能夠?qū)崟r(shí)收集關(guān)于應(yīng)用程序的度量和運(yùn)行時(shí)信息，并幫助不斷優(yōu)化性能。

其他特性：OpenShift支持微服務(wù)體系結(jié)構(gòu)，OpenShift的本地特性足以支持DevOps流程，很容易與標(biāo)準(zhǔn)和定制的持續(xù)集成/持續(xù)部署工具集成。

簡(jiǎn)述OpenShift projects及其作用？

OpenShift管理projects和users。一個(gè)projects對(duì)Kubernetes資源進(jìn)行分組，以便用戶可以使用訪問(wèn)權(quán)限。還可以為projects分配配額，從而限制了已定義的pod、volumes、services和其他資源。

project允許一組用戶獨(dú)立于其他組組織和管理其內(nèi)容，必須允許用戶訪問(wèn)項(xiàng)目。如果允許創(chuàng)建項(xiàng)目，用戶將自動(dòng)訪問(wèn)自己的項(xiàng)目。

簡(jiǎn)述OpenShift高可用的實(shí)現(xiàn)？

OpenShift平臺(tái)集群的高可用性(HA)有兩個(gè)不同的方面：

OpenShift基礎(chǔ)設(shè)施本身的HA(即主機(jī))；

以及在OpenShift集群中運(yùn)行的應(yīng)用程序的HA。

默認(rèn)情況下，OpenShift為master節(jié)點(diǎn)提供了完全支持的本機(jī)HA機(jī)制。
對(duì)于應(yīng)用程序或“pods”，如果pod因任何原因丟失，Kubernetes將調(diào)度另一個(gè)副本，將其連接到服務(wù)層和持久存儲(chǔ)。如果整個(gè)節(jié)點(diǎn)丟失，Kubernetes會(huì)為它所有的pod安排替換節(jié)點(diǎn)，最終所有的應(yīng)用程序都會(huì)重新可用。pod中的應(yīng)用程序負(fù)責(zé)它們自己的狀態(tài)，因此它們需要自己維護(hù)應(yīng)用程序狀態(tài)(如HTTP會(huì)話復(fù)制或數(shù)據(jù)庫(kù)復(fù)制)。

簡(jiǎn)述OpenShift的SDN網(wǎng)絡(luò)實(shí)現(xiàn)？

默認(rèn)情況下，Docker網(wǎng)絡(luò)使用僅使用主機(jī)虛機(jī)網(wǎng)橋bridge，主機(jī)內(nèi)的所有容器都連接至該網(wǎng)橋。連接到此橋的所有容器都可以彼此通信，但不能與不同主機(jī)上的容器通信。

為了支持跨集群的容器之間的通信，OpenShift容器平臺(tái)使用了軟件定義的網(wǎng)絡(luò)(SDN)方法。軟件定義的網(wǎng)絡(luò)是一種網(wǎng)絡(luò)模型，它通過(guò)幾個(gè)網(wǎng)絡(luò)層的抽象來(lái)管理網(wǎng)絡(luò)服務(wù)。SDN將處理流量的軟件(稱為控制平面)和路由流量的底層機(jī)制(稱為數(shù)據(jù)平面)解耦。SDN支持控制平面和數(shù)據(jù)平面之間的通信。

在OpenShift中，可以為pod網(wǎng)絡(luò)配置三個(gè)SDN插件:

1、ovs-subnet：默認(rèn)插件，子網(wǎng)提供了一個(gè)flat pod網(wǎng)絡(luò)，其中每個(gè)pod可以與其他pod和service通信。

2、ovs-multitenant：該為pod和服務(wù)提供了額外的隔離層。當(dāng)使用此插件時(shí)，每個(gè)project接收一個(gè)惟一的虛擬網(wǎng)絡(luò)ID (VNID)，該ID標(biāo)識(shí)來(lái)自屬于該project的pod的流量。通過(guò)使用VNID，來(lái)自不同project的pod不能與其他project的pod和service通信。

3、ovs-network policy：此插件允許管理員使用NetworkPolicy對(duì)象定義自己的隔離策略。

cluster network由OpenShift SDN建立和維護(hù)，它使用Open vSwitch創(chuàng)建overlay網(wǎng)絡(luò)，master節(jié)點(diǎn)不能通過(guò)集群網(wǎng)絡(luò)訪問(wèn)容器，除非master同時(shí)也為node節(jié)點(diǎn)。

簡(jiǎn)述OpenShift角色及其作用？

OpenShift的角色具有不同級(jí)別的訪問(wèn)和策略，包括集群和本地策略。user和group可以同時(shí)與多個(gè)role關(guān)聯(lián)。

簡(jiǎn)述OpenShift支持哪些身份驗(yàn)證？

OpenShift容器平臺(tái)支持的其他認(rèn)證類型包括:

Basic Authentication (Remote)：一種通用的后端集成機(jī)制，允許用戶使用針對(duì)遠(yuǎn)程標(biāo)識(shí)提供者驗(yàn)證的憑據(jù)登錄到OpenShift容器平臺(tái)。用戶將他們的用戶名和密碼發(fā)送到OpenShift容器平臺(tái)，OpenShift平臺(tái)通過(guò)到服務(wù)器的請(qǐng)求驗(yàn)證這些憑據(jù)，并將憑據(jù)作為基本的Auth頭傳遞。這要求用戶在登錄過(guò)程中向OpenShift容器平臺(tái)輸入他們的憑據(jù)。

Request Header Authentication：用戶使用請(qǐng)求頭值(如X-RemoteUser)登錄到OpenShift容器平臺(tái)。它通常與身份驗(yàn)證代理結(jié)合使用，身份驗(yàn)證代理對(duì)用戶進(jìn)行身份驗(yàn)證，然后通過(guò)請(qǐng)求頭值為OpenShift容器平臺(tái)提供用戶標(biāo)識(shí)。

Keystone Authentication：Keystone是一個(gè)OpenStack項(xiàng)目，提供標(biāo)識(shí)、令牌、目錄和策略服務(wù)。OpenShift容器平臺(tái)與Keystone集成，通過(guò)配置OpenStack Keystone v3服務(wù)器將用戶存儲(chǔ)在內(nèi)部數(shù)據(jù)庫(kù)中，從而支持共享身份驗(yàn)證。這種配置允許用戶使用Keystone憑證登錄OpenShift容器平臺(tái)。

LDAP Authentication：用戶使用他們的LDAP憑證登錄到OpenShift容器平臺(tái)。在身份驗(yàn)證期間，LDAP目錄將搜索與提供的用戶名匹配的條目。如果找到匹配項(xiàng)，則嘗試使用條目的專有名稱(DN)和提供的密碼進(jìn)行簡(jiǎn)單綁定。

GitHub Authentication：GitHub使用OAuth，它允許與OpenShift容器平臺(tái)集成使用OAuth身份驗(yàn)證來(lái)促進(jìn)令牌交換流。這允許用戶使用他們的GitHub憑證登錄到OpenShift容器平臺(tái)。為了防止使用GitHub用戶id的未授權(quán)用戶登錄到OpenShift容器平臺(tái)集群，可以將訪問(wèn)權(quán)限限制在特定的GitHub組織中。

簡(jiǎn)述什么是中間件？

中間件是一種獨(dú)立的系統(tǒng)軟件或服務(wù)程序，分布式應(yīng)用軟件借助這種軟件在不同的技術(shù)之間共享資源。通常位于客戶機(jī)/服務(wù)器的操作系統(tǒng)中間，是連接兩個(gè)獨(dú)立應(yīng)用程序或獨(dú)立系統(tǒng)的軟件。

通過(guò)中間件實(shí)現(xiàn)兩個(gè)不同系統(tǒng)之間的信息交換。

編輯：黃飛

?