集群相關(guān)
簡述 ETCD 及其特點(diǎn)？
etcd 是 CoreOS 團(tuán)隊發(fā)起的開源項目，是一個管理配置信息和服務(wù)發(fā)現(xiàn)（service discovery）的項目，它的目標(biāo)是構(gòu)建一個高可用的分布式鍵值（key-value）數(shù)據(jù)庫，基于 Go 語言實(shí)現(xiàn)。

特點(diǎn)：

簡單：支持 REST 風(fēng)格的 HTTP+JSON API
安全：支持 HTTPS 方式的訪問
快速：支持并發(fā) 1k/s 的寫操作
可靠：支持分布式結(jié)構(gòu)，基于 Raft 的一致性算法，Raft 是一套通過選舉主節(jié)點(diǎn)來實(shí)現(xiàn)分布式系統(tǒng)一致性的算法。
簡述 ETCD 適應(yīng)的場景？
etcd 基于其優(yōu)秀的特點(diǎn)，可廣泛的應(yīng)用于以下場景：

服務(wù)發(fā)現(xiàn) (Service Discovery)：服務(wù)發(fā)現(xiàn)主要解決在同一個分布式集群中的進(jìn)程或服務(wù)，要如何才能找到對方并建立連接。本質(zhì)上來說，服務(wù)發(fā)現(xiàn)就是想要了解集群中是否有進(jìn)程在監(jiān)聽 udp 或 tcp 端口，并且通過名字就可以查找和連接。
消息發(fā)布與訂閱：在分布式系統(tǒng)中，最適用的一種組件間通信方式就是消息發(fā)布與訂閱。即構(gòu)建一個配置共享中心，數(shù)據(jù)提供者在這個配置中心發(fā)布消息，而消息使用者則訂閱他們關(guān)心的主題，一旦主題有消息發(fā)布，就會實(shí)時通知訂閱者。通過這種方式可以做到分布式系統(tǒng)配置的集中式管理與動態(tài)更新。應(yīng)用中用到的一些配置信息放到 etcd 上進(jìn)行集中管理。
負(fù)載均衡：在分布式系統(tǒng)中，為了保證服務(wù)的高可用以及數(shù)據(jù)的一致性，通常都會把數(shù)據(jù)和服務(wù)部署多份，以此達(dá)到對等服務(wù)，即使其中的某一個服務(wù)失效了，也不影響使用。etcd 本身分布式架構(gòu)存儲的信息訪問支持負(fù)載均衡。etcd 集群化以后，每個 etcd 的核心節(jié)點(diǎn)都可以處理用戶的請求。所以，把數(shù)據(jù)量小但是訪問頻繁的消息數(shù)據(jù)直接存儲到 etcd 中也可以實(shí)現(xiàn)負(fù)載均衡的效果。
分布式通知與協(xié)調(diào)：與消息發(fā)布和訂閱類似，都用到了 etcd 中的 Watcher 機(jī)制，通過注冊與異步通知機(jī)制，實(shí)現(xiàn)分布式環(huán)境下不同系統(tǒng)之間的通知與協(xié)調(diào)，從而對數(shù)據(jù)變更做到實(shí)時處理。
分布式鎖：因?yàn)?etcd 使用 Raft 算法保持了數(shù)據(jù)的強(qiáng)一致性，某次操作存儲到集群中的值必然是全局一致的，所以很容易實(shí)現(xiàn)分布式鎖。鎖服務(wù)有兩種使用方式，一是保持獨(dú)占，二是控制時序。
集群監(jiān)控與 Leader 競選：通過 etcd 來進(jìn)行監(jiān)控實(shí)現(xiàn)起來非常簡單并且實(shí)時性強(qiáng)。
簡述 HAProxy 及其特性？
HAProxy 是可提供高可用性、負(fù)載均衡以及基于 TCP 和 HTTP 應(yīng)用的代理，是免費(fèi)、快速并且可靠的一種解決方案。HAProxy 非常適用于并發(fā)大（并發(fā)達(dá) 1w 以上）web 站點(diǎn)，這些站點(diǎn)通常又需要會話保持或七層處理。HAProxy 的運(yùn)行模式使得它可以很簡單安全的整合至當(dāng)前的架構(gòu)中，同時可以保護(hù) web 服務(wù)器不被暴露到網(wǎng)絡(luò)上。

HAProxy 的主要特性有：

可靠性和穩(wěn)定性非常好，可以與硬件級的 F5 負(fù)載均衡設(shè)備相媲美；
最高可以同時維護(hù) 40000-50000 個并發(fā)連接，單位時間內(nèi)處理的最大請求數(shù)為 20000 個，最大處理能力可達(dá) 10Git/s；
支持多達(dá) 8 種負(fù)載均衡算法，同時也支持會話保持；
支持虛機(jī)主機(jī)功能，從而實(shí)現(xiàn) web 負(fù)載均衡更加靈活；
支持連接拒絕、全透明代理等獨(dú)特的功能；
擁有強(qiáng)大的 ACL 支持，用于訪問控制；
其獨(dú)特的彈性二叉樹數(shù)據(jù)結(jié)構(gòu)，使數(shù)據(jù)結(jié)構(gòu)的復(fù)雜性上升到了 0(1)，即數(shù)據(jù)的查尋速度不會隨著數(shù)據(jù)條目的增加而速度有所下降；
支持客戶端的 keepalive 功能，減少客戶端與 haproxy 的多次三次握手導(dǎo)致資源浪費(fèi)，讓多個請求在一個 tcp 連接中完成；
支持 TCP 加速，零復(fù)制功能，類似于 mmap 機(jī)制；
支持響應(yīng)池（response buffering）；
支持 RDP 協(xié)議；
基于源的粘性，類似 nginx 的 ip_hash 功能，把來自同一客戶端的請求在一定時間內(nèi)始終調(diào)度到上游的同一服務(wù)器；
更好統(tǒng)計數(shù)據(jù)接口，其 web 接口顯示后端集群中各個服務(wù)器的接收、發(fā)送、拒絕、錯誤等數(shù)據(jù)的統(tǒng)計信息；
詳細(xì)的健康狀態(tài)檢測，web 接口中有關(guān)于對上游服務(wù)器的健康檢測狀態(tài)，并提供了一定的管理功能；
基于流量的健康評估機(jī)制；
基于 http 認(rèn)證；
基于命令行的管理接口；
日志分析器，可對日志進(jìn)行分析。
簡述 HAProxy 常見的負(fù)載均衡策略？
HAProxy 負(fù)載均衡策略非常多，常見的有如下 8 種：

roundrobin：表示簡單的輪詢。
static-rr：表示根據(jù)權(quán)重。
leastconn：表示最少連接者先處理。
source：表示根據(jù)請求的源 IP，類似 Nginx 的 IP_hash 機(jī)制。
ri：表示根據(jù)請求的 URI。
rl_param：表示根據(jù) HTTP 請求頭來鎖定每一次 HTTP 請求。
rdp-cookie(name)：表示根據(jù)據(jù) cookie(name)來鎖定并哈希每一次 TCP 請求。
簡述負(fù)載均衡四層和七層的區(qū)別？
四層負(fù)載均衡器也稱為 4 層交換機(jī)，主要通過分析 IP 層及 TCP/UDP 層的流量實(shí)現(xiàn)基于 IP 加端口的負(fù)載均衡，如常見的 LVS、F5 等；

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

簡述 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ù)，無法實(shí)現(xiàn)基于目錄、URL 的轉(zhuǎn)發(fā)。而 HAProxy 和 Nginx 都可以實(shí)現(xiàn) 4 層和 7 層技術(shù)，HAProxy 可提供 TCP 和 HTTP 應(yīng)用的負(fù)載均衡綜合解決方案；
LVS 因?yàn)楣ぷ髟?ISO 模型的第四層，其狀態(tài)監(jiān)測功能單一，而 HAProxy 在狀監(jiān)測方面功能更豐富、強(qiáng)大，可支持端口、URL、腳本等多種狀態(tài)檢測方式；
HAProxy 功能強(qiáng)大，但整體性能低于 4 層模式的 LVS 負(fù)載均衡。
Nginx 主要用于 Web 服務(wù)器或緩存服務(wù)器。
簡述 Heartbeat？
Heartbeat 是 Linux-HA 項目中的一個組件，它提供了心跳檢測和資源接管、集群中服務(wù)的監(jiān)測、失效切換等功能。heartbeat 最核心的功能包括兩個部分，心跳監(jiān)測和資源接管。心跳監(jiān)測可以通過網(wǎng)絡(luò)鏈路和串口進(jìn)行，而且支持冗余鏈路，它們之間相互發(fā)送報文來告訴對方自己當(dāng)前的狀態(tài)，如果在指定的時間內(nèi)未收到對方發(fā)送的報文，那么就認(rèn)為對方失效，這時需啟動資源接管模塊來接管運(yùn)行在對方主機(jī)上的資源或者服務(wù)。

簡述 Keepalived 及其工作原理？
Keepalived 是一個基于 VRRP 協(xié)議來實(shí)現(xiàn)的 LVS 服務(wù)高可用方案，可以解決靜態(tài)路由出現(xiàn)的單點(diǎn)故障問題。

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

簡述 Keepalived 體系主要模塊及其作用？
keepalived 體系架構(gòu)中主要有三個模塊，分別是 core、check 和 vrrp。

core 模塊為 keepalived 的核心，負(fù)責(zé)主進(jìn)程的啟動、維護(hù)及全局配置文件的加載和解析。
vrrp 模塊是來實(shí)現(xiàn) VRRP 協(xié)議的。
check 負(fù)責(zé)健康檢查，常見的方式有端口檢查及 URL 檢查。
簡述 Keepalived 如何通過健康檢查來保證高可用？
Keepalived 工作在 TCP/IP 模型的第三、四和五層，即網(wǎng)絡(luò)層、傳輸層和應(yīng)用層。

