簡述ETCD及其特點？

etcd 是 CoreOS 團隊發起的開源項目，是一個管理配置信息和服務發現（service discovery）的項目，它的目標是構建一個高可用的分布式鍵值（key-value）數據庫，基于 Go 語言實現。

特點：

簡單：支持 REST 風格的 HTTP+JSON API

安全：支持 HTTPS 方式的訪問

快速：支持并發 1k/s 的寫操作

可靠：支持分布式結構，基于 Raft 的一致性算法，Raft 是一套通過選舉主節點來實現分布式系統一致性的算法。

簡述ETCD適應的場景？

etcd基于其優秀的特點，可廣泛的應用于以下場景：

服務發現(Service Discovery)：服務發現主要解決在同一個分布式集群中的進程或服務，要如何才能找到對方并建立連接。本質上來說，服務發現就是想要了解集群中是否有進程在監聽udp或tcp端口，并且通過名字就可以查找和連接。

消息發布與訂閱：在分布式系統中，最適用的一種組件間通信方式就是消息發布與訂閱。即構建一個配置共享中心，數據提供者在這個配置中心發布消息，而消息使用者則訂閱他們關心的主題，一旦主題有消息發布，就會實時通知訂閱者。通過這種方式可以做到分布式系統配置的集中式管理與動態更新。 應用中用到的一些配置信息放到etcd上進行集中管理。

負載均衡：在分布式系統中，為了保證服務的高可用以及數據的一致性，通常都會把數據和服務部署多份，以此達到對等服務，即使其中的某一個服務失效了，也不影響使用。etcd本身分布式架構存儲的信息訪問支持負載均衡。etcd集群化以后，每個etcd的核心節點都可以處理用戶的請求。所以，把數據量小但是訪問頻繁的消息數據直接存儲到etcd中也可以實現負載均衡的效果。

分布式通知與協調：與消息發布和訂閱類似，都用到了etcd中的Watcher機制，通過注冊與異步通知機制，實現分布式環境下不同系統之間的通知與協調，從而對數據變更做到實時處理。

分布式鎖：因為etcd使用Raft算法保持了數據的強一致性，某次操作存儲到集群中的值必然是全局一致的，所以很容易實現分布式鎖。鎖服務有兩種使用方式，一是保持獨占，二是控制時序。

集群監控與Leader競選：通過etcd來進行監控實現起來非常簡單并且實時性強。

簡述HAProxy及其特性？

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

HAProxy的主要特性有：

可靠性和穩定性非常好，可以與硬件級的F5負載均衡設備相媲美；

最高可以同時維護40000-50000個并發連接，單位時間內處理的最大請求數為20000個，最大處理能力可達10Git/s；

支持多達8種負載均衡算法，同時也支持會話保持；

支持虛機主機功能，從而實現web負載均衡更加靈活；

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

擁有強大的ACL支持，用于訪問控制；

其獨特的彈性二叉樹數據結構，使數據結構的復雜性上升到了0(1)，即數據的查尋速度不會隨著數據條目的增加而速度有所下降；

支持客戶端的keepalive功能，減少客戶端與haproxy的多次三次握手導致資源浪費，讓多個請求在一個tcp連接中完成；

支持TCP加速，零復制功能，類似于mmap機制；

支持響應池（response buffering）；

支持RDP協議；

基于源的粘性，類似nginx的ip_hash功能，把來自同一客戶端的請求在一定時間內始終調度到上游的同一服務器；

更好統計數據接口，其web接口顯示后端集群中各個服務器的接收、發送、拒絕、錯誤等數據的統計信息；

詳細的健康狀態檢測，web接口中有關于對上游服務器的健康檢測狀態，并提供了一定的管理功能；

基于流量的健康評估機制；

基于http認證；

基于命令行的管理接口；

日志分析器，可對日志進行分析。

簡述HAProxy常見的負載均衡策略？

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

roundrobin：表示簡單的輪詢。

static-rr：表示根據權重。

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

source：表示根據請求的源IP，類似Nginx的IP_hash機制。

ri：表示根據請求的URI。

rl_param：表示根據HTTP請求頭來鎖定每一次HTTP請求。

rdp-cookie(name)：表示根據據cookie(name)來鎖定并哈希每一次TCP請求。

簡述負載均衡四層和七層的區別？

四層負載均衡器也稱為4層交換機，主要通過分析IP層及TCP/UDP層的流量實現基于IP加端口的負載均衡，如常見的LVS、F5等；

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

簡述LVS、Nginx、HAproxy的什么異同？

相同：
三者都是軟件負載均衡產品。

區別：

LVS基于Linux操作系統實現軟負載均衡，而HAProxy和Nginx是基于第三方應用實現的軟負載均衡；

LVS是可實現4層的IP負載均衡技術，無法實現基于目錄、URL的轉發。而HAProxy和Nginx都可以實現4層和7層技術，HAProxy可提供TCP和HTTP應用的負載均衡綜合解決方案；

LVS因為工作在ISO模型的第四層，其狀態監測功能單一，而HAProxy在狀監測方面功能更豐富、強大，可支持端口、URL、腳本等多種狀態檢測方式；

HAProxy功能強大，但整體性能低于4層模式的LVS負載均衡。

Nginx主要用于Web服務器或緩存服務器。

簡述Heartbeat？

Heartbeat是Linux-HA項目中的一個組件，它提供了心跳檢測和資源接管、集群中服務的監測、失效切換等功能。heartbeat最核心的功能包括兩個部分，心跳監測和資源接管。心跳監測可以通過網絡鏈路和串口進行，而且支持冗余鏈路，它們之間相互發送報文來告訴對方自己當前的狀態，如果在指定的時間內未收到對方發送的報文，那么就認為對方失效，這時需啟動資源接管模塊來接管運行在對方主機上的資源或者服務。

簡述Keepalived及其工作原理？

Keepalived 是一個基于VRRP協議來實現的LVS服務高可用方案，可以解決靜態路由出現的單點故障問題。

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

簡述Keepalived體系主要模塊及其作用？

keepalived體系架構中主要有三個模塊，分別是core、check和vrrp。

core模塊為keepalived的核心，負責主進程的啟動、維護及全局配置文件的加載和解析。

vrrp模塊是來實現VRRP協議的。

check負責健康檢查，常見的方式有端口檢查及URL檢查。

簡述Keepalived如何通過健康檢查來保證高可用？

Keepalived工作在TCP/IP模型的第三、四和五層，即網絡層、傳輸層和應用層。

網絡層，Keepalived采用ICMP協議向服務器集群中的每個節點發送一個ICMP的數據包，如果某個節點沒有返回響應數據包，則認為此節點發生了故障，Keepalived將報告次節點失效，并從服務器集群中剔除故障節點。

傳輸層，Keepalived利用TCP的端口連接和掃描技術來判斷集群節點是否正常。如常見的web服務默認端口80，ssh默認端口22等。Keepalived一旦在傳輸層探測到相應端口沒用響應數據返回，則認為此端口發生異常，從而將此端口對應的節點從服務器集群中剔除。

應用層，可以運行FTP、telnet、smtp、dns等各種不同類型的高層協議，Keepalived的運行方式也更加全面化和復雜化，用戶可以通過自定義Keepalived的工作方式，來設定監測各種程序或服務是否正常，若監測結果與設定的正常結果不一致，將此服務對應的節點從服務器集群中剔除。

Keepalived通過完整的健康檢查機制，保證集群中的所有節點均有效從而實現高可用。

簡述LVS的概念及其作用？

LVS是linux virtual server的簡寫linux虛擬服務器，是一個虛擬的服務器集群系統，可以在unix/linux平臺下實現負載均衡集群功能。

LVS的主要作用是：通過LVS提供的負載均衡技術實現一個高性能、高可用的服務器群集。因此LVS主要可以實現：

把單臺計算機無法承受的大規模的并發訪問或數據流量分擔到多臺節點設備上分別處理，減少用戶等待響應的時間，提升用戶體驗。

單個重負載的運算分擔到多臺節點設備上做并行處理，每個節點設備處理結束后，將結果匯總，返回給用戶，系統處理能力得到大幅度提高。

7*24小時的服務保證，任意一個或多個設備節點設備宕機，不能影響到業務。在負載均衡集群中，所有計算機節點都應該提供相同的服務，集群負載均衡獲取所有對該服務的如站請求。

簡述LVS的工作模式及其工作過程？

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

NAT模式（VS-NAT）

原理：首先負載均衡器接收到客戶的請求數據包時，根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后負載均衡器就把客戶端發送的請求數據包的目標IP地址及端口改成后端真實服務器的IP地址（RIP）。真實服務器響應完請求后，查看默認路由，把響應后的數據包發送給負載均衡器，負載均衡器在接收到響應包后，把包的源地址改成虛擬地址（VIP）然后發送回給客戶端。

優點：集群中的服務器可以使用任何支持TCP/IP的操作系統，只要負載均衡器有一個合法的IP地址。

缺點：擴展性有限，當服務器節點增長過多時，由于所有的請求和應答都需要經過負載均衡器，因此負載均衡器將成為整個系統的瓶頸。

IP隧道模式（VS-TUN）

原理：首先負載均衡器接收到客戶的請求數據包時，根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后負載均衡器就把客戶端發送的請求報文封裝一層IP隧道（T-IP）轉發到真實服務器（RS）。真實服務器響應完請求后，查看默認路由，把響應后的數據包直接發送給客戶端，不需要經過負載均衡器。

優點：負載均衡器只負責將請求包分發給后端節點服務器，而RS將應答包直接發給用戶。所以，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，也能處理很巨大的請求量。

缺點：隧道模式的RS節點需要合法IP，這種方式需要所有的服務器支持“IP Tunneling”。

直接路由模式（VS-DR）

原理：首先負載均衡器接收到客戶的請求數據包時，根據調度算法決定將請求發送給哪個后端的真實服務器（RS）。然后負載均衡器就把客戶端發送的請求數據包的目標MAC地址改成后端真實服務器的MAC地址（R-MAC）。真實服務器響應完請求后，查看默認路由，把響應后的數據包直接發送給客戶端，不需要經過負載均衡器。

優點：負載均衡器只負責將請求包分發給后端節點服務器，而RS將應答包直接發給用戶。所以，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，也能處理很巨大的請求量。

缺點：需要負載均衡器與真實服務器RS都有一塊網卡連接到同一物理網段上，必須在同一個局域網環境。

簡述LVS調度器常見算法（均衡策略）？

LVS調度器用的調度方法基本分為兩類：

固定調度算法：rr，wrr，dh，sh

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

wrr：加權輪訓調度，依據不同RS的權值分配任務。權值較高的RS將優先獲得任務，并且分配到的連接數將比權值低的RS更多。相同權值的RS得到相同數目的連接數。

dh：目的地址哈希調度（destination hashing）以目的地址為關鍵字查找一個靜態hash表來獲得所需RS。

sh：源地址哈希調度（source hashing）以源地址為關鍵字查找一個靜態hash表來獲得需要的RS。

動態調度算法：wlc，lc，lblc，lblcr

wlc：加權最小連接數調度，假設各臺RS的權值依次為Wi，當前tcp連接數依次為Ti，依次去Ti/Wi為最小的RS作為下一個分配的RS。

lc：最小連接數調度（least-connection），IPVS表存儲了所有活動的連接。LB會比較將連接請求發送到當前連接最少的RS。

lblc：基于地址的最小連接數調度（locality-based least-connection）：將來自同一個目的地址的請求分配給同一臺RS，此時這臺服務器是尚未滿負荷的。否則就將這個請求分配給連接數最小的RS，并以它作為下一次分配的首先考慮。

簡述LVS、Nginx、HAProxy各自優缺點？

Nginx的優點：

工作在網絡的7層之上，可以針對http應用做一些分流的策略，比如針對域名、目錄結構。Nginx正則規則比HAProxy更為強大和靈活。

Nginx對網絡穩定性的依賴非常小，理論上能ping通就就能進行負載功能，LVS對網絡穩定性依賴比較大，穩定要求相對更高。

Nginx安裝和配置、測試比較簡單、方便，有清晰的日志用于排查和管理，LVS的配置、測試就要花比較長的時間了。

可以承擔高負載壓力且穩定，一般能支撐幾萬次的并發量，負載度比LVS相對小些。

Nginx可以通過端口檢測到服務器內部的故障，比如根據服務器處理網頁返回的狀態碼、超時等等。

Nginx不僅僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。

Nginx作為Web反向加速緩存越來越成熟了，速度比傳統的Squid服務器更快，很多場景下都將其作為反向代理加速器。

Nginx作為靜態網頁和圖片服務器，這方面的性能非常優秀，同時第三方模塊也很多。

Nginx的缺點：

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

對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。

不支持Session的直接保持，需要通過ip_hash來解決。

LVS的優點：

抗負載能力強、是工作在網絡4層之上僅作分發之用，沒有流量的產生。因此負載均衡軟件里的性能最強的，對內存和cpu資源消耗比較低。

LVS工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案。

無流量，LVS只分發請求，而流量并不從它本身出去，這點保證了均衡器IO的性能不會收到大流量的影響。

應用范圍較廣，因為LVS工作在4層，所以它幾乎可對所有應用做負載均衡，包括http、數據庫等。

LVS的缺點是：

軟件本身不支持正則表達式處理，不能做動靜分離。相對來說，Nginx/HAProxy+Keepalived則具有明顯的優勢。

如果是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較復雜了。相對來說，Nginx/HAProxy+Keepalived就簡單多了。

HAProxy的優點：

HAProxy也是支持虛擬主機的。

HAProxy的優點能夠補充Nginx的一些缺點，比如支持Session的保持，Cookie的引導，同時支持通過獲取指定的url來檢測后端服務器的狀態。

HAProxy跟LVS類似，本身就只是一款負載均衡軟件，單純從效率上來講HAProxy會比Nginx有更出色的負載均衡速度，在并發處理上也是優于Nginx的。

HAProxy支持TCP協議的負載均衡轉發。

簡述代理服務器的概念及其作用？

代理服務器是一個位于客戶端和原始（資源）服務器之間的服務器，為了從原始服務器取得內容，客戶端向代理服務器發送一個請求并指定目標原始服務器，然后代理服務器向原始服務器轉交請求并將獲得的內容返回給客戶端。

其主要作用有：

資源獲取：代替客戶端實現從原始服務器的資源獲取；

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

緩存作用：代理服務器保存從原始服務器所獲取的資源，從而實現客戶端快速的獲取；

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

簡述高可用集群可通過哪兩個維度衡量高可用性，各自含義是什么？

RTO（Recovery Time Objective）：RTO指服務恢復的時間，最佳的情況是 0，即服務立即恢復；最壞是無窮大，即服務永遠無法恢復；