網(wǎng)絡(luò)層，Keepalived 采用 ICMP 協(xié)議向服務(wù)器集群中的每個節(jié)點(diǎn)發(fā)送一個 ICMP 的數(shù)據(jù)包，如果某個節(jié)點(diǎn)沒有返回響應(yīng)數(shù)據(jù)包，則認(rèn)為此節(jié)點(diǎn)發(fā)生了故障，Keepalived 將報告次節(jié)點(diǎn)失效，并從服務(wù)器集群中剔除故障節(jié)點(diǎn)。
傳輸層，Keepalived 利用 TCP 的端口連接和掃描技術(shù)來判斷集群節(jié)點(diǎn)是否正常。如常見的 web 服務(wù)默認(rèn)端口 80，ssh 默認(rèn)端口 22 等。Keepalived 一旦在傳輸層探測到相應(yīng)端口沒用響應(yīng)數(shù)據(jù)返回，則認(rèn)為此端口發(fā)生異常，從而將此端口對應(yīng)的節(jié)點(diǎn)從服務(wù)器集群中剔除。
應(yīng)用層，可以運(yùn)行 FTP、telnet、smtp、dns 等各種不同類型的高層協(xié)議，Keepalived 的運(yùn)行方式也更加全面化和復(fù)雜化，用戶可以通過自定義 Keepalived 的工作方式，來設(shè)定監(jiān)測各種程序或服務(wù)是否正常，若監(jiān)測結(jié)果與設(shè)定的正常結(jié)果不一致，將此服務(wù)對應(yīng)的節(jié)點(diǎn)從服務(wù)器集群中剔除。
Keepalived 通過完整的健康檢查機(jī)制，保證集群中的所有節(jié)點(diǎn)均有效從而實(shí)現(xiàn)高可用。

簡述 LVS 的概念及其作用？
LVS 是 linux virtual server 的簡寫 linux 虛擬服務(wù)器，是一個虛擬的服務(wù)器集群系統(tǒng)，可以在 unix/linux 平臺下實(shí)現(xiàn)負(fù)載均衡集群功能。

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

把單臺計算機(jī)無法承受的大規(guī)模的并發(fā)訪問或數(shù)據(jù)流量分擔(dān)到多臺節(jié)點(diǎn)設(shè)備上分別處理，減少用戶等待響應(yīng)的時間，提升用戶體驗(yàn)。
單個重負(fù)載的運(yùn)算分擔(dān)到多臺節(jié)點(diǎn)設(shè)備上做并行處理，每個節(jié)點(diǎn)設(shè)備處理結(jié)束后，將結(jié)果匯總，返回給用戶，系統(tǒng)處理能力得到大幅度提高。
7*24 小時的服務(wù)保證，任意一個或多個設(shè)備節(jié)點(diǎn)設(shè)備宕機(jī)，不能影響到業(yè)務(wù)。在負(fù)載均衡集群中，所有計算機(jī)節(jié)點(diǎn)都應(yīng)該提供相同的服務(wù)，集群負(fù)載均衡獲取所有對該服務(wù)的如站請求。
簡述 LVS 的工作模式及其工作過程？
LVS 有三種負(fù)載均衡的模式，分別是 VS/NAT（nat 模式）、VS/DR（路由模式）、VS/TUN（隧道模式）。

NAT 模式（VS-NAT）
原理：首先負(fù)載均衡器接收到客戶的請求數(shù)據(jù)包時，根據(jù)調(diào)度算法決定將請求發(fā)送給哪個后端的真實(shí)服務(wù)器（RS）。然后負(fù)載均衡器就把客戶端發(fā)送的請求數(shù)據(jù)包的目標(biāo) IP 地址及端口改成后端真實(shí)服務(wù)器的 IP 地址（RIP）。真實(shí)服務(wù)器響應(yīng)完請求后，查看默認(rèn)路由，把響應(yīng)后的數(shù)據(jù)包發(fā)送給負(fù)載均衡器，負(fù)載均衡器在接收到響應(yīng)包后，把包的源地址改成虛擬地址（VIP）然后發(fā)送回給客戶端。
優(yōu)點(diǎn)：集群中的服務(wù)器可以使用任何支持 TCP/IP 的操作系統(tǒng)，只要負(fù)載均衡器有一個合法的 IP 地址。
缺點(diǎn)：擴(kuò)展性有限，當(dāng)服務(wù)器節(jié)點(diǎn)增長過多時，由于所有的請求和應(yīng)答都需要經(jīng)過負(fù)載均衡器，因此負(fù)載均衡器將成為整個系統(tǒng)的瓶頸。
IP 隧道模式（VS-TUN）
原理：首先負(fù)載均衡器接收到客戶的請求數(shù)據(jù)包時，根據(jù)調(diào)度算法決定將請求發(fā)送給哪個后端的真實(shí)服務(wù)器（RS）。然后負(fù)載均衡器就把客戶端發(fā)送的請求報文封裝一層 IP 隧道（T-IP）轉(zhuǎn)發(fā)到真實(shí)服務(wù)器（RS）。真實(shí)服務(wù)器響應(yīng)完請求后，查看默認(rèn)路由，把響應(yīng)后的數(shù)據(jù)包直接發(fā)送給客戶端，不需要經(jīng)過負(fù)載均衡器。
優(yōu)點(diǎn)：負(fù)載均衡器只負(fù)責(zé)將請求包分發(fā)給后端節(jié)點(diǎn)服務(wù)器，而 RS 將應(yīng)答包直接發(fā)給用戶。所以，減少了負(fù)載均衡器的大量數(shù)據(jù)流動，負(fù)載均衡器不再是系統(tǒng)的瓶頸，也能處理很巨大的請求量。
缺點(diǎn)：隧道模式的 RS 節(jié)點(diǎn)需要合法 IP，這種方式需要所有的服務(wù)器支持“IP Tunneling”。
直接路由模式（VS-DR）
原理：首先負(fù)載均衡器接收到客戶的請求數(shù)據(jù)包時，根據(jù)調(diào)度算法決定將請求發(fā)送給哪個后端的真實(shí)服務(wù)器（RS）。然后負(fù)載均衡器就把客戶端發(fā)送的請求數(shù)據(jù)包的目標(biāo) MAC 地址改成后端真實(shí)服務(wù)器的 MAC 地址（R-MAC）。真實(shí)服務(wù)器響應(yīng)完請求后，查看默認(rèn)路由，把響應(yīng)后的數(shù)據(jù)包直接發(fā)送給客戶端，不需要經(jīng)過負(fù)載均衡器。
優(yōu)點(diǎn)：負(fù)載均衡器只負(fù)責(zé)將請求包分發(fā)給后端節(jié)點(diǎn)服務(wù)器，而 RS 將應(yīng)答包直接發(fā)給用戶。所以，減少了負(fù)載均衡器的大量數(shù)據(jù)流動，負(fù)載均衡器不再是系統(tǒng)的瓶頸，也能處理很巨大的請求量。
缺點(diǎn)：需要負(fù)載均衡器與真實(shí)服務(wù)器 RS 都有一塊網(wǎng)卡連接到同一物理網(wǎng)段上，必須在同一個局域網(wǎng)環(huán)境。
簡述 LVS 調(diào)度器常見算法（均衡策略）？
LVS 調(diào)度器用的調(diào)度方法基本分為兩類：

固定調(diào)度算法：rr，wrr，dh，sh
rr：輪詢算法，將請求依次分配給不同的 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)鍵字查找一個靜態(tài) hash 表來獲得所需 RS。
sh：源地址哈希調(diào)度（source hashing）以源地址為關(guān)鍵字查找一個靜態(tài) hash 表來獲得需要的 RS。
動態(tài)調(diào)度算法：wlc，lc，lblc，lblcr
wlc：加權(quán)最小連接數(shù)調(diào)度，假設(shè)各臺 RS 的權(quán)值依次為 Wi，當(dāng)前 tcp 連接數(shù)依次為 Ti，依次去 Ti/Wi 為最小的 RS 作為下一個分配的 RS。
lc：最小連接數(shù)調(diào)度（least-connection），IPVS 表存儲了所有活動的連接。LB 會比較將連接請求發(fā)送到當(dāng)前連接最少的 RS。
lblc：基于地址的最小連接數(shù)調(diào)度（locality-based least-connection）：將來自同一個目的地址的請求分配給同一臺 RS，此時這臺服務(wù)器是尚未滿負(fù)荷的。否則就將這個請求分配給連接數(shù)最小的 RS，并以它作為下一次分配的首先考慮。
簡述 LVS、Nginx、HAProxy 各自優(yōu)缺點(diǎn)？
Nginx 的優(yōu)點(diǎn)：
工作在網(wǎng)絡(luò)的 7 層之上，可以針對 http 應(yīng)用做一些分流的策略，比如針對域名、目錄結(jié)構(gòu)。Nginx 正則規(guī)則比 HAProxy 更為強(qiáng)大和靈活。
Nginx 對網(wǎng)絡(luò)穩(wěn)定性的依賴非常小，理論上能 ping 通就就能進(jìn)行負(fù)載功能，LVS 對網(wǎng)絡(luò)穩(wěn)定性依賴比較大，穩(wěn)定要求相對更高。
Nginx 安裝和配置、測試比較簡單、方便，有清晰的日志用于排查和管理，LVS 的配置、測試就要花比較長的時間了。
可以承擔(dān)高負(fù)載壓力且穩(wěn)定，一般能支撐幾萬次的并發(fā)量，負(fù)載度比 LVS 相對小些。
Nginx 可以通過端口檢測到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁返回的狀態(tài)碼、超時等等。
Nginx 不僅僅是一款優(yōu)秀的負(fù)載均衡器/反向代理軟件，它同時也是功能強(qiáng)大的 Web 應(yīng)用服務(wù)器。
Nginx 作為 Web 反向加速緩存越來越成熟了，速度比傳統(tǒng)的 Squid 服務(wù)器更快，很多場景下都將其作為反向代理加速器。
Nginx 作為靜態(tài)網(wǎng)頁和圖片服務(wù)器，這方面的性能非常優(yōu)秀，同時第三方模塊也很多。
Nginx 的缺點(diǎn)：
Nginx 僅能支持 http、https 和 Email 協(xié)議，這樣就在適用范圍上面小些。
對后端服務(wù)器的健康檢查，只支持通過端口來檢測，不支持通過 url 來檢測。
不支持 Session 的直接保持，需要通過 ip_hash 來解決。
LVS 的優(yōu)點(diǎn)：
抗負(fù)載能力強(qiáng)、是工作在網(wǎng)絡(luò) 4 層之上僅作分發(fā)之用，沒有流量的產(chǎn)生。因此負(fù)載均衡軟件里的性能最強(qiáng)的，對內(nèi)存和 cpu 資源消耗比較低。
LVS 工作穩(wěn)定，因?yàn)槠浔旧砜关?fù)載能力很強(qiáng)，自身有完整的雙機(jī)熱備方案。
無流量，LVS 只分發(fā)請求，而流量并不從它本身出去，這點(diǎn)保證了均衡器 IO 的性能不會收到大流量的影響。
應(yīng)用范圍較廣，因?yàn)?LVS 工作在 4 層，所以它幾乎可對所有應(yīng)用做負(fù)載均衡，包括 http、數(shù)據(jù)庫等。
LVS 的缺點(diǎn)是：
軟件本身不支持正則表達(dá)式處理，不能做動靜分離。相對來說，Nginx/HAProxy+Keepalived 則具有明顯的優(yōu)勢。
如果是網(wǎng)站應(yīng)用比較龐大的話，LVS/DR+Keepalived 實(shí)施起來就比較復(fù)雜了。相對來說，Nginx/HAProxy+Keepalived 就簡單多了。
HAProxy 的優(yōu)點(diǎn)：
HAProxy 也是支持虛擬主機(jī)的。
HAProxy 的優(yōu)點(diǎn)能夠補(bǔ)充 Nginx 的一些缺點(diǎn)，比如支持 Session 的保持，Cookie 的引導(dǎo)，同時支持通過獲取指定的 url 來檢測后端服務(wù)器的狀態(tài)。
HAProxy 跟 LVS 類似，本身就只是一款負(fù)載均衡軟件，單純從效率上來講 HAProxy 會比 Nginx 有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于 Nginx 的。
HAProxy 支持 TCP 協(xié)議的負(fù)載均衡轉(zhuǎn)發(fā)。
簡述代理服務(wù)器的概念及其作用？
代理服務(wù)器是一個位于客戶端和原始（資源）服務(wù)器之間的服務(wù)器，為了從原始服務(wù)器取得內(nèi)容，客戶端向代理服務(wù)器發(fā)送一個請求并指定目標(biāo)原始服務(wù)器，然后代理服務(wù)器向原始服務(wù)器轉(zhuǎn)交請求并將獲得的內(nèi)容返回給客戶端。