RPO（Recovery Point Objective）：RPO 指指當災難發生時允許丟失的數據量，0 意味著使用同步的數據，大于 0 意味著有數據丟失，如“RPO=1 d”指恢復時使用一天前的數據，那么一天之內的數據就丟失了。因此，恢復的最佳情況是 RTO = RPO = 0，幾乎無法實現。

簡述什么是CAP理論？

CAP理論指出了在分布式系統中需要滿足的三個條件，主要包括：

Consistency（一致性）：所有節點在同一時間具有相同的數據；

Availability（可用性）：保證每個請求不管成功或者失敗都有響應；

Partition tolerance（分區容錯性）：系統中任意信息的丟失或失敗不影響系統的繼續運行。

CAP 理論的核心是：一個分布式系統不可能同時很好的滿足一致性，可用性和分區容錯性這三個需求，最多只能同時較好的滿足兩個。

簡述什么是ACID理論？

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

一致性(Consistency)：事務執行前、后數據庫狀態均一致；

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

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

簡述什么是Kubernetes？

Kubernetes是一個全新的基于容器技術的分布式系統支撐平臺。是Google開源的容器集群管理系統（谷歌內部:Borg）。在Docker技術的基礎上，為容器化的應用提供部署運行、資源調度、服務發現和動態伸縮等一系列完整功能，提高了大規模容器集群管理的便捷性。并且具有完備的集群管理能力，多層次的安全防護和準入機制、多租戶應用支撐能力、透明的服務注冊和發現機制、內建智能負載均衡器、強大的故障發現和自我修復能力、服務滾動升級和在線擴容能力、可擴展的資源自動調度機制以及多粒度的資源配額管理能力。

簡述Kubernetes和Docker的關系？

Docker 提供容器的生命周期管理和，Docker 鏡像構建運行時容器。它的主要優點是將將軟件/應用程序運行所需的設置和依賴項打包到一個容器中，從而實現了可移植性等優點。

Kubernetes 用于關聯和編排在多個主機上運行的容器。

簡述Kubernetes中什么是Minikube、Kubectl、Kubelet？

Minikube?是一種可以在本地輕松運行一個單節點 Kubernetes 群集的工具。

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

Kubelet?是一個代理服務，它在每個節點上運行，并使從服務器與主服務器通信。

簡述Kubernetes常見的部署方式？

常見的Kubernetes部署方式有：

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

二進制：

minikube：在本地輕松運行一個單節點 Kubernetes 群集的工具。

簡述Kubernetes如何實現集群管理？

在集群管理方面，Kubernetes將集群中的機器劃分為一個Master節點和一群工作節點Node。其中，在Master節點運行著集群管理相關的一組進程kube-apiserver、kube-controller-manager和kube-scheduler，這些進程實現了整個集群的資源管理、Pod調度、彈性伸縮、安全控制、系統監控和糾錯等管理能力，并且都是全自動完成的。

簡述Kubernetes的優勢、適應場景及其特點？

Kubernetes作為一個完備的分布式系統支撐平臺，其主要優勢：

容器編排

輕量級

開源

彈性伸縮

負載均衡

Kubernetes常見場景：

快速部署應用

快速擴展應用

無縫對接新的應用功能

節省資源，優化硬件資源的使用

Kubernetes相關特點：

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

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

自動化: 自動部署、自動重啟、自動復制、自動伸縮/擴展。

簡述Kubernetes的缺點或當前的不足之處？

Kubernetes當前存在的缺點（不足）如下：

安裝過程和配置相對困難復雜。

管理服務相對繁瑣。

運行和編譯需要很多時間。

它比其他替代品更昂貴。

對于簡單的應用程序來說，可能不需要涉及Kubernetes即可滿足。

簡述Kubernetes相關基礎概念？

master：k8s集群的管理節點，負責管理集群，提供集群的資源數據訪問入口。擁有Etcd存儲服務（可選），運行Api Server進程，Controller Manager服務進程及Scheduler服務進程。

node（worker）：Node（worker）是Kubernetes集群架構中運行Pod的服務節點，是Kubernetes集群操作的單元，用來承載被分配Pod的運行，是Pod運行的宿主機。運行docker eninge服務，守護進程kunelet及負載均衡器kube-proxy。

pod：運行于Node節點上，若干相關容器的組合。Pod內包含的容器運行在同一宿主機上，使用相同的網絡命名空間、IP地址和端口，能夠通過localhost進行通信。Pod是Kurbernetes進行創建、調度和管理的最小單位，它提供了比容器更高層次的抽象，使得部署和管理更加靈活。一個Pod可以包含一個容器或者多個相關容器。

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

Replication Controller：Replication Controller用來管理Pod的副本，保證集群中存在指定數量的Pod副本。集群中副本的數量大于指定數量，則會停止指定數量之外的多余容器數量。反之，則會啟動少于指定數量個數的容器，保證數量不變。Replication Controller是實現彈性伸縮、動態擴容和滾動升級的核心。

Deployment：Deployment在內部使用了RS來實現目的，Deployment相當于RC的一次升級，其最大的特色為可以隨時獲知當前Pod的部署進度。

HPA（Horizontal Pod Autoscaler）：Pod的橫向自動擴容，也是Kubernetes的一種資源，通過追蹤分析RC控制的所有Pod目標的負載變化情況，來確定是否需要針對性的調整Pod副本數量。

Service：Service定義了Pod的邏輯集合和訪問該集合的策略，是真實服務的抽象。Service提供了一個統一的服務訪問入口以及服務代理和發現機制，關聯多個相同Label的Pod，用戶不需要了解后臺Pod是如何運行。

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

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

簡述Kubernetes集群相關組件？

Kubernetes Master控制組件，調度管理整個系統（集群），包含如下組件:

Kubernetes API Server：作為Kubernetes系統的入口，其封裝了核心對象的增刪改查操作，以RESTful API接口方式提供給外部客戶和內部組件調用，集群內各個功能模塊之間數據交互和通信的中心樞紐。

Kubernetes Scheduler：為新建立的Pod進行節點(node)選擇(即分配機器)，負責集群的資源調度。

Kubernetes Controller：負責執行各種控制器，目前已經提供了很多控制器來保證Kubernetes的正常運行。

Replication Controller：管理維護Replication Controller，關聯Replication Controller和Pod，保證Replication Controller定義的副本數量與實際運行Pod數量一致。

Node Controller：管理維護Node，定期檢查Node的健康狀態，標識出(失效|未失效)的Node節點。

Namespace Controller：管理維護Namespace，定期清理無效的Namespace，包括Namesapce下的API對象，比如Pod、Service等。

Service Controller：管理維護Service，提供負載以及服務代理。

EndPoints Controller：管理維護Endpoints，關聯Service和Pod，創建Endpoints為Service的后端，當Pod發生變化時，實時更新Endpoints。

Service Account Controller：管理維護Service Account，為每個Namespace創建默認的Service Account，同時為Service Account創建Service Account Secret。

Persistent Volume Controller：管理維護Persistent Volume和Persistent Volume Claim，為新的Persistent Volume Claim分配Persistent Volume進行綁定，為釋放的Persistent Volume執行清理回收。

Daemon Set Controller：管理維護Daemon Set，負責創建Daemon Pod，保證指定的Node上正常的運行Daemon Pod。

Deployment Controller：管理維護Deployment，關聯Deployment和Replication Controller，保證運行指定數量的Pod。當Deployment更新時，控制實現Replication Controller和Pod的更新。

Job Controller：管理維護Job，為Jod創建一次性任務Pod，保證完成Job指定完成的任務數目