其主要作用有：

資源獲取：代替客戶端實(shí)現(xiàn)從原始服務(wù)器的資源獲取；
加速訪問：代理服務(wù)器可能離原始服務(wù)器更近，從而起到一定的加速作用；
緩存作用：代理服務(wù)器保存從原始服務(wù)器所獲取的資源，從而實(shí)現(xiàn)客戶端快速的獲取；
隱藏真實(shí)地址：代理服務(wù)器代替客戶端去獲取原始服務(wù)器資源，從而隱藏客戶端真實(shí)信息。
簡述高可用集群可通過哪兩個維度衡量高可用性，各自含義是什么？
RTO（Recovery Time Objective）：RTO 指服務(wù)恢復(fù)的時間，最佳的情況是 0，即服務(wù)立即恢復(fù)；最壞是無窮大，即服務(wù)永遠(yuǎn)無法恢復(fù)；
RPO（Recovery Point Objective）：RPO 指指當(dāng)災(zāi)難發(fā)生時允許丟失的數(shù)據(jù)量，0 意味著使用同步的數(shù)據(jù)，大于 0 意味著有數(shù)據(jù)丟失，如“RPO=1 d”指恢復(fù)時使用一天前的數(shù)據(jù)，那么一天之內(nèi)的數(shù)據(jù)就丟失了。因此，恢復(fù)的最佳情況是 RTO = RPO = 0，幾乎無法實(shí)現(xiàn)。
簡述什么是 CAP 理論？
CAP 理論指出了在分布式系統(tǒng)中需要滿足的三個條件，主要包括：

Consistency（一致性）：所有節(jié)點(diǎn)在同一時間具有相同的數(shù)據(jù)；
Availability（可用性）：保證每個請求不管成功或者失敗都有響應(yīng)；
Partition tolerance（分區(qū)容錯性）：系統(tǒng)中任意信息的丟失或失敗不影響系統(tǒng)的繼續(xù)運(yùn)行。
CAP 理論的核心是：一個分布式系統(tǒng)不可能同時很好的滿足一致性，可用性和分區(qū)容錯性這三個需求，最多只能同時較好的滿足兩個。

簡述什么是 ACID 理論？
原子性(Atomicity)：整體不可分割性，要么全做要不全不做；
一致性(Consistency)：事務(wù)執(zhí)行前、后數(shù)據(jù)庫狀態(tài)均一致；
隔離性(Isolation)：在事務(wù)未提交前，它操作的數(shù)據(jù)，對其它用戶不可見；
持久性 (Durable)：一旦事務(wù)成功，將進(jìn)行永久的變更，記錄與 redo 日志。
簡述什么是 Kubernetes？
Kubernetes 是一個全新的基于容器技術(shù)的分布式系統(tǒng)支撐平臺。是 Google 開源的容器集群管理系統(tǒng)（谷歌內(nèi)部:Borg）。在 Docker 技術(shù)的基礎(chǔ)上，為容器化的應(yīng)用提供部署運(yùn)行、資源調(diào)度、服務(wù)發(fā)現(xiàn)和動態(tài)伸縮等一系列完整功能，提高了大規(guī)模容器集群管理的便捷性。并且具有完備的集群管理能力，多層次的安全防護(hù)和準(zhǔn)入機(jī)制、多租戶應(yīng)用支撐能力、透明的服務(wù)注冊和發(fā)現(xiàn)機(jī)制、內(nèi)建智能負(fù)載均衡器、強(qiáng)大的故障發(fā)現(xiàn)和自我修復(fù)能力、服務(wù)滾動升級和在線擴(kuò)容能力、可擴(kuò)展的資源自動調(diào)度機(jī)制以及多粒度的資源配額管理能力。

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

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

簡述 Kubernetes 中什么是 Minikube、Kubectl、Kubelet？
Minikube 是一種可以在本地輕松運(yùn)行一個單節(jié)點(diǎn) Kubernetes 群集的工具。

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

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

簡述 Kubernetes 常見的部署方式？
常見的 Kubernetes 部署方式有：

kubeadm：也是推薦的一種部署方式；
二進(jìn)制：
minikube：在本地輕松運(yùn)行一個單節(jié)點(diǎn) Kubernetes 群集的工具。
簡述 Kubernetes 如何實(shí)現(xiàn)集群管理？
在集群管理方面，Kubernetes 將集群中的機(jī)器劃分為一個 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)了整個集群的資源管理、Pod 調(diào)度、彈性伸縮、安全控制、系統(tǒng)監(jiān)控和糾錯等管理能力，并且都是全自動完成的。

簡述 Kubernetes 的優(yōu)勢、適應(yīng)場景及其特點(diǎn)？
Kubernetes 作為一個完備的分布式系統(tǒng)支撐平臺，其主要優(yōu)勢：

容器編排
輕量級
開源
彈性伸縮
負(fù)載均衡
Kubernetes 常見場景：

快速部署應(yīng)用
快速擴(kuò)展應(yīng)用
無縫對接新的應(yīng)用功能
節(jié)省資源，優(yōu)化硬件資源的使用
Kubernetes 相關(guān)特點(diǎn)：

可移植: 支持公有云、私有云、混合云、多重云（multi-cloud）。
可擴(kuò)展: 模塊化,、插件化、可掛載、可組合。
自動化: 自動部署、自動重啟、自動復(fù)制、自動伸縮/擴(kuò)展。
簡述 Kubernetes 的缺點(diǎn)或當(dāng)前的不足之處？
Kubernetes 當(dāng)前存在的缺點(diǎn)（不足）如下：

安裝過程和配置相對困難復(fù)雜。
管理服務(wù)相對繁瑣。
運(yùn)行和編譯需要很多時間。
它比其他替代品更昂貴。
對于簡單的應(yīng)用程序來說，可能不需要涉及 Kubernetes 即可滿足。
簡述 Kubernetes 相關(guān)基礎(chǔ)概念？
master：k8s 集群的管理節(jié)點(diǎn)，負(fù)責(zé)管理集群，提供集群的資源數(shù)據(jù)訪問入口。擁有 Etcd 存儲服務(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 集群操作的單元，用來承載被分配 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 地址和端口，能夠通過 localhost 進(jìn)行通信。Pod 是 Kurbernetes 進(jìn)行創(chuàng)建、調(diào)度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個 Pod 可以包含一個容器或者多個相關(guān)容器。
label：Kubernetes 中的 Label 實(shí)質(zhì)是一系列的 Key/Value 鍵值對，其中 key 與 value 可自定義。Label 可以附加到各種資源對象上，如 Node、Pod、Service、RC 等。一個資源對象可以定義任意數(shù)量的 Label，同一個 Label 也可以被添加到任意數(shù)量的資源對象上去。Kubernetes 通過 Label Selector（標(biāo)簽選擇器）查詢和篩選資源對象。
Replication Controller：Replication Controller 用來管理 Pod 的副本，保證集群中存在指定數(shù)量的 Pod 副本。集群中副本的數(shù)量大于指定數(shù)量，則會停止指定數(shù)量之外的多余容器數(shù)量。反之，則會啟動少于指定數(shù)量個數(shù)的容器，保證數(shù)量不變。Replication Controller 是實(shí)現(xiàn)彈性伸縮、動態(tài)擴(kuò)容和滾動升級的核心。
Deployment：Deployment 在內(nèi)部使用了 RS 來實(shí)現(xiàn)目的，Deployment 相當(dāng)于 RC 的一次升級，其最大的特色為可以隨時獲知當(dāng)前 Pod 的部署進(jìn)度。
HPA（Horizontal Pod Autoscaler）：Pod 的橫向自動擴(kuò)容，也是 Kubernetes 的一種資源，通過追蹤分析 RC 控制的所有 Pod 目標(biāo)的負(fù)載變化情況，來確定是否需要針對性的調(diào)整 Pod 副本數(shù)量。
Service：Service 定義了 Pod 的邏輯集合和訪問該集合的策略，是真實(shí)服務(wù)的抽象。Service 提供了一個統(tǒng)一的服務(wù)訪問入口以及服務(wù)代理和發(fā)現(xiàn)機(jī)制，關(guān)聯(lián)多個相同 Label 的 Pod，用戶不需要了解后臺 Pod 是如何運(yùn)行。
Volume：Volume 是 Pod 中能夠被多個容器訪問的共享目錄，Kubernetes 中的 Volume 是定義在 Pod 上，可以被一個或多個 Pod 中的容器掛載到某個目錄下。
Namespace：Namespace 用于實(shí)現(xiàn)多租戶的資源隔離，可將集群內(nèi)部的資源對象分配到不同的 Namespace 中，形成邏輯上的不同項目、小組或用戶組，便于不同的 Namespace 在共享使用整個集群的資源的同時還能被分別管理。
簡述 Kubernetes 集群相關(guān)組件？
Kubernetes Master 控制組件，調(diào)度管理整個系統(tǒng)（集群），包含如下組件:

Kubernetes API Server：作為 Kubernetes 系統(tǒng)的入口，其封裝了核心對象的增刪改查操作，以 RESTful API 接口方式提供給外部客戶和內(nèi)部組件調(diào)用，集群內(nèi)各個功能模塊之間數(shù)據(jù)交互和通信的中心樞紐。
Kubernetes Scheduler：為新建立的 Pod 進(jìn)行節(jié)點(diǎn)(node)選擇(即分配機(jī)器)，負(fù)責(zé)集群的資源調(diào)度。
Kubernetes Controller：負(fù)責(zé)執(zhí)行各種控制器，目前已經(jīng)提供了很多控制器來保證 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)識出(失效|未失效)的 Node 節(jié)點(diǎn)。
Namespace Controller：管理維護(hù) Namespace，定期清理無效的 Namespace，包括 Namesapce 下的 API 對象，比如 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í)時更新 Endpoints。
Service Account Controller：管理維護(hù) Service Account，為每個 Namespace 創(chuàng)建默認(rèn)的 Service Account，同時為 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í)現(xiàn) Replication Controller 和 Pod 的更新。
Job Controller：管理維護(hù) Job，為 Jod 創(chuàng)建一次性任務(wù) Pod，保證完成 Job 指定完成的任務(wù)數(shù)目
Pod Autoscaler Controller：實(shí)現(xiàn) Pod 的自動伸縮，定時獲取監(jiān)控數(shù)據(jù)，進(jìn)行策略匹配，當(dāng)滿足條件時執(zhí)行 Pod 的伸縮動作。
簡述 Kubernetes RC 的機(jī)制？
Replication Controller 用來管理 Pod 的副本，保證集群中存在指定數(shù)量的 Pod 副本。當(dāng)定義了 RC 并提交至 Kubernetes 集群中之后，Master 節(jié)點(diǎn)上的 Controller Manager 組件獲悉，并同時巡檢系統(tǒng)中當(dāng)前存活的目標(biāo) Pod，并確保目標(biāo) Pod 實(shí)例的數(shù)量剛好等于此 RC 的期望值，若存在過多的 Pod 副本在運(yùn)行，系統(tǒng)會停止一些 Pod，反之則自動創(chuàng)建一些 Pod。

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

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

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

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

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

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

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

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

為大型集群提供了更好的可擴(kuò)展性和性能；
支持比 iptables 更復(fù)雜的復(fù)制均衡算法（最小負(fù)載、最少連接、加權(quán)等）；
支持服務(wù)器健康檢查和連接重試等功能；
可以動態(tài)修改 ipset 的集合，即使 iptables 的規(guī)則正在使用這個集合。
簡述 Kubernetes 中什么是靜態(tài) Pod？
靜態(tài) pod 是由 kubelet 進(jìn)行管理的僅存在于特定 Node 的 Pod 上，他們不能通過 API Server 進(jìn)行管理，無法與 ReplicationController、Deployment 或者 DaemonSet 進(jìn)行關(guān)聯(lián)，并且 kubelet 無法對他們進(jìn)行健康檢查。靜態(tài) Pod 總是由 kubelet 進(jìn)行創(chuàng)建，并且總是在 kubelet 所在的 Node 上運(yùn)行。

簡述 Kubernetes 中 Pod 可能位于的狀態(tài)？
Pending：API Server 已經(jīng)創(chuàng)建該 Pod，且 Pod 內(nèi)還有一個或多個容器的鏡像沒有創(chuàng)建，包括正在下載鏡像的過程。
Running：Pod 內(nèi)所有容器均已創(chuàng)建，且至少有一個容器處于運(yùn)行狀態(tài)、正在啟動狀態(tài)或正在重啟狀態(tài)。
Succeeded：Pod 內(nèi)所有容器均成功執(zhí)行退出，且不會重啟。
Failed：Pod 內(nèi)所有容器均已退出，但至少有一個容器退出為失敗狀態(tài)。
Unknown：由于某種原因無法獲取該 Pod 狀態(tài)，可能由于網(wǎng)絡(luò)通信不暢導(dǎo)致。
簡述 Kubernetes 創(chuàng)建一個 Pod 的主要流程？
Kubernetes 中創(chuàng)建一個 Pod 涉及多個組件之間聯(lián)動，主要流程如下：

客戶端提交 Pod 的配置信息（可以是 yaml 文件定義的信息）到 kube-apiserver。
Apiserver 收到指令后，通知給 controller-manager 創(chuàng)建一個資源對象。
Controller-manager 通過 api-server 將 pod 的配置信息存儲到 ETCD 數(shù)據(jù)中心中。
Kube-scheduler 檢測到 pod 信息會開始調(diào)度預(yù)選，會先過濾掉不符合 Pod 資源配置要求的節(jié)點(diǎn)，然后開始調(diào)度調(diào)優(yōu)，主要是挑選出更適合運(yùn)行 pod 的節(jié)點(diǎn)，然后將 pod 的資源配置單發(fā)送到 node 節(jié)點(diǎn)上的 kubelet 組件上。
Kubelet 根據(jù) scheduler 發(fā)來的資源配置單運(yùn)行 pod，運(yùn)行成功后，將 pod 的運(yùn)行信息返回給 scheduler，scheduler 將返回的 pod 運(yùn)行狀況的信息存儲到 etcd 數(shù)據(jù)中心。
簡述 Kubernetes 中 Pod 的重啟策略？
Pod 重啟策略（RestartPolicy）應(yīng)用于 Pod 內(nèi)的所有容器，并且僅在 Pod 所處的 Node 上由 kubelet 進(jìn)行判斷和重啟操作。當(dāng)某個容器異常退出或者健康檢查失敗時，kubelet 將根據(jù) RestartPolicy 的設(shè)置來進(jìn)行相應(yīng)操作。

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

Always：當(dāng)容器失效時，由 kubelet 自動重啟該容器；
OnFailure：當(dāng)容器終止運(yùn)行且退出碼不為 0 時，由 kubelet 自動重啟該容器；
Never：不論容器運(yùn)行狀態(tài)如何，kubelet 都不會重啟該容器。
同時 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 失效時重啟，不論將 RestartPolicy 設(shè)置為何值，也不會對 Pod 進(jìn)行健康檢查。
簡述 Kubernetes 中 Pod 的健康檢查方式？
對 Pod 的健康檢查可以通過兩類探針來檢查：LivenessProbe 和 ReadinessProbe。

LivenessProbe 探針：用于判斷容器是否存活（running 狀態(tài)），如果 LivenessProbe 探針探測到容器不健康，則 kubelet 將殺掉該容器，并根據(jù)容器的重啟策略做相應(yīng)處理。若一個容器不包含 LivenessProbe 探針，kubelet 認(rèn)為該容器的 LivenessProbe 探針返回值用于是“Success”。
ReadineeProbe 探針：用于判斷容器是否啟動完成（ready 狀態(tài)）。如果 ReadinessProbe 探針探測到失敗，則 Pod 的狀態(tài)將被修改。Endpoint Controller 將從 Service 的 Endpoint 中刪除包含該容器所在 Pod 的 Eenpoint。
startupProbe 探針：啟動檢查機(jī)制，應(yīng)用一些啟動緩慢的業(yè)務(wù)，避免業(yè)務(wù)長時間啟動而被上面兩類探針 kill 掉。
簡述 Kubernetes Pod 的 LivenessProbe 探針的常見方式？
kubelet 定期執(zhí)行 LivenessProbe 探針來診斷容器的健康狀態(tài)，通常有以下三種方式：

ExecAction：在容器內(nèi)執(zhí)行一個命令，若返回碼為 0，則表明容器健康。
TCPSocketAction：通過容器的 IP 地址和端口號執(zhí)行 TCP 檢查，若能建立 TCP 連接，則表明容器健康。
HTTPGetAction：通過容器的 IP 地址、端口號及路徑調(diào)用 HTTP Get 方法，若響應(yīng)的狀態(tài)碼大于等于 200 且小于 400，則表明容器健康。
簡述 Kubernetes Pod 的常見調(diào)度方式？
Kubernetes 中，Pod 通常是容器的載體，主要有如下常見調(diào)度方式：

Deployment 或 RC：該調(diào)度策略主要功能就是自動部署一個容器應(yīng)用的多份副本，以及持續(xù)監(jiān)控副本的數(shù)量，在集群內(nèi)始終維持用戶指定的副本數(shù)量。
NodeSelector：定向調(diào)度，當(dāng)需要手動指定將 Pod 調(diào)度到特定 Node 上，可以通過 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，語法不同）。
preferredDuringSchedulingIgnoredDuringExecution：軟規(guī)則，優(yōu)先調(diào)度至滿足的 Node 的節(jié)點(diǎn)，但不強(qiáng)求，多個優(yōu)先級規(guī)則還可以設(shè)置權(quán)重值。
Taints 和 Tolerations（污點(diǎn)和容忍）：
Taint：使 Node 拒絕特定 Pod 運(yùn)行；
Toleration：為 Pod 的屬性，表示 Pod 能容忍（運(yùn)行）標(biāo)注了 Taint 的 Node。
簡述 Kubernetes 初始化容器（init container）？
init container 的運(yùn)行方式與應(yīng)用容器不同，它們必須先于應(yīng)用容器執(zhí)行完成，當(dāng)設(shè)置了多個 init container 時，將按順序逐個運(yùn)行，并且只有前一個 init container 運(yùn)行成功后才能運(yùn)行后一個 init container。當(dāng)所有 init container 都成功運(yùn)行后，Kubernetes 才會初始化 Pod 的各種信息，并開始創(chuàng)建和運(yùn)行應(yīng)用容器。