Pod Autoscaler Controller：實現Pod的自動伸縮，定時獲取監控數據，進行策略匹配，當滿足條件時執行Pod的伸縮動作。

簡述Kubernetes RC的機制？

Replication Controller用來管理Pod的副本，保證集群中存在指定數量的Pod副本。當定義了RC并提交至Kubernetes集群中之后，Master節點上的Controller Manager組件獲悉，并同時巡檢系統中當前存活的目標Pod，并確保目標Pod實例的數量剛好等于此RC的期望值，若存在過多的Pod副本在運行，系統會停止一些Pod，反之則自動創建一些Pod。

簡述Kubernetes Replica Set 和 Replication Controller 之間有什么區別？

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

簡述kube-proxy作用？

kube-proxy 運行在所有節點上，它監聽 apiserver 中 service 和 endpoint 的變化情況，創建路由規則以提供服務 IP 和負載均衡功能。簡單理解此進程是Service的透明代理兼負載均衡器，其核心功能是將到某個Service的訪問請求轉發到后端的多個Pod實例上。

簡述kube-proxy iptables原理？

Kubernetes從1.2版本開始，將iptables作為kube-proxy的默認模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通過API Server的Watch接口實時跟蹤Service與Endpoint的變更信息，并更新對應的iptables規則，Client的請求流量則通過iptables的NAT機制“直接路由”到目標Pod。

簡述kube-proxy ipvs原理？

IPVS在Kubernetes1.11中升級為GA穩定版。IPVS則專門用于高性能負載均衡，并使用更高效的數據結構（Hash表），允許幾乎無限的規模擴張，因此被kube-proxy采納為最新模式。

在IPVS模式下，使用iptables的擴展ipset，而不是直接調用iptables來生成規則鏈。iptables規則鏈是一個線性的數據結構，ipset則引入了帶索引的數據結構，因此當規則很多時，也可以很高效地查找和匹配。

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

簡述kube-proxy ipvs和iptables的異同？

iptables與IPVS都是基于Netfilter實現的，但因為定位不同，二者有著本質的差別：iptables是為防火墻而設計的；IPVS則專門用于高性能負載均衡，并使用更高效的數據結構（Hash表），允許幾乎無限的規模擴張。

與iptables相比，IPVS擁有以下明顯優勢：

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

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

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

4、可以動態修改ipset的集合，即使iptables的規則正在使用這個集合。

簡述Kubernetes中什么是靜態Pod？

靜態pod是由kubelet進行管理的僅存在于特定Node的Pod上，他們不能通過API Server進行管理，無法與ReplicationController、Deployment或者DaemonSet進行關聯，并且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行創建，并且總是在kubelet所在的Node上運行。

簡述Kubernetes中Pod可能位于的狀態？

Pending：API Server已經創建該Pod，且Pod內還有一個或多個容器的鏡像沒有創建，包括正在下載鏡像的過程。

Running：Pod內所有容器均已創建，且至少有一個容器處于運行狀態、正在啟動狀態或正在重啟狀態。

Succeeded：Pod內所有容器均成功執行退出，且不會重啟。

Failed：Pod內所有容器均已退出，但至少有一個容器退出為失敗狀態。

Unknown：由于某種原因無法獲取該Pod狀態，可能由于網絡通信不暢導致。

簡述Kubernetes創建一個Pod的主要流程？

Kubernetes中創建一個Pod涉及多個組件之間聯動，主要流程如下：

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

2、Apiserver收到指令后，通知給controller-manager創建一個資源對象。

3、Controller-manager通過api-server將pod的配置信息存儲到ETCD數據中心中。

4、Kube-scheduler檢測到pod信息會開始調度預選，會先過濾掉不符合Pod資源配置要求的節點，然后開始調度調優，主要是挑選出更適合運行pod的節點，然后將pod的資源配置單發送到node節點上的kubelet組件上。

5、Kubelet根據scheduler發來的資源配置單運行pod，運行成功后，將pod的運行信息返回給scheduler，scheduler將返回的pod運行狀況的信息存儲到etcd數據中心。

簡述Kubernetes中Pod的重啟策略？

Pod重啟策略（RestartPolicy）應用于Pod內的所有容器，并且僅在Pod所處的Node上由kubelet進行判斷和重啟操作。當某個容器異常退出或者健康檢查失敗時，kubelet將根據RestartPolicy的設置來進行相應操作。

Pod的重啟策略包括Always、OnFailure和Never，默認值為Always。

Always：當容器失效時，由kubelet自動重啟該容器；

OnFailure：當容器終止運行且退出碼不為0時，由kubelet自動重啟該容器；

Never：不論容器運行狀態如何，kubelet都不會重啟該容器。

同時Pod的重啟策略與控制方式關聯，當前可用于管理Pod的控制器包括ReplicationController、Job、DaemonSet及直接管理kubelet管理（靜態Pod）。

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

RC和DaemonSet：必須設置為Always，需要保證該容器持續運行；

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

kubelet：在Pod失效時重啟，不論將RestartPolicy設置為何值，也不會對Pod進行健康檢查。

簡述Kubernetes中Pod的健康檢查方式？

對Pod的健康檢查可以通過兩類探針來檢查：LivenessProbe和ReadinessProbe。

LivenessProbe探針：用于判斷容器是否存活（running狀態），如果LivenessProbe探針探測到容器不健康，則kubelet將殺掉該容器，并根據容器的重啟策略做相應處理。若一個容器不包含LivenessProbe探針，kubelet認為該容器的LivenessProbe探針返回值用于是“Success”。

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

startupProbe探針：啟動檢查機制，應用一些啟動緩慢的業務，避免業務長時間啟動而被上面兩類探針kill掉。

簡述Kubernetes Pod的LivenessProbe探針的常見方式？

kubelet定期執行LivenessProbe探針來診斷容器的健康狀態，通常有以下三種方式：

ExecAction：在容器內執行一個命令，若返回碼為0，則表明容器健康。

TCPSocketAction：通過容器的IP地址和端口號執行TCP檢查，若能建立TCP連接，則表明容器健康。

HTTPGetAction：通過容器的IP地址、端口號及路徑調用HTTP Get方法，若響應的狀態碼大于等于200且小于400，則表明容器健康。

簡述Kubernetes Pod的常見調度方式？

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

Deployment或RC：該調度策略主要功能就是自動部署一個容器應用的多份副本，以及持續監控副本的數量，在集群內始終維持用戶指定的副本數量。

NodeSelector：定向調度，當需要手動指定將Pod調度到特定Node上，可以通過Node的標簽（Label）和Pod的nodeSelector屬性相匹配。

NodeAffinity親和性調度：親和性調度機制極大的擴展了Pod的調度能力，目前有兩種節點親和力表達：

requiredDuringSchedulingIgnoredDuringExecution：硬規則，必須滿足指定的規則，調度器才可以調度Pod至Node上（類似nodeSelector，語法不同）。

preferredDuringSchedulingIgnoredDuringExecution：軟規則，優先調度至滿足的Node的節點，但不強求，多個優先級規則還可以設置權重值。

Taints和Tolerations（污點和容忍）：

Taint：使Node拒絕特定Pod運行；

Toleration：為Pod的屬性，表示Pod能容忍（運行）標注了Taint的Node。

簡述Kubernetes初始化容器（init container）？

init container的運行方式與應用容器不同，它們必須先于應用容器執行完成，當設置了多個init container時，將按順序逐個運行，并且只有前一個init container運行成功后才能運行后一個init container。當所有init container都成功運行后，Kubernetes才會初始化Pod的各種信息，并開始創建和運行應用容器。