簡述 Kubernetes deployment 升級過程？
初始創(chuàng)建 Deployment 時，系統(tǒng)創(chuàng)建了一個 ReplicaSet，并按用戶的需求創(chuàng)建了對應(yīng)數(shù)量的 Pod 副本。
當(dāng)更新 Deployment 時，系統(tǒng)創(chuàng)建了一個新的 ReplicaSet，并將其副本數(shù)量擴(kuò)展到 1，然后將舊 ReplicaSet 縮減為 2。
之后，系統(tǒng)繼續(xù)按照相同的更新策略對新舊兩個 ReplicaSet 進(jìn)行逐個調(diào)整。
最后，新的 ReplicaSet 運(yùn)行了對應(yīng)個新版本 Pod 副本，舊的 ReplicaSet 副本數(shù)量則縮減為 0。
簡述 Kubernetes deployment 升級策略？
在 Deployment 的定義中，可以通過 spec.strategy 指定 Pod 更新的策略，目前支持兩種策略：Recreate（重建）和 RollingUpdate（滾動更新），默認(rèn)值為 RollingUpdate。

Recreate：設(shè)置 spec.strategy.type=Recreate，表示 Deployment 在更新 Pod 時，會先殺掉所有正在運(yùn)行的 Pod，然后創(chuàng)建新的 Pod。
RollingUpdate：設(shè)置 spec.strategy.type=RollingUpdate，表示 Deployment 會以滾動更新的方式來逐個更新 Pod。同時，可以通過設(shè)置 spec.strategy.rollingUpdate 下的兩個參數(shù)（maxUnavailable 和 maxSurge）來控制滾動更新的過程。
簡述 Kubernetes DaemonSet 類型的資源特性？
DaemonSet 資源對象會在每個 Kubernetes 集群中的節(jié)點(diǎn)上運(yùn)行，并且每個節(jié)點(diǎn)只能運(yùn)行一個 pod，這是它和 deployment 資源對象的最大也是唯一的區(qū)別。

因此，在定義 yaml 文件中，不支持定義 replicas。

它的一般使用場景如下：

在去做每個節(jié)點(diǎn)的日志收集工作。
監(jiān)控每個節(jié)點(diǎn)的的運(yùn)行狀態(tài)。
簡述 Kubernetes 自動擴(kuò)容機(jī)制？
Kubernetes 使用 Horizontal Pod Autoscaler（HPA）的控制器實(shí)現(xiàn)基于 CPU 使用率進(jìn)行自動 Pod 擴(kuò)縮容的功能。

HPA 控制器周期性地監(jiān)測目標(biāo) Pod 的資源性能指標(biāo)，并與 HPA 資源對象中的擴(kuò)縮容條件進(jìn)行對比，在滿足條件時對 Pod 副本數(shù)量進(jìn)行調(diào)整。

HPA 原理
Kubernetes 中的某個 Metrics Server（Heapster 或自定義 Metrics Server）持續(xù)采集所有 Pod 副本的指標(biāo)數(shù)據(jù)。

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

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

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

ClusterIP：虛擬的服務(wù) IP 地址，該地址用于 Kubernetes 集群內(nèi)部的 Pod 訪問，在 Node 上 kube-proxy 通過設(shè)置的 iptables 規(guī)則進(jìn)行轉(zhuǎn)發(fā)；
NodePort：使用宿主機(jī)的端口，使能夠訪問各 Node 的外部客戶端通過 Node 的 IP 地址和端口號就能訪問服務(wù)；
LoadBalancer：使用外接負(fù)載均衡器完成到服務(wù)的負(fù)載分發(fā)，需要在 spec.status.loadBalancer 字段指定外部負(fù)載均衡器的 IP 地址，通常用于公有云。
簡述 Kubernetes Service 分發(fā)后端的策略？
Service 負(fù)載分發(fā)的策略有：RoundRobin 和 SessionAffinity

RoundRobin：默認(rèn)為輪詢模式，即輪詢將請求轉(zhuǎn)發(fā)到后端的各個 Pod 上。
SessionAffinity：基于客戶端 IP 地址進(jìn)行會話保持的模式，即第 1 次將某個客戶端發(fā)起的請求轉(zhuǎn)發(fā)到后端的某個 Pod 上，之后從相同的客戶端發(fā)起的請求都將被轉(zhuǎn)發(fā)到后端相同的 Pod 上。
簡述 Kubernetes Headless Service？
在某些應(yīng)用場景中，若需要人為指定負(fù)載均衡器，不使用 Service 提供的默認(rèn)負(fù)載均衡的功能，或者應(yīng)用程序希望知道屬于同組服務(wù)的其他實(shí)例。

Kubernetes 提供了 Headless Service 來實(shí)現(xiàn)這種功能，即不為 Service 設(shè)置 ClusterIP（入口 IP 地址），僅通過 Label Selector 將后端的 Pod 列表返回給調(diào)用的客戶端。

簡述 Kubernetes 外部如何訪問集群內(nèi)的服務(wù)？
對于 Kubernetes，集群外的客戶端默認(rèn)情況，無法通過 Pod 的 IP 地址或者 Service 的虛擬 IP 地址:虛擬端口號進(jìn)行訪問。

通常可以通過以下方式進(jìn)行訪問 Kubernetes 集群內(nèi)的服務(wù)：

映射 Pod 到物理機(jī)：將 Pod 端口號映射到宿主機(jī)，即在 Pod 中采用 hostPort 方式，以使客戶端應(yīng)用能夠通過物理機(jī)訪問容器應(yīng)用。
映射 Service 到物理機(jī)：將 Service 端口號映射到宿主機(jī)，即在 Service 中采用 nodePort 方式，以使客戶端應(yīng)用能夠通過物理機(jī)訪問容器應(yīng)用。
映射 Sercie 到 LoadBalancer：通過設(shè)置 LoadBalancer 映射到云服務(wù)商提供的 LoadBalancer 地址。這種用法僅用于在公有云服務(wù)提供商的云平臺上設(shè)置 Service 的場景。
簡述 Kubernetes ingress？
Kubernetes 的 Ingress 資源對象，用于將不同 URL 的訪問請求轉(zhuǎn)發(fā)到后端不同的 Service，以實(shí)現(xiàn) HTTP 層的業(yè)務(wù)路由機(jī)制。

Kubernetes 使用了 Ingress 策略和 Ingress Controller，兩者結(jié)合并實(shí)現(xiàn)了一個完整的 Ingress 負(fù)載均衡器。

使用 Ingress 進(jìn)行負(fù)載分發(fā)時，Ingress Controller 基于 Ingress 規(guī)則將客戶端請求直接轉(zhuǎn)發(fā)到 Service 對應(yīng)的后端 Endpoint（Pod）上，從而跳過 kube-proxy 的轉(zhuǎn)發(fā)功能，kube-proxy 不再起作用，全過程為：ingress controller + ingress 規(guī)則 ----> services。

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

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

Always：鏡像標(biāo)簽為 latest 時，總是從指定的倉庫中獲取鏡像。
Never：禁止從倉庫中下載鏡像，也就是說只能使用本地鏡像。
IfNotPresent：僅當(dāng)本地沒有對應(yīng)鏡像時，才從目標(biāo)倉庫中下載。默認(rèn)的鏡像下載策略是：當(dāng)鏡像標(biāo)簽是 latest 時，默認(rèn)策略是 Always；當(dāng)鏡像標(biāo)簽是自定義時（也就是標(biāo)簽不是 latest），那么默認(rèn)策略是 IfNotPresent。
簡述 Kubernetes 的負(fù)載均衡器？
負(fù)載均衡器是暴露服務(wù)的最常見和標(biāo)準(zhǔn)方式之一。

根據(jù)工作環(huán)境使用兩種類型的負(fù)載均衡器，即內(nèi)部負(fù)載均衡器或外部負(fù)載均衡器。

內(nèi)部負(fù)載均衡器自動平衡負(fù)載并使用所需配置分配容器，而外部負(fù)載均衡器將流量從外部負(fù)載引導(dǎo)至后端容器。

簡述 Kubernetes 各模塊如何與 API Server 通信？
Kubernetes API Server 作為集群的核心，負(fù)責(zé)集群各功能模塊之間的通信。

集群內(nèi)的各個功能模塊通過 API Server 將信息存入 etcd，當(dāng)需要獲取和操作這些數(shù)據(jù)時，則通過 API Server 提供的 REST 接口（用 GET、LIST 或 WATCH 方法）來實(shí)現(xiàn)，從而實(shí)現(xiàn)各模塊之間的信息交互。

如 kubelet 進(jìn)程與 API Server 的交互：每個 Node 上的 kubelet 每隔一個時間周期，就會調(diào)用一次 API Server 的 REST 接口報告自身狀態(tài)，API Server 在接收到這些信息后，會將節(jié)點(diǎn)狀態(tài)信息更新到 etcd 中。

如 kube-controller-manager 進(jìn)程與 API Server 的交互：kube-controller-manager 中的 Node Controller 模塊通過 API Server 提供的 Watch 接口實(shí)時監(jiān)控 Node 的信息，并做相應(yīng)處理。

如 kube-scheduler 進(jìn)程與 API Server 的交互：Scheduler 通過 API Server 的 Watch 接口監(jiān)聽到新建 Pod 副本的信息后，會檢索所有符合該 Pod 要求的 Node 列表，開始執(zhí)行 Pod 調(diào)度邏輯，在調(diào)度成功后將 Pod 綁定到目標(biāo)節(jié)點(diǎn)上。