簡述Kubernetes deployment升級過程？

初始創建Deployment時，系統創建了一個ReplicaSet，并按用戶的需求創建了對應數量的Pod副本。

當更新Deployment時，系統創建了一個新的ReplicaSet，并將其副本數量擴展到1，然后將舊ReplicaSet縮減為2。

之后，系統繼續按照相同的更新策略對新舊兩個ReplicaSet進行逐個調整。

最后，新的ReplicaSet運行了對應個新版本Pod副本，舊的ReplicaSet副本數量則縮減為0。

簡述Kubernetes deployment升級策略？

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

Recreate：設置spec.strategy.type=Recreate，表示Deployment在更新Pod時，會先殺掉所有正在運行的Pod，然后創建新的Pod。

RollingUpdate：設置spec.strategy.type=RollingUpdate，表示Deployment會以滾動更新的方式來逐個更新Pod。同時，可以通過設置spec.strategy.rollingUpdate下的兩個參數（maxUnavailable和maxSurge）來控制滾動更新的過程。

簡述Kubernetes DaemonSet類型的資源特性？

DaemonSet資源對象會在每個Kubernetes集群中的節點上運行，并且每個節點只能運行一個pod，這是它和deployment資源對象的最大也是唯一的區別。因此，在定義yaml文件中，不支持定義replicas。

它的一般使用場景如下：

在去做每個節點的日志收集工作。

監控每個節點的的運行狀態。

簡述Kubernetes自動擴容機制？

Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器實現基于CPU使用率進行自動Pod擴縮容的功能。HPA控制器周期性地監測目標Pod的資源性能指標，并與HPA資源對象中的擴縮容條件進行對比，在滿足條件時對Pod副本數量進行調整。

HPA原理

Kubernetes中的某個Metrics Server（Heapster或自定義Metrics Server）持續采集所有Pod副本的指標數據。HPA控制器通過Metrics Server的API（Heapster的API或聚合API）獲取這些數據，基于用戶定義的擴縮容規則進行計算，得到目標Pod副本數量。

當目標Pod副本數量與當前副本數量不同時，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）發起scale操作，調整Pod的副本數量，完成擴縮容操作。

簡述Kubernetes Service類型？

通過創建Service，可以為一組具有相同功能的容器應用提供一個統一的入口地址，并且將請求負載分發到后端的各個容器應用上。 其主要類型有：

ClusterIP：虛擬的服務IP地址，該地址用于Kubernetes集群內部的Pod訪問，在Node上kube-proxy通過設置的iptables規則進行轉發；

NodePort：使用宿主機的端口，使能夠訪問各Node的外部客戶端通過Node的IP地址和端口號就能訪問服務；

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

簡述Kubernetes Service分發后端的策略？

Service負載分發的策略有：RoundRobin和SessionAffinity

RoundRobin：默認為輪詢模式，即輪詢將請求轉發到后端的各個Pod上。

SessionAffinity：基于客戶端IP地址進行會話保持的模式，即第1次將某個客戶端發起的請求轉發到后端的某個Pod上，之后從相同的客戶端發起的請求都將被轉發到后端相同的Pod上。

簡述Kubernetes Headless Service？

在某些應用場景中，若需要人為指定負載均衡器，不使用Service提供的默認負載均衡的功能，或者應用程序希望知道屬于同組服務的其他實例。Kubernetes提供了Headless Service來實現這種功能，即不為Service設置ClusterIP（入口IP地址），僅通過Label Selector將后端的Pod列表返回給調用的客戶端。

簡述Kubernetes外部如何訪問集群內的服務？

對于Kubernetes，集群外的客戶端默認情況，無法通過Pod的IP地址或者Service的虛擬IP地址:虛擬端口號進行訪問。通常可以通過以下方式進行訪問Kubernetes集群內的服務：

映射Pod到物理機：將Pod端口號映射到宿主機，即在Pod中采用hostPort方式，以使客戶端應用能夠通過物理機訪問容器應用。

映射Service到物理機：將Service端口號映射到宿主機，即在Service中采用nodePort方式，以使客戶端應用能夠通過物理機訪問容器應用。

映射Sercie到LoadBalancer：通過設置LoadBalancer映射到云服務商提供的LoadBalancer地址。這種用法僅用于在公有云服務提供商的云平臺上設置Service的場景。

簡述Kubernetes ingress？

Kubernetes的Ingress資源對象，用于將不同URL的訪問請求轉發到后端不同的Service，以實現HTTP層的業務路由機制。

Kubernetes使用了Ingress策略和Ingress Controller，兩者結合并實現了一個完整的Ingress負載均衡器。使用Ingress進行負載分發時，Ingress Controller基于Ingress規則將客戶端請求直接轉發到Service對應的后端Endpoint（Pod）上，從而跳過kube-proxy的轉發功能，kube-proxy不再起作用，全過程為：ingress controller + ingress 規則 ----> services。

同時當Ingress Controller提供的是對外服務，則實際上實現的是邊緣路由器的功能。

簡述Kubernetes鏡像的下載策略？

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

Always：鏡像標簽為latest時，總是從指定的倉庫中獲取鏡像。

Never：禁止從倉庫中下載鏡像，也就是說只能使用本地鏡像。

IfNotPresent：僅當本地沒有對應鏡像時，才從目標倉庫中下載。
默認的鏡像下載策略是：當鏡像標簽是latest時，默認策略是Always；當鏡像標簽是自定義時（也就是標簽不是latest），那么默認策略是IfNotPresent。

簡述Kubernetes的負載均衡器？

負載均衡器是暴露服務的最常見和標準方式之一。

根據工作環境使用兩種類型的負載均衡器，即內部負載均衡器或外部負載均衡器。內部負載均衡器自動平衡負載并使用所需配置分配容器，而外部負載均衡器將流量從外部負載引導至后端容器。

簡述Kubernetes各模塊如何與API Server通信？

Kubernetes API Server作為集群的核心，負責集群各功能模塊之間的通信。集群內的各個功能模塊通過API Server將信息存入etcd，當需要獲取和操作這些數據時，則通過API Server提供的REST接口（用GET、LIST或WATCH方法）來實現，從而實現各模塊之間的信息交互。

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

如kube-controller-manager進程與API Server的交互：kube-controller-manager中的Node Controller模塊通過API Server提供的Watch接口實時監控Node的信息，并做相應處理。

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

簡述Kubernetes Scheduler作用及實現原理？

Kubernetes Scheduler是負責Pod調度的重要功能模塊，Kubernetes Scheduler在整個系統中承擔了“承上啟下”的重要功能，“承上”是指它負責接收Controller Manager創建的新Pod，為其調度至目標Node；“啟下”是指調度完成后，目標Node上的kubelet服務進程接管后繼工作，負責Pod接下來生命周期。

Kubernetes Scheduler的作用是將待調度的Pod（API新創建的Pod、Controller Manager為補足副本而創建的Pod等）按照特定的調度算法和調度策略綁定（Binding）到集群中某個合適的Node上，并將綁定信息寫入etcd中。

在整個調度過程中涉及三個對象，分別是待調度Pod列表、可用Node列表，以及調度算法和策略。

Kubernetes Scheduler通過調度算法調度為待調度Pod列表中的每個Pod從Node列表中選擇一個最適合的Node來實現Pod的調度。隨后，目標節點上的kubelet通過API Server監聽到Kubernetes Scheduler產生的Pod綁定事件，然后獲取對應的Pod清單，下載Image鏡像并啟動容器。

簡述Kubernetes Scheduler使用哪兩種算法將Pod綁定到worker節點？

Kubernetes Scheduler根據如下兩種調度算法將 Pod 綁定到最合適的工作節點：

預選（Predicates）：輸入是所有節點，輸出是滿足預選條件的節點。kube-scheduler根據預選策略過濾掉不滿足策略的Nodes。如果某節點的資源不足或者不滿足預選策略的條件則無法通過預選。如“Node的label必須與Pod的Selector一致”。

優選（Priorities）：輸入是預選階段篩選出的節點，優選會根據優先策略為通過預選的Nodes進行打分排名，選擇得分最高的Node。例如，資源越富裕、負載越小的Node可能具有越高的排名。

簡述Kubernetes kubelet的作用？

在Kubernetes集群中，在每個Node（又稱Worker）上都會啟動一個kubelet服務進程。該進程用于處理Master下發到本節點的任務，管理Pod及Pod中的容器。每個kubelet進程都會在API Server上注冊節點自身的信息，定期向Master匯報節點資源的使用情況，并通過cAdvisor監控容器和節點資源。

簡述Kubernetes kubelet監控Worker節點資源是使用什么組件來實現的？

kubelet使用cAdvisor對worker節點資源進行監控。在 Kubernetes 系統中，cAdvisor 已被默認集成到 kubelet 組件內，當 kubelet 服務啟動時，它會自動啟動 cAdvisor 服務，然后 cAdvisor 會實時采集所在節點的性能指標及在節點上運行的容器的性能指標。

簡述Kubernetes如何保證集群的安全性？

Kubernetes通過一系列機制來實現集群的安全控制，主要有如下不同的維度：

基礎設施方面：保證容器與其所在宿主機的隔離；

權限方面：

最小權限原則：合理限制所有組件的權限，確保組件只執行它被授權的行為，通過限制單個組件的能力來限制它的權限范圍。

用戶權限：劃分普通用戶和管理員的角色。

集群方面：

API Server的認證授權：Kubernetes集群中所有資源的訪問和變更都是通過Kubernetes API Server來實現的，因此需要建議采用更安全的HTTPS或Token來識別和認證客戶端身份（Authentication），以及隨后訪問權限的授權（Authorization）環節。

API Server的授權管理：通過授權策略來決定一個API調用是否合法。對合法用戶進行授權并且隨后在用戶訪問時進行鑒權，建議采用更安全的RBAC方式來提升集群安全授權。

敏感數據引入Secret機制：對于集群敏感數據建議使用Secret方式進行保護。

AdmissionControl（準入機制）：對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然后執行準入操作，最后對目標對象進行操作。

簡述Kubernetes準入機制？

在對集群進行請求時，每個準入控制代碼都按照一定順序執行。如果有一個準入控制拒絕了此次請求，那么整個請求的結果將會立即返回，并提示用戶相應的error信息。

準入控制（AdmissionControl）準入控制本質上為一段準入代碼，在對kubernetes api的請求過程中，順序為：先經過認證 & 授權，然后執行準入操作，最后對目標對象進行操作。常用組件（控制代碼）如下：

AlwaysAdmit：允許所有請求

AlwaysDeny：禁止所有請求，多用于測試環境。

ServiceAccount：它將serviceAccounts實現了自動化，它會輔助serviceAccount做一些事情，比如如果pod沒有serviceAccount屬性，它會自動添加一個default，并確保pod的serviceAccount始終存在。

LimitRanger：觀察所有的請求，確保沒有違反已經定義好的約束條件，這些條件定義在namespace中LimitRange對象中。

NamespaceExists：觀察所有的請求，如果請求嘗試創建一個不存在的namespace，則這個請求被拒絕。

簡述Kubernetes RBAC及其特點（優勢）？

RBAC是基于角色的訪問控制，是一種基于個人用戶的角色來管理對計算機或網絡資源的訪問的方法。

相對于其他授權模式，RBAC具有如下優勢：

對集群中的資源和非資源權限均有完整的覆蓋。

整個RBAC完全由幾個API對象完成， 同其他API對象一樣， 可以用kubectl或API進行操作。

可以在運行時進行調整，無須重新啟動API Server。

簡述Kubernetes Secret作用？

Secret對象，主要作用是保管私密數據，比如密碼、OAuth Tokens、SSH Keys等信息。將這些私密信息放在Secret對象中比直接放在Pod或Docker Image中更安全，也更便于使用和分發。

簡述Kubernetes Secret有哪些使用方式？

創建完secret之后，可通過如下三種方式使用：

在創建Pod時，通過為Pod指定Service Account來自動使用該Secret。

通過掛載該Secret到Pod來使用它。

在Docker鏡像下載時使用，通過指定Pod的spc.ImagePullSecrets來引用它。

簡述Kubernetes PodSecurityPolicy機制？

Kubernetes PodSecurityPolicy是為了更精細地控制Pod對資源的使用方式以及提升安全策略。在開啟PodSecurityPolicy準入控制器后，Kubernetes默認不允許創建任何Pod，需要創建PodSecurityPolicy策略和相應的RBAC授權策略（Authorizing Policies），Pod才能創建成功。

簡述Kubernetes PodSecurityPolicy機制能實現哪些安全策略？

在PodSecurityPolicy對象中可以設置不同字段來控制Pod運行時的各種安全策略，常見的有：

特權模式：privileged是否允許Pod以特權模式運行。

宿主機資源：控制Pod對宿主機資源的控制，如hostPID：是否允許Pod共享宿主機的進程空間。

用戶和組：設置運行容器的用戶ID（范圍）或組（范圍）。

提升權限：AllowPrivilegeEscalation：設置容器內的子進程是否可以提升權限，通常在設置非root用戶（MustRunAsNonRoot）時進行設置。

SELinux：進行SELinux的相關配置。

簡述Kubernetes網絡模型？

Kubernetes網絡模型中每個Pod都擁有一個獨立的IP地址，并假定所有Pod都在一個可以直接連通的、扁平的網絡空間中。所以不管它們是否運行在同一個Node（宿主機）中，都要求它們可以直接通過對方的IP進行訪問。設計這個原則的原因是，用戶不需要額外考慮如何建立Pod之間的連接，也不需要考慮如何將容器端口映射到主機端口等問題。

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

在Kubernetes的集群里，IP是以Pod為單位進行分配的。一個Pod內部的所有容器共享一個網絡堆棧（相當于一個網絡命名空間，它們的IP地址、網絡設備、配置等都是共享的）。

簡述Kubernetes CNI模型？

CNI提供了一種應用容器的插件化網絡解決方案，定義對容器網絡進行操作和配置的規范，通過插件的形式對CNI接口進行實現。CNI僅關注在創建容器時分配網絡資源，和在銷毀容器時刪除網絡資源。在CNI模型中只涉及兩個概念：容器和網絡。

容器（Container）：是擁有獨立Linux網絡命名空間的環境，例如使用Docker或rkt創建的容器。容器需要擁有自己的Linux網絡命名空間，這是加入網絡的必要條件。

網絡（Network）：表示可以互連的一組實體，這些實體擁有各自獨立、唯一的IP地址，可以是容器、物理機或者其他網絡設備（比如路由器）等。

對容器網絡的設置和操作都通過插件（Plugin）進行具體實現，CNI插件包括兩種類型：CNI Plugin和IPAM（IP Address ?Management）Plugin。CNI Plugin負責為容器配置網絡資源，IPAM Plugin負責對容器的IP地址進行分配和管理。IPAM Plugin作為CNI Plugin的一部分，與CNI Plugin協同工作。