簡述 Kubernetes Scheduler 作用及實(shí)現(xiàn)原理？
Kubernetes Scheduler 是負(fù)責(zé) Pod 調(diào)度的重要功能模塊，Kubernetes Scheduler 在整個系統(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）到集群中某個合適的 Node 上，并將綁定信息寫入 etcd 中。

在整個調(diào)度過程中涉及三個對象：

分別是待調(diào)度 Pod 列表、可用 Node 列表，以及調(diào)度算法和策略。

Kubernetes Scheduler 通過調(diào)度算法調(diào)度為待調(diào)度 Pod 列表中的每個 Pod 從 Node 列表中選擇一個最適合的 Node 來實(shí)現(xiàn) Pod 的調(diào)度。

隨后，目標(biāo)節(jié)點(diǎn)上的 kubelet 通過 API Server 監(jiān)聽到 Kubernetes Scheduler 產(chǎn)生的 Pod 綁定事件，然后獲取對應(yīng)的 Pod 清單，下載 Image 鏡像并啟動容器。

簡述 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)選會根據(jù)優(yōu)先策略為通過預(yù)選的 Nodes 進(jìn)行打分排名，選擇得分最高的 Node。例如，資源越富裕、負(fù)載越小的 Node 可能具有越高的排名。
簡述 Kubernetes kubelet 的作用？
在 Kubernetes 集群中，在每個 Node（又稱 Worker）上都會啟動一個 kubelet 服務(wù)進(jìn)程。

該進(jìn)程用于處理 Master 下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理 Pod 及 Pod 中的容器。

每個 kubelet 進(jìn)程都會在 API Server 上注冊節(jié)點(diǎn)自身的信息，定期向 Master 匯報節(jié)點(diǎn)資源的使用情況，并通過 cAdvisor 監(jiān)控容器和節(jié)點(diǎn)資源。

簡述 Kubernetes kubelet 監(jiān)控 Worker 節(jié)點(diǎn)資源是使用什么組件來實(shí)現(xiàn)的？
kubelet 使用 cAdvisor 對 worker 節(jié)點(diǎn)資源進(jìn)行監(jiān)控。

在 Kubernetes 系統(tǒng)中，cAdvisor 已被默認(rèn)集成到 kubelet 組件內(nèi)，當(dāng) kubelet 服務(wù)啟動時，它會自動啟動 cAdvisor 服務(wù)，然后 cAdvisor 會實(shí)時采集所在節(jié)點(diǎn)的性能指標(biāo)及在節(jié)點(diǎn)上運(yùn)行的容器的性能指標(biāo)。

簡述 Kubernetes 如何保證集群的安全性？
Kubernetes 通過一系列機(jī)制來實(shí)現(xiàn)集群的安全控制，

主要有如下不同的維度：

基礎(chǔ)設(shè)施方面：保證容器與其所在宿主機(jī)的隔離；
權(quán)限方面：
最小權(quán)限原則：合理限制所有組件的權(quán)限，確保組件只執(zhí)行它被授權(quán)的行為，通過限制單個組件的能力來限制它的權(quán)限范圍。
用戶權(quán)限：劃分普通用戶和管理員的角色。
集群方面：
API Server 的認(rèn)證授權(quán)：Kubernetes 集群中所有資源的訪問和變更都是通過 Kubernetes API Server 來實(shí)現(xiàn)的，因此需要建議采用更安全的 HTTPS 或 Token 來識別和認(rèn)證客戶端身份（Authentication），以及隨后訪問權(quán)限的授權(quán)（Authorization）環(huán)節(jié)。
API Server 的授權(quán)管理：通過授權(quán)策略來決定一個 API 調(diào)用是否合法。對合法用戶進(jìn)行授權(quán)并且隨后在用戶訪問時進(jìn)行鑒權(quán)，建議采用更安全的 RBAC 方式來提升集群安全授權(quán)。
敏感數(shù)據(jù)引入 Secret 機(jī)制：對于集群敏感數(shù)據(jù)建議使用 Secret 方式進(jìn)行保護(hù)。
AdmissionControl（準(zhǔn)入機(jī)制）：對 kubernetes api 的請求過程中，順序?yàn)椋合冉?jīng)過認(rèn)證 & 授權(quán)，然后執(zhí)行準(zhǔn)入操作，最后對目標(biāo)對象進(jìn)行操作。
簡述 Kubernetes 準(zhǔn)入機(jī)制？
在對集群進(jìn)行請求時，每個準(zhǔn)入控制代碼都按照一定順序執(zhí)行。

如果有一個準(zhǔn)入控制拒絕了此次請求，那么整個請求的結(jié)果將會立即返回，并提示用戶相應(yīng)的 error 信息。

準(zhǔn)入控制（AdmissionControl）準(zhǔn)入控制本質(zhì)上為一段準(zhǔn)入代碼，在對 kubernetes api 的請求過程中，順序?yàn)椋合冉?jīng)過認(rèn)證 & 授權(quán)，然后執(zhí)行準(zhǔn)入操作，最后對目標(biāo)對象進(jìn)行操作。常用組件（控制代碼）如下：

AlwaysAdmit：允許所有請求
AlwaysDeny：禁止所有請求，多用于測試環(huán)境。
ServiceAccount：它將 serviceAccounts 實(shí)現(xiàn)了自動化，它會輔助 serviceAccount 做一些事情，比如如果 pod 沒有 serviceAccount 屬性，它會自動添加一個 default，并確保 pod 的 serviceAccount 始終存在。
LimitRanger：觀察所有的請求，確保沒有違反已經(jīng)定義好的約束條件，這些條件定義在 namespace 中 LimitRange 對象中。
NamespaceExists：觀察所有的請求，如果請求嘗試創(chuàng)建一個不存在的 namespace，則這個請求被拒絕。
簡述 Kubernetes RBAC 及其特點(diǎn)（優(yōu)勢）？
RBAC 是基于角色的訪問控制，是一種基于個人用戶的角色來管理對計算機(jī)或網(wǎng)絡(luò)資源的訪問的方法。

相對于其他授權(quán)模式，RBAC 具有如下優(yōu)勢：

對集群中的資源和非資源權(quán)限均有完整的覆蓋。
整個 RBAC 完全由幾個 API 對象完成， 同其他 API 對象一樣， 可以用 kubectl 或 API 進(jìn)行操作。
可以在運(yùn)行時進(jìn)行調(diào)整，無須重新啟動 API Server。
簡述 Kubernetes Secret 作用？
Secret 對象，主要作用是保管私密數(shù)據(jù)，比如密碼、OAuth Tokens、SSH Keys 等信息。

將這些私密信息放在 Secret 對象中比直接放在 Pod 或 Docker Image 中更安全，也更便于使用和分發(fā)。

簡述 Kubernetes Secret 有哪些使用方式？
創(chuàng)建完 secret 之后，可通過如下三種方式使用：

在創(chuàng)建 Pod 時，通過為 Pod 指定 Service Account 來自動使用該 Secret。
通過掛載該 Secret 到 Pod 來使用它。
在 Docker 鏡像下載時使用，通過指定 Pod 的 spc.ImagePullSecrets 來引用它。
簡述 Kubernetes PodSecurityPolicy 機(jī)制？
Kubernetes PodSecurityPolicy 是為了更精細(xì)地控制 Pod 對資源的使用方式以及提升安全策略。

在開啟 PodSecurityPolicy 準(zhǔn)入控制器后，Kubernetes 默認(rèn)不允許創(chuàng)建任何 Pod，需要創(chuàng)建 PodSecurityPolicy 策略和相應(yīng)的 RBAC 授權(quán)策略（Authorizing Policies），Pod 才能創(chuàng)建成功。

簡述 Kubernetes PodSecurityPolicy 機(jī)制能實(shí)現(xiàn)哪些安全策略？
在 PodSecurityPolicy 對象中可以設(shè)置不同字段來控制 Pod 運(yùn)行時的各種安全策略，常見的有：

特權(quán)模式：privileged 是否允許 Pod 以特權(quán)模式運(yùn)行。
宿主機(jī)資源：控制 Pod 對宿主機(jī)資源的控制，如 hostPID：是否允許 Pod 共享宿主機(jī)的進(jìn)程空間。
用戶和組：設(shè)置運(yùn)行容器的用戶 ID（范圍）或組（范圍）。
提升權(quán)限：AllowPrivilegeEscalation：設(shè)置容器內(nèi)的子進(jìn)程是否可以提升權(quán)限，通常在設(shè)置非 root 用戶（MustRunAsNonRoot）時進(jìn)行設(shè)置。
SELinux：進(jìn)行 SELinux 的相關(guān)配置。
簡述 Kubernetes 網(wǎng)絡(luò)模型？
Kubernetes 網(wǎng)絡(luò)模型中每個 Pod 都擁有一個獨(dú)立的 IP 地址，并假定所有 Pod 都在一個可以直接連通的、扁平的網(wǎng)絡(luò)空間中。

所以不管它們是否運(yùn)行在同一個 Node（宿主機(jī)）中，都要求它們可以直接通過對方的 IP 進(jìn)行訪問。

設(shè)計這個原則的原因是，用戶不需要額外考慮如何建立 Pod 之間的連接，也不需要考慮如何將容器端口映射到主機(jī)端口等問題。

同時為每個 Pod 都設(shè)置一個 IP 地址的模型使得同一個 Pod 內(nèi)的不同容器會共享同一個網(wǎng)絡(luò)命名空間，也就是同一個 Linux 網(wǎng)絡(luò)協(xié)議棧。這就意味著同一個 Pod 內(nèi)的容器可以通過 localhost 來連接對方的端口。

在 Kubernetes 的集群里，IP 是以 Pod 為單位進(jìn)行分配的。

一個 Pod 內(nèi)部的所有容器共享一個網(wǎng)絡(luò)堆棧（相當(dāng)于一個網(wǎng)絡(luò)命名空間，它們的 IP 地址、網(wǎng)絡(luò)設(shè)備、配置等都是共享的）。

簡述 Kubernetes CNI 模型？
CNI 提供了一種應(yīng)用容器的插件化網(wǎng)絡(luò)解決方案，定義對容器網(wǎng)絡(luò)進(jìn)行操作和配置的規(guī)范，通過插件的形式對 CNI 接口進(jìn)行實(shí)現(xiàn)。

CNI 僅關(guān)注在創(chuàng)建容器時分配網(wǎng)絡(luò)資源，和在銷毀容器時刪除網(wǎng)絡(luò)資源。在 CNI 模型中只涉及兩個概念：容器和網(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è)備（比如路由器）等。
對容器網(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é)對容器的 IP 地址進(jìn)行分配和管理。

IPAM Plugin 作為 CNI Plugin 的一部分，與 CNI Plugin 協(xié)同工作。