簡述Kubernetes網絡策略？

為實現細粒度的容器間網絡訪問隔離策略，Kubernetes引入Network Policy。

Network Policy的主要功能是對Pod間的網絡通信進行限制和準入控制，設置允許訪問或禁止訪問的客戶端Pod列表。Network Policy定義網絡策略，配合策略控制器（Policy Controller）進行策略的實現。

簡述Kubernetes網絡策略原理？

Network Policy的工作原理主要為：policy controller需要實現一個API Listener，監聽用戶設置的Network Policy定義，并將網絡訪問規則通過各Node的Agent進行實際設置（Agent則需要通過CNI網絡插件實現）。

簡述Kubernetes中flannel的作用？

Flannel可以用于Kubernetes底層網絡的實現，主要作用有：

它能協助Kubernetes，給每一個Node上的Docker容器都分配互相不沖突的IP地址。

它能在這些IP地址之間建立一個覆蓋網絡（Overlay Network），通過這個覆蓋網絡，將數據包原封不動地傳遞到目標容器內。

簡述Kubernetes Calico網絡組件實現原理？

Calico是一個基于BGP的純三層的網絡方案，與OpenStack、Kubernetes、AWS、GCE等云平臺都能夠良好地集成。

Calico在每個計算節點都利用Linux Kernel實現了一個高效的vRouter來負責數據轉發。每個vRouter都通過BGP協議把在本節點上運行的容器的路由信息向整個Calico網絡廣播，并自動設置到達其他節點的路由轉發規則。

Calico保證所有容器之間的數據流量都是通過IP路由的方式完成互聯互通的。Calico節點組網時可以直接利用數據中心的網絡結構（L2或者L3），不需要額外的NAT、隧道或者Overlay Network，沒有額外的封包解包，能夠節約CPU運算，提高網絡效率。

簡述Kubernetes共享存儲的作用？

Kubernetes對于有狀態的容器應用或者對數據需要持久化的應用，因此需要更加可靠的存儲來保存應用產生的重要數據，以便容器應用在重建之后仍然可以使用之前的數據。因此需要使用共享存儲。

簡述Kubernetes數據持久化的方式有哪些？

Kubernetes通過數據持久化來持久化保存重要數據，常見的方式有：

EmptyDir（空目錄）：沒有指定要掛載宿主機上的某個目錄，直接由Pod內保部映射到宿主機上。類似于docker中的manager volume。

場景：

只需要臨時將數據保存在磁盤上，比如在合并/排序算法中；

作為兩個容器的共享存儲。

特性：

同個pod里面的不同容器，共享同一個持久化目錄，當pod節點刪除時，volume的數據也會被刪除。

emptyDir的數據持久化的生命周期和使用的pod一致，一般是作為臨時存儲使用。

Hostpath：將宿主機上已存在的目錄或文件掛載到容器內部。類似于docker中的bind mount掛載方式。

特性：增加了pod與節點之間的耦合。

PersistentVolume（簡稱PV）：如基于NFS服務的PV，也可以基于GFS的PV。它的作用是統一數據持久化目錄，方便管理。

簡述Kubernetes PV和PVC？

PV是對底層網絡共享存儲的抽象，將共享存儲定義為一種“資源”。

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

簡述Kubernetes PV生命周期內的階段？

某個PV在生命周期中可能處于以下4個階段（Phaes）之一。

Available：可用狀態，還未與某個PVC綁定。

Bound：已與某個PVC綁定。

Released：綁定的PVC已經刪除，資源已釋放，但沒有被集群回收。

Failed：自動資源回收失敗。

簡述Kubernetes所支持的存儲供應模式？

Kubernetes支持兩種資源的存儲供應模式：靜態模式（Static）和動態模式（Dynamic）。

靜態模式：集群管理員手工創建許多PV，在定義PV時需要將后端存儲的特性進行設置。

動態模式：集群管理員無須手工創建PV，而是通過StorageClass的設置對后端存儲進行描述，標記為某種類型。此時要求PVC對存儲的類型進行聲明，系統將自動完成PV的創建及與PVC的綁定。

簡述Kubernetes CSI模型？

Kubernetes CSI是Kubernetes推出與容器對接的存儲接口標準，存儲提供方只需要基于標準接口進行存儲插件的實現，就能使用Kubernetes的原生存儲機制為容器提供存儲服務。CSI使得存儲提供方的代碼能和Kubernetes代碼徹底解耦，部署也與Kubernetes核心組件分離，顯然，存儲插件的開發由提供方自行維護，就能為Kubernetes用戶提供更多的存儲功能，也更加安全可靠。

CSI包括CSI Controller和CSI Node：

CSI Controller的主要功能是提供存儲服務視角對存儲資源和存儲卷進行管理和操作。

CSI Node的主要功能是對主機（Node）上的Volume進行管理和操作。

簡述Kubernetes Worker節點加入集群的過程？

通常需要對Worker節點進行擴容，從而將應用系統進行水平擴展。主要過程如下：

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

2、然后配置kubelet和kubeproxy的啟動參數，將Master URL指定為當前Kubernetes集群Master的地址，最后啟動這些服務；

3、通過kubelet默認的自動注冊機制，新的Worker將會自動加入現有的Kubernetes集群中；

4、Kubernetes Master在接受了新Worker的注冊之后，會自動將其納入當前集群的調度范圍。

簡述Kubernetes Pod如何實現對節點的資源控制？

Kubernetes集群里的節點提供的資源主要是計算資源，計算資源是可計量的能被申請、分配和使用的基礎資源。當前Kubernetes集群中的計算資源主要包括CPU、GPU及Memory。CPU與Memory是被Pod使用的，因此在配置Pod時可以通過參數CPU Request及Memory Request為其中的每個容器指定所需使用的CPU與Memory量，Kubernetes會根據Request的值去查找有足夠資源的Node來調度此Pod。

通常，一個程序所使用的CPU與Memory是一個動態的量，確切地說，是一個范圍，跟它的負載密切相關：負載增加時，CPU和Memory的使用量也會增加。

簡述Kubernetes Requests和Limits如何影響Pod的調度？

當一個Pod創建成功時，Kubernetes調度器（Scheduler）會為該Pod選擇一個節點來執行。對于每種計算資源（CPU和Memory）而言，每個節點都有一個能用于運行Pod的最大容量值。調度器在調度時，首先要確保調度后該節點上所有Pod的CPU和內存的Requests總和，不超過該節點能提供給Pod使用的CPU和Memory的最大容量值。

簡述Kubernetes Metric Service？

在Kubernetes從1.10版本后采用Metrics Server作為默認的性能數據采集和監控，主要用于提供核心指標（Core Metrics），包括Node、Pod的CPU和內存使用指標。

對其他自定義指標（Custom Metrics）的監控則由Prometheus等組件來完成。

簡述Kubernetes中，如何使用EFK實現日志的統一管理？

在Kubernetes集群環境中，通常一個完整的應用或服務涉及組件過多，建議對日志系統進行集中化管理，通常采用EFK實現。

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

Elasticsearch：是一個搜索引擎，負責存儲日志并提供查詢接口；

Fluentd：負責從 Kubernetes 搜集日志，每個node節點上面的fluentd監控并收集該節點上面的系統日志，并將處理過后的日志信息發送給Elasticsearch；

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