簡述 Kubernetes 網(wǎng)絡(luò)策略？
為實(shí)現(xiàn)細(xì)粒度的容器間網(wǎng)絡(luò)訪問隔離策略，Kubernetes 引入 Network Policy。

Network Policy 的主要功能是對 Pod 間的網(wǎng)絡(luò)通信進(jìn)行限制和準(zhǔn)入控制，設(shè)置允許訪問或禁止訪問的客戶端 Pod 列表。

Network Policy 定義網(wǎng)絡(luò)策略，配合策略控制器（Policy Controller）進(jìn)行策略的實(shí)現(xiàn)。

簡述 Kubernetes 網(wǎng)絡(luò)策略原理？
Network Policy 的工作原理主要為：policy controller 需要實(shí)現(xiàn)一個 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)）。

簡述 Kubernetes 中 flannel 的作用？
Flannel 可以用于 Kubernetes 底層網(wǎng)絡(luò)的實(shí)現(xiàn)，主要作用有：

它能協(xié)助 Kubernetes，給每一個 Node 上的 Docker 容器都分配互相不沖突的 IP 地址。
它能在這些 IP 地址之間建立一個覆蓋網(wǎng)絡(luò)（Overlay Network），通過這個覆蓋網(wǎng)絡(luò)，將數(shù)據(jù)包原封不動地傳遞到目標(biāo)容器內(nèi)。
簡述 Kubernetes Calico 網(wǎng)絡(luò)組件實(shí)現(xiàn)原理？
Calico 是一個基于 BGP 的純?nèi)龑拥木W(wǎng)絡(luò)方案，與 OpenStack、Kubernetes、AWS、GCE 等云平臺都能夠良好地集成。

Calico 在每個計算節(jié)點(diǎn)都利用 Linux Kernel 實(shí)現(xiàn)了一個高效的 vRouter 來負(fù)責(zé)數(shù)據(jù)轉(zhuǎn)發(fā)。每個 vRouter 都通過 BGP 協(xié)議把在本節(jié)點(diǎn)上運(yùn)行的容器的路由信息向整個 Calico 網(wǎng)絡(luò)廣播，并自動設(shè)置到達(dá)其他節(jié)點(diǎn)的路由轉(zhuǎn)發(fā)規(guī)則。

Calico 保證所有容器之間的數(shù)據(jù)流量都是通過 IP 路由的方式完成互聯(lián)互通的。

Calico 節(jié)點(diǎn)組網(wǎng)時可以直接利用數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)（L2 或者 L3），不需要額外的 NAT、隧道或者 Overlay Network，沒有額外的封包解包，能夠節(jié)約 CPU 運(yùn)算，提高網(wǎng)絡(luò)效率。

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

簡述 Kubernetes 數(shù)據(jù)持久化的方式有哪些？
Kubernetes 通過數(shù)據(jù)持久化來持久化保存重要數(shù)據(jù)，常見的方式有：

EmptyDir（空目錄）：沒有指定要掛載宿主機(jī)上的某個目錄，直接由 Pod 內(nèi)保部映射到宿主機(jī)上。類似于 docker 中的 manager volume。
場景：
只需要臨時將數(shù)據(jù)保存在磁盤上，比如在合并/排序算法中；
作為兩個容器的共享存儲。
特性：
同個 pod 里面的不同容器，共享同一個持久化目錄，當(dāng) pod 節(jié)點(diǎn)刪除時，volume 的數(shù)據(jù)也會被刪除。
emptyDir 的數(shù)據(jù)持久化的生命周期和使用的 pod 一致，一般是作為臨時存儲使用。
Hostpath：將宿主機(jī)上已存在的目錄或文件掛載到容器內(nèi)部。類似于 docker 中的 bind mount 掛載方式。
特性：增加了 pod 與節(jié)點(diǎn)之間的耦合。
PersistentVolume（簡稱 PV）：如基于 NFS 服務(wù)的 PV，也可以基于 GFS 的 PV。它的作用是統(tǒng)一數(shù)據(jù)持久化目錄，方便管理。

簡述 Kubernetes PV 和 PVC？
PV 是對底層網(wǎng)絡(luò)共享存儲的抽象，將共享存儲定義為一種“資源”。

PVC 則是用戶對存儲資源的一個“申請”。

簡述 Kubernetes PV 生命周期內(nèi)的階段？
某個 PV 在生命周期中可能處于以下 4 個階段（Phaes）之一。

Available：可用狀態(tài)，還未與某個 PVC 綁定。
Bound：已與某個 PVC 綁定。
Released：綁定的 PVC 已經(jīng)刪除，資源已釋放，但沒有被集群回收。
Failed：自動資源回收失敗。
簡述 Kubernetes 所支持的存儲供應(yīng)模式？
Kubernetes 支持兩種資源的存儲供應(yīng)模式：靜態(tài)模式（Static）和動態(tài)模式（Dynamic）。

**靜態(tài)模式****：**集群管理員手工創(chuàng)建許多 PV，在定義 PV 時需要將后端存儲的特性進(jìn)行設(shè)置。
**動態(tài)模式****：**集群管理員無須手工創(chuàng)建 PV，而是通過 StorageClass 的設(shè)置對后端存儲進(jìn)行描述，標(biāo)記為某種類型。此時要求 PVC 對存儲的類型進(jìn)行聲明，系統(tǒng)將自動完成 PV 的創(chuàng)建及與 PVC 的綁定。
簡述 Kubernetes CSI 模型？
Kubernetes CSI 是 Kubernetes 推出與容器對接的存儲接口標(biāo)準(zhǔn)，存儲提供方只需要基于標(biāo)準(zhǔn)接口進(jìn)行存儲插件的實(shí)現(xiàn)，就能使用 Kubernetes 的原生存儲機(jī)制為容器提供存儲服務(wù)。

CSI 使得存儲提供方的代碼能和 Kubernetes 代碼徹底解耦，部署也與 Kubernetes 核心組件分離，顯然，存儲插件的開發(fā)由提供方自行維護(hù)，就能為 Kubernetes 用戶提供更多的存儲功能，也更加安全可靠。

CSI 包括 CSI Controller 和 CSI Node：

CSI Controller 的主要功能是提供存儲服務(wù)視角對存儲資源和存儲卷進(jìn)行管理和操作。
CSI Node 的主要功能是對主機(jī)（Node）上的 Volume 進(jìn)行管理和操作。
簡述 Kubernetes Worker 節(jié)點(diǎn)加入集群的過程？
通常需要對 Worker 節(jié)點(diǎn)進(jìn)行擴(kuò)容，從而將應(yīng)用系統(tǒng)進(jìn)行水平擴(kuò)展。

主要過程如下：

在該 Node 上安裝 Docker、kubelet 和 kube-proxy 服務(wù)；
然后配置 kubelet 和 kubeproxy 的啟動參數(shù)，將 Master URL 指定為當(dāng)前 Kubernetes 集群 Master 的地址，最后啟動這些服務(wù)；
通過 kubelet 默認(rèn)的自動注冊機(jī)制，新的 Worker 將會自動加入現(xiàn)有的 Kubernetes 集群中；
Kubernetes Master 在接受了新 Worker 的注冊之后，會自動將其納入當(dāng)前集群的調(diào)度范圍。
簡述 Kubernetes Pod 如何實(shí)現(xiàn)對節(jié)點(diǎn)的資源控制？
Kubernetes 集群里的節(jié)點(diǎn)提供的資源主要是計算資源，計算資源是可計量的能被申請、分配和使用的基礎(chǔ)資源。

當(dāng)前 Kubernetes 集群中的計算資源主要包括 CPU、GPU 及 Memory。CPU 與 Memory 是被 Pod 使用的，因此在配置 Pod 時可以通過參數(shù) CPU Request 及 Memory Request 為其中的每個容器指定所需使用的 CPU 與 Memory 量，Kubernetes 會根據(jù) Request 的值去查找有足夠資源的 Node 來調(diào)度此 Pod。

通常，一個程序所使用的 CPU 與 Memory 是一個動態(tài)的量，確切地說，是一個范圍，跟它的負(fù)載密切相關(guān)：負(fù)載增加時，CPU 和 Memory 的使用量也會增加。

簡述 Kubernetes Requests 和 Limits 如何影響 Pod 的調(diào)度？
當(dāng)一個 Pod 創(chuàng)建成功時，Kubernetes 調(diào)度器（Scheduler）會為該 Pod 選擇一個節(jié)點(diǎn)來執(zhí)行。

對于每種計算資源（CPU 和 Memory）而言，每個節(jié)點(diǎn)都有一個能用于運(yùn)行 Pod 的最大容量值。調(diào)度器在調(diào)度時，首先要確保調(diào)度后該節(jié)點(diǎn)上所有 Pod 的 CPU 和內(nèi)存的 Requests 總和，不超過該節(jié)點(diǎn)能提供給 Pod 使用的 CPU 和 Memory 的最大容量值。

簡述 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)。

對其他自定義指標(biāo)（Custom Metrics）的監(jiān)控則由 Prometheus 等組件來完成。

簡述 Kubernetes 中，如何使用 EFK 實(shí)現(xiàn)日志的統(tǒng)一管理？
在 Kubernetes 集群環(huán)境中，通常一個完整的應(yīng)用或服務(wù)涉及組件過多，建議對日志系統(tǒng)進(jìn)行集中化管理，通常采用 EFK 實(shí)現(xiàn)。

EFK 是 Elasticsearch、Fluentd 和 Kibana 的組合，其各組件功能如下：

Elasticsearch：是一個搜索引擎，負(fù)責(zé)存儲日志并提供查詢接口；
Fluentd：負(fù)責(zé)從 Kubernetes 搜集日志，每個 node 節(jié)點(diǎn)上面的 fluentd 監(jiān)控并收集該節(jié)點(diǎn)上面的系統(tǒng)日志，并將處理過后的日志信息發(fā)送給 Elasticsearch；
Kibana：提供了一個 Web GUI，用戶可以瀏覽和搜索存儲在 Elasticsearch 中的日志。
通過在每臺 node 上部署一個以 DaemonSet 方式運(yùn)行的 fluentd 來收集每臺 node 上的日志。