通過在每臺node上部署一個以DaemonSet方式運行的fluentd來收集每臺node上的日志。Fluentd將docker日志目錄/var/lib/docker/containers和/var/log目錄掛載到Pod中，然后Pod會在node節點的/var/log/pods目錄中創建新的目錄，可以區別不同的容器日志輸出，該目錄下有一個日志文件鏈接到/var/lib/docker/contianers目錄下的容器日志輸出。

簡述Kubernetes如何進行優雅的節點關機維護？

由于Kubernetes節點運行大量Pod，因此在進行關機維護之前，建議先使用kubectl drain將該節點的Pod進行驅逐，然后進行關機維護。

簡述Kubernetes集群聯邦？

Kubernetes集群聯邦可以將多個Kubernetes集群作為一個集群進行管理。因此，可以在一個數據中心/云中創建多個Kubernetes集群，并使用集群聯邦在一個地方控制/管理所有集群。

簡述Helm及其優勢？

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

Helm能夠將一組K8S資源打包統一管理, 是查找、共享和使用為Kubernetes構建的軟件的最佳方式。

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

Helm優勢

在 Kubernetes中部署一個可以使用的應用，需要涉及到很多的 Kubernetes 資源的共同協作。使用helm則具有如下優勢：

統一管理、配置和更新這些分散的 k8s 的應用資源文件；

分發和復用一套應用模板；

將應用的一系列資源當做一個軟件包管理。

對于應用發布者而言，可以通過 Helm 打包應用、管理應用依賴關系、管理應用版本并發布應用到軟件倉庫。

對于使用者而言，使用 Helm 后不用需要編寫復雜的應用部署文件，可以以簡單的方式在 Kubernetes 上查找、安裝、升級、回滾、卸載應用程序。

簡述OpenShift及其特性？

OpenShift是一個容器應用程序平臺，用于在安全的、可伸縮的資源上部署新應用程序，而配置和管理開銷最小。

OpenShift構建于Red Hat Enterprise Linux、Docker和Kubernetes之上，為企業級應用程序提供了一個安全且可伸縮的多租戶操作系統，同時還提供了集成的應用程序運行時和庫。

其主要特性：

自助服務平臺：OpenShift允許開發人員使用Source-to-Image(S2I)從模板或自己的源代碼管理存儲庫創建應用程序。系統管理員可以為用戶和項目定義資源配額和限制，以控制系統資源的使用。

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

自動化：OpenShift提供應用程序生命周期管理功能，當上游源或容器映像發生更改時，可以自動重新構建和重新部署容器。根據調度和策略擴展或故障轉移應用程序。

用戶界面：OpenShift提供用于部署和監視應用程序的web UI，以及用于遠程管理應用程序和資源的CLi。

協作：OpenShift允許在組織內或與更大的社區共享項目。

可伸縮性和高可用性：OpenShift提供了容器多租戶和一個分布式應用程序平臺，其中包括彈性，高可用性，以便應用程序能夠在物理機器宕機等事件中存活下來。OpenShift提供了對容器健康狀況的自動發現和自動重新部署。

容器可移植性：在OpenShift中，應用程序和服務使用標準容器映像進行打包，組合應用程序使用Kubernetes進行管理。這些映像可以部署到基于這些基礎技術的其他平臺上。

開源：沒有廠商鎖定。

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

動態存儲管理：OpenShift使用Kubernetes持久卷和持久卷聲明的方式為容器數據提供靜態和動態存儲管理

基于云(或不基于云)：可以在裸機服務器、活來自多個供應商的hypervisor和大多數IaaS云提供商上部署OpenShift容器平臺。

企業級：Red Hat支持OpenShift、選定的容器映像和應用程序運行時。可信的第三方容器映像、運行時和應用程序由Red Hat認證。可以在OpenShift提供的高可用性的強化安全環境中運行內部或第三方應用程序。

日志聚合和metrics：可以在中心節點收集、聚合和分析部署在OpenShift上的應用程序的日志信息。OpenShift能夠實時收集關于應用程序的度量和運行時信息，并幫助不斷優化性能。

其他特性：OpenShift支持微服務體系結構，OpenShift的本地特性足以支持DevOps流程，很容易與標準和定制的持續集成/持續部署工具集成。

簡述OpenShift projects及其作用？

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

project允許一組用戶獨立于其他組組織和管理其內容，必須允許用戶訪問項目。如果允許創建項目，用戶將自動訪問自己的項目。

簡述OpenShift高可用的實現？

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

OpenShift基礎設施本身的HA(即主機)；

以及在OpenShift集群中運行的應用程序的HA。

默認情況下，OpenShift為master節點提供了完全支持的本機HA機制。
對于應用程序或“pods”，如果pod因任何原因丟失，Kubernetes將調度另一個副本，將其連接到服務層和持久存儲。如果整個節點丟失，Kubernetes會為它所有的pod安排替換節點，最終所有的應用程序都會重新可用。pod中的應用程序負責它們自己的狀態，因此它們需要自己維護應用程序狀態(如HTTP會話復制或數據庫復制)。

簡述OpenShift的SDN網絡實現？

默認情況下，Docker網絡使用僅使用主機虛機網橋bridge，主機內的所有容器都連接至該網橋。連接到此橋的所有容器都可以彼此通信，但不能與不同主機上的容器通信。

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

在OpenShift中，可以為pod網絡配置三個SDN插件:

1、ovs-subnet：默認插件，子網提供了一個flat pod網絡，其中每個pod可以與其他pod和service通信。

2、ovs-multitenant：該為pod和服務提供了額外的隔離層。當使用此插件時，每個project接收一個惟一的虛擬網絡ID (VNID)，該ID標識來自屬于該project的pod的流量。通過使用VNID，來自不同project的pod不能與其他project的pod和service通信。

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

cluster network由OpenShift SDN建立和維護，它使用Open vSwitch創建overlay網絡，master節點不能通過集群網絡訪問容器，除非master同時也為node節點。

簡述OpenShift角色及其作用？

OpenShift的角色具有不同級別的訪問和策略，包括集群和本地策略。user和group可以同時與多個role關聯。

簡述OpenShift支持哪些身份驗證？

OpenShift容器平臺支持的其他認證類型包括:

Basic Authentication (Remote)：一種通用的后端集成機制，允許用戶使用針對遠程標識提供者驗證的憑據登錄到OpenShift容器平臺。用戶將他們的用戶名和密碼發送到OpenShift容器平臺，OpenShift平臺通過到服務器的請求驗證這些憑據，并將憑據作為基本的Auth頭傳遞。這要求用戶在登錄過程中向OpenShift容器平臺輸入他們的憑據。

Request Header Authentication：用戶使用請求頭值(如X-RemoteUser)登錄到OpenShift容器平臺。它通常與身份驗證代理結合使用，身份驗證代理對用戶進行身份驗證，然后通過請求頭值為OpenShift容器平臺提供用戶標識。

Keystone Authentication：Keystone是一個OpenStack項目，提供標識、令牌、目錄和策略服務。OpenShift容器平臺與Keystone集成，通過配置OpenStack Keystone v3服務器將用戶存儲在內部數據庫中，從而支持共享身份驗證。這種配置允許用戶使用Keystone憑證登錄OpenShift容器平臺。

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

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

簡述什么是中間件？

中間件是一種獨立的系統軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源。通常位于客戶機/服務器的操作系統中間，是連接兩個獨立應用程序或獨立系統的軟件。

通過中間件實現兩個不同系統之間的信息交換。

編輯：黃飛

?