Fluentd 將 docker 日志目錄/var/lib/docker/containers 和/var/log 目錄掛載到 Pod 中，然后 Pod 會在 node 節(jié)點(diǎn)的/var/log/pods 目錄中創(chuàng)建新的目錄，可以區(qū)別不同的容器日志輸出，該目錄下有一個日志文件鏈接到/var/lib/docker/contianers 目錄下的容器日志輸出。

簡述 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ù)。

簡述 Kubernetes 集群聯(lián)邦？
Kubernetes 集群聯(lián)邦可以將多個 Kubernetes 集群作為一個集群進(jìn)行管理。

因此，可以在一個數(shù)據(jù)中心/云中創(chuàng)建多個 Kubernetes 集群，并使用集群聯(lián)邦在一個地方控制/管理所有集群。

簡述 Helm 及其優(yōu)勢？
Helm 是 Kubernetes 的軟件包管理工具。類似 Ubuntu 中使用的 apt、Centos 中使用的 yum 或者 Python 中的 pip 一樣。

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

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

Helm 優(yōu)勢
在 Kubernetes 中部署一個可以使用的應(yīng)用，需要涉及到很多的 Kubernetes 資源的共同協(xié)作。

使用 helm 則具有如下優(yōu)勢：

統(tǒng)一管理、配置和更新這些分散的 k8s 的應(yīng)用資源文件；
分發(fā)和復(fù)用一套應(yīng)用模板；
將應(yīng)用的一系列資源當(dāng)做一個軟件包管理。
對于應(yīng)用發(fā)布者而言，可以通過 Helm 打包應(yīng)用、管理應(yīng)用依賴關(guān)系、管理應(yīng)用版本并發(fā)布應(yīng)用到軟件倉庫。
對于使用者而言，使用 Helm 后不用需要編寫復(fù)雜的應(yīng)用部署文件，可以以簡單的方式在 Kubernetes 上查找、安裝、升級、回滾、卸載應(yīng)用程序。
簡述 OpenShift 及其特性？
OpenShift 是一個容器應(yīng)用程序平臺，用于在安全的、可伸縮的資源上部署新應(yīng)用程序，而配置和管理開銷最小。

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

其主要特性：

自助服務(wù)平臺：OpenShift 允許開發(fā)人員使用 Source-to-Image(S2I)從模板或自己的源代碼管理存儲庫創(chuàng)建應(yīng)用程序。系統(tǒng)管理員可以為用戶和項目定義資源配額和限制，以控制系統(tǒng)資源的使用。
多語言支持：OpenShift 支持 Java、Node.js、PHP、Perl 以及直接來自 Red Hat 的 Ruby。OpenShift 還支持中間件產(chǎn)品，如 Apache httpd、Apache Tomcat、JBoss EAP、ActiveMQ 和 Fuse。
自動化：OpenShift 提供應(yīng)用程序生命周期管理功能，當(dāng)上游源或容器映像發(fā)生更改時，可以自動重新構(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ū)共享項目。
可伸縮性和高可用性：OpenShift 提供了容器多租戶和一個分布式應(yīng)用程序平臺，其中包括彈性，高可用性，以便應(yīng)用程序能夠在物理機(jī)器宕機(jī)等事件中存活下來。OpenShift 提供了對容器健康狀況的自動發(fā)現(xiàn)和自動重新部署。
容器可移植性：在 OpenShift 中，應(yīng)用程序和服務(wù)使用標(biāo)準(zhǔn)容器映像進(jìn)行打包，組合應(yīng)用程序使用 Kubernetes 進(jìn)行管理。這些映像可以部署到基于這些基礎(chǔ)技術(shù)的其他平臺上。
開源：沒有廠商鎖定。
安全性：OpenShift 使用 SELinux 提供多層安全性、基于角色的訪問控制以及與外部身份驗(yàn)證系統(tǒng)(如 LDAP 和 OAuth)集成的能力。
動態(tài)存儲管理：OpenShift 使用 Kubernetes 持久卷和持久卷聲明的方式為容器數(shù)據(jù)提供靜態(tài)和動態(tài)存儲管理
基于云(或不基于云)：可以在裸機(jī)服務(wù)器、活來自多個供應(yīng)商的 hypervisor 和大多數(shù) IaaS 云提供商上部署 OpenShift 容器平臺。
企業(yè)級：Red Hat 支持 OpenShift、選定的容器映像和應(yīng)用程序運(yùn)行時。可信的第三方容器映像、運(yùn)行時和應(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收集關(guān)于應(yīng)用程序的度量和運(yùn)行時信息，并幫助不斷優(yōu)化性能。
其他特性：OpenShift 支持微服務(wù)體系結(jié)構(gòu)，OpenShift 的本地特性足以支持 DevOps 流程，很容易與標(biāo)準(zhǔn)和定制的持續(xù)集成/持續(xù)部署工具集成。
簡述 OpenShift projects 及其作用？
OpenShift 管理 projects 和 users。

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

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

簡述 OpenShift 高可用的實(shí)現(xiàn)？
OpenShift 平臺集群的高可用性(HA)有兩個不同的方面：

OpenShift 基礎(chǔ)設(shè)施本身的 HA(即主機(jī))；以及在 OpenShift 集群中運(yùn)行的應(yīng)用程序的 HA。

默認(rèn)情況下，OpenShift 為 master 節(jié)點(diǎn)提供了完全支持的本機(jī) HA 機(jī)制。

對于應(yīng)用程序或“pods”，如果 pod 因任何原因丟失，Kubernetes 將調(diào)度另一個副本，將其連接到服務(wù)層和持久存儲。

如果整個節(jié)點(diǎn)丟失，Kubernetes 會為它所有的 pod 安排替換節(jié)點(diǎn)，最終所有的應(yīng)用程序都會重新可用。pod 中的應(yīng)用程序負(fù)責(zé)它們自己的狀態(tài)，因此它們需要自己維護(hù)應(yīng)用程序狀態(tài)(如 HTTP 會話復(fù)制或數(shù)據(jù)庫復(fù)制)。

簡述 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 容器平臺使用了軟件定義的網(wǎng)絡(luò)(SDN)方法。

軟件定義的網(wǎng)絡(luò)是一種網(wǎng)絡(luò)模型，它通過幾個網(wǎng)絡(luò)層的抽象來管理網(wǎng)絡(luò)服務(wù)。

SDN 將處理流量的軟件(稱為控制平面)和路由流量的底層機(jī)制(稱為數(shù)據(jù)平面)解耦。SDN 支持控制平面和數(shù)據(jù)平面之間的通信。

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

ovs-subnet：默認(rèn)插件，子網(wǎng)提供了一個 flat pod 網(wǎng)絡(luò)，其中每個 pod 可以與其他 pod 和 service 通信。
ovs-multitenant：該為 pod 和服務(wù)提供了額外的隔離層。當(dāng)使用此插件時，每個 project 接收一個惟一的虛擬網(wǎng)絡(luò) ID (VNID)，該 ID 標(biāo)識來自屬于該 project 的 pod 的流量。通過使用 VNID，來自不同 project 的 pod 不能與其他 project 的 pod 和 service 通信。
ovs-network policy：此插件允許管理員使用 NetworkPolicy 對象定義自己的隔離策略。
cluster network 由 OpenShift SDN 建立和維護(hù)，它使用 Open vSwitch 創(chuàng)建 overlay 網(wǎng)絡(luò)，master 節(jié)點(diǎn)不能通過集群網(wǎng)絡(luò)訪問容器，除非 master 同時也為 node 節(jié)點(diǎn)。

簡述 OpenShift 角色及其作用？
OpenShift 的角色具有不同級別的訪問和策略，包括集群和本地策略。

user 和 group 可以同時與多個 role 關(guān)聯(lián)。

簡述 OpenShift 支持哪些身份驗(yàn)證？
OpenShift 容器平臺支持的其他認(rèn)證類型包括:

Basic Authentication (Remote)：一種通用的后端集成機(jī)制，允許用戶使用針對遠(yuǎn)程標(biāo)識提供者驗(yàn)證的憑據(jù)登錄到 OpenShift 容器平臺。用戶將他們的用戶名和密碼發(fā)送到 OpenShift 容器平臺，OpenShift 平臺通過到服務(wù)器的請求驗(yàn)證這些憑據(jù)，并將憑據(jù)作為基本的 Auth 頭傳遞。這要求用戶在登錄過程中向 OpenShift 容器平臺輸入他們的憑據(jù)。
Request Header Authentication：用戶使用請求頭值(如 X-RemoteUser)登錄到 OpenShift 容器平臺。它通常與身份驗(yàn)證代理結(jié)合使用，身份驗(yàn)證代理對用戶進(jìn)行身份驗(yàn)證，然后通過請求頭值為 OpenShift 容器平臺提供用戶標(biāo)識。
Keystone Authentication：Keystone 是一個 OpenStack 項目，提供標(biāo)識、令牌、目錄和策略服務(wù)。OpenShift 容器平臺與 Keystone 集成，通過配置 OpenStack Keystone v3 服務(wù)器將用戶存儲在內(nèi)部數(shù)據(jù)庫中，從而支持共享身份驗(yàn)證。這種配置允許用戶使用 Keystone 憑證登錄 OpenShift 容器平臺。
LDAP Authentication：用戶使用他們的 LDAP 憑證登錄到 OpenShift 容器平臺。在身份驗(yàn)證期間，LDAP 目錄將搜索與提供的用戶名匹配的條目。如果找到匹配項，則嘗試使用條目的專有名稱(DN)和提供的密碼進(jìn)行簡單綁定。
GitHub Authentication：GitHub 使用 OAuth，它允許與 OpenShift 容器平臺集成使用 OAuth 身份驗(yàn)證來促進(jìn)令牌交換流。這允許用戶使用他們的 GitHub 憑證登錄到 OpenShift 容器平臺。為了防止使用 GitHub 用戶 id 的未授權(quán)用戶登錄到 OpenShift 容器平臺集群，可以將訪問權(quán)限限制在特定的 GitHub 組織中。
簡述什么是中間件？
中間件是一種獨(dú)立的系統(tǒng)軟件或服務(wù)程序，分布式應(yīng)用軟件借助這種軟件在不同的技術(shù)之間共享資源。

通常位于客戶機(jī)/服務(wù)器的操作系統(tǒng)中間，是連接兩個獨(dú)立應(yīng)用程序或獨(dú)立系統(tǒng)的軟件。

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