IT運維面試問題總結-LVS、Keepalived、HAProxy、Kubernetes、OpenShift等

語言: CN / TW / HK
公眾號關注 傑哥的IT之旅 ”,
選擇“ 星標 ”, 重磅乾貨,第一 時間送達!

1、簡述ETCD及其特點?

etcd 是 CoreOS 團隊發起的開源專案,是一個管理配置資訊和服務發現(service discovery)的專案,它的目標是構建一個高可用的分散式鍵值(key-value)資料庫,基於 Go 語言實現。

特點:

  • 簡單:支援 REST 風格的 HTTP+JSON API

  • 安全:支援 HTTPS 方式的訪問

  • 快速:支援併發 1k/s 的寫操作

  • 可靠:支援分散式結構,基於 Raft 的一致性演算法,Raft 是一套通過選舉主節點來實現分散式系統一致性的演算法。

2、簡述ETCD適應的場景?

etcd基於其優秀的特點,可廣泛的應用於以下場景:

  • 服務發現(Service Discovery):服務發現主要解決在同一個分散式叢集中的程序或服務,要如何才能找到對方並建立連線。本質上來說,服務發現就是想要了解叢集中是否有程序在監聽udp或tcp埠,並且通過名字就可以查詢和連線。

  • 訊息釋出與訂閱:在分散式系統中,最適用的一種元件間通訊方式就是訊息釋出與訂閱。即構建一個配置共享中心,資料提供者在這個配置中心釋出訊息,而訊息使用者則訂閱他們關心的主題,一旦主題有訊息釋出,就會實時通知訂閱者。通過這種方式可以做到分散式系統配置的集中式管理與動態更新。應用中用到的一些配置資訊放到etcd上進行集中管理。

  • 負載均衡:在分散式系統中,為了保證服務的高可用以及資料的一致性,通常都會把資料和服務部署多份,以此達到對等服務,即使其中的某一個服務失效了,也不影響使用。etcd本身分散式架構儲存的資訊訪問支援負載均衡。etcd叢集化以後,每個etcd的核心節點都可以處理使用者的請求。所以,把資料量小但是訪問頻繁的訊息資料直接儲存到etcd中也可以實現負載均衡的效果。

  • 分散式通知與協調:與訊息釋出和訂閱類似,都用到了etcd中的Watcher機制,通過註冊與非同步通知機制,實現分散式環境下不同系統之間的通知與協調,從而對資料變更做到實時處理。

  • 分散式鎖:因為etcd使用Raft演算法保持了資料的強一致性,某次操作儲存到叢集中的值必然是全域性一致的,所以很容易實現分散式鎖。鎖服務有兩種使用方式,一是保持獨佔,二是控制時序。

  • 叢集監控與Leader競選:**通過etcd來進行監控實現起來非常簡單並且實時性強。

3、簡述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認證;

  • 基於命令列的管理介面;

  • 日誌分析器,可對日誌進行分析。

4、簡述HAProxy常見的負載均衡策略?

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

  • roundrobin:表示簡單的輪詢。

  • static-rr:表示根據權重。

  • leastconn:表示最少連線者先處理。

  • source:表示根據請求的源IP,類似Nginx的IP_hash機制。

  • ri:表示根據請求的URI。

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

  • rdp-cookie(name):表示根據據cookie(name)來鎖定並雜湊每一次TCP請求。

5、簡述負載均衡四層和七層的區別?

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

七層負載均衡器也稱為7層交換機,位於OSI的最高層,即應用層,此負載均衡器支援多種協議,如HTTP、FTP、SMTP等。7層負載均衡器可根據報文內容,配合一定的負載均衡演算法來選擇後端伺服器,即“內容交換器”。如常見的HAProxy、Nginx。一文帶你讀懂Nginx的負載均衡

6、簡述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伺服器或快取伺服器。

7、簡述Heartbeat?

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

8、簡述Keepalived及其工作原理?

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

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

9、簡述Keepalived體系主要模組及其作用?

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

core模組為keepalived的核心,負責主程序的啟動、維護及全域性配置檔案的載入和解析。

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

check負責健康檢查,常見的方式有埠檢查及URL檢查。

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

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

網路層,Keepalived採用ICMP協議向伺服器叢集中的每個節點發送一個ICMP的資料包,如果某個節點沒有返回響應資料包,則認為此節點發生了故障,Keepalived將報告次節點失效,並從伺服器叢集中剔除故障節點。利用 Nginx+Keepalived 實現高可用技術

傳輸層,Keepalived利用TCP的埠連線和掃描技術來判斷叢集節點是否正常。如常見的web服務預設埠80,ssh預設埠22等。Keepalived一旦在傳輸層探測到相應埠沒用響應資料返回,則認為此埠發生異常,從而將此埠對應的節點從伺服器叢集中剔除。

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

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

11、簡述LVS的概念及其作用?

LVS是linux virtual server的簡寫linux虛擬伺服器,是一個虛擬的伺服器集群系統,可以在unix/linux平臺下實現負載均衡叢集功能。超詳細!一文帶你瞭解 LVS 負載均衡叢集!

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

  • 把單臺計算機無法承受的大規模的併發訪問或資料流量分擔到多臺節點裝置上分別處理,減少使用者等待響應的時間,提升使用者體驗。

  • 單個重負載的運算分擔到多臺節點裝置上做並行處理,每個節點裝置處理結束後,將結果彙總,返回給使用者,系統處理能力得到大幅度提高。

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

12、簡述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都有一塊網絡卡連線到同一物理網段上,必須在同一個區域網環境。

13、簡述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,並以它作為下一次分配的首先考慮。

14、簡述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協議的負載均衡轉發。

15、簡述代理伺服器的概念及其作用?

代理伺服器是一個位於客戶端和原始(資源)伺服器之間的伺服器,為了從原始伺服器取得內容,客戶端向代理伺服器傳送一個請求並指定目標原始伺服器,然後代理伺服器向原始伺服器轉交請求並將獲得的內容返回給客戶端。

其主要作用有:

  • 資源獲取:代替客戶端實現從原始伺服器的資源獲取;

  • 加速訪問:代理伺服器可能離原始伺服器更近,從而起到一定的加速作用;

  • 快取作用:代理伺服器儲存從原始伺服器所獲取的資源,從而實現客戶端快速的獲取;

  • 隱藏真實地址:代理伺服器代替客戶端去獲取原始伺服器資源,從而隱藏客戶端真實資訊。

16、簡述高可用叢集可通過哪兩個維度衡量高可用性,各自含義是什麼?

  • RTO(Recovery Time Objective):RTO指服務恢復的時間,最佳的情況是 0,即服務立即恢復;最壞是無窮大,即服務永遠無法恢復;

  • RPO(Recovery Point Objective):RPO 指指當災難發生時允許丟失的資料量,0 意味著使用同步的資料,大於 0 意味著有資料丟失,如“RPO=1 d”指恢復時使用一天前的資料,那麼一天之內的資料就丟失了。因此,恢復的最佳情況是 RTO = RPO = 0,幾乎無法實現。

17、簡述什麼是CAP理論?

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

  • Consistency(一致性):所有節點在同一時間具有相同的資料;

  • Availability(可用性):保證每個請求不管成功或者失敗都有響應;

  • Partition tolerance(分割槽容錯性):系統中任意資訊的丟失或失敗不影響系統的繼續執行。

CAP 理論的核心是:一個分散式系統不可能同時很好的滿足一致性,可用性和分割槽容錯性這三個需求,最多隻能同時較好的滿足兩個。

18、簡述什麼是ACID理論?

  • 原子性(Atomicity):整體不可分割性,要麼全做要不全不做;

  • 一致性(Consistency):事務執行前、後資料庫狀態均一致;

  • 隔離性(Isolation):在事務未提交前,它操作的資料,對其它使用者不可見;

  • 永續性 (Durable):一旦事務成功,將進行永久的變更,記錄與redo日誌。

19、簡述什麼是Kubernetes?

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

20、簡述Kubernetes和Docker的關係?

Docker 提供容器的生命週期管理和,Docker 映象構建執行時容器。它的主要優點是將將軟體/應用程式執行所需的設定和依賴項打包到一個容器中,從而實現了可移植性等優點。

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

21、簡述Kubernetes中什麼是Minikube、Kubectl、Kubelet?

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

Kubectl 是一個命令列工具,可以使用該工具控制Kubernetes叢集管理器,如檢查群集資源,建立、刪除和更新元件,檢視應用程式。

Kubelet 是一個代理服務,它在每個節點上執行,並使從伺服器與主伺服器通訊。

22、簡述Kubernetes常見的部署方式?

常見的Kubernetes部署方式有:

  • kubeadm:也是推薦的一種部署方式;

  • 二進位制

  • minikube:在本地輕鬆執行一個單節點 Kubernetes 群集的工具。

23、簡述Kubernetes如何實現叢集管理?

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

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

Kubernetes作為一個完備的分散式系統支撐平臺,其主要優勢:

  • 容器編排

  • 輕量級

  • 開源

  • 彈性伸縮

  • 負載均衡

Kubernetes常見場景:

  • 快速部署應用

  • 快速擴充套件應用

  • 無縫對接新的應用功能

  • 節省資源,優化硬體資源的使用

Kubernetes相關特點:

  • **可移植: ** 支援公有云、私有云、混合雲、多重雲(multi-cloud)。

  • **可擴充套件: ** 模組化,、外掛化、可掛載、可組合。

  • **自動化: ** 自動部署、自動重啟、自動複製、自動伸縮/擴充套件。

25、簡述Kubernetes的缺點或當前的不足之處?

Kubernetes當前存在的缺點(不足)如下:

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

  • 管理服務相對繁瑣。

  • 執行和編譯需要很多時間。

  • 它比其他替代品更昂貴。

  • 對於簡單的應用程式來說,可能不需要涉及Kubernetes即可滿足。

26、簡述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在共享使用整個叢集的資源的同時還能被分別管理。

27、簡述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的伸縮動作。

28、簡述Kubernetes RC的機制?

Replication Controller用來管理Pod的副本,保證叢集中存在指定數量的Pod副本。當定義了RC並提交至Kubernetes叢集中之後,Master節點上的Controller Manager元件獲悉,並同時巡檢系統中當前存活的目標Pod,並確保目標Pod例項的數量剛好等於此RC的期望值,若存在過多的Pod副本在執行,系統會停止一些Pod,反之則自動建立一些Pod。

29、簡述Kubernetes Replica Set 和 Replication Controller 之間有什麼區別?

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

30、簡述kube-proxy作用?

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

31、簡述kube-proxy iptables原理?

Kubernetes從1.2版本開始,將iptables作為kube-proxy的預設模式。iptables模式下的kube-proxy不再起到Proxy的作用,其核心功能:通過API Server的Watch介面實時跟蹤Service與Endpoint的變更資訊,並更新對應的iptables規則,Client的請求流量則通過iptables的NAT機制“直接路由”到目標Pod。

32、簡述kube-proxy ipvs原理?

IPVS在Kubernetes1.11中升級為GA穩定版。IPVS則專門用於高效能負載均衡,並使用更高效的資料結構(Hash表),允許幾乎無限的規模擴張,因此被kube-proxy採納為最新模式。

在IPVS模式下,使用iptables的擴充套件ipset,而不是直接呼叫iptables來生成規則鏈。iptables規則鏈是一個線性的資料結構,ipset則引入了帶索引的資料結構,因此當規則很多時,也可以很高效地查詢和匹配。

可以將ipset簡單理解為一個IP(段)的集合,這個集合的內容可以是IP地址、IP網段、埠等,iptables可以直接新增規則對這個“可變的集合”進行操作,這樣做的好處在於可以大大減少iptables規則的數量,從而減少效能損耗。

33、簡述kube-proxy ipvs和iptables的異同?

iptables與IPVS都是基於Netfilter實現的,但因為定位不同,二者有著本質的差別:iptables是為防火牆而設計的;IPVS則專門用於高效能負載均衡,並使用更高效的資料結構(Hash表),允許幾乎無限的規模擴張。

與iptables相比,IPVS擁有以下明顯優勢:

  • 為大型叢集提供了更好的可擴充套件性和效能;

  • 支援比iptables更復雜的複製均衡演算法(最小負載、最少連線、加權等);

  • 支援伺服器健康檢查和連線重試等功能;

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

34、簡述Kubernetes中什麼是靜態Pod?

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

35、簡述Kubernetes中Pod可能位於的狀態?

  • Pending:API Server已經建立該Pod,且Pod內還有一個或多個容器的映象沒有建立,包括正在下載映象的過程。

  • Running:Pod內所有容器均已建立,且至少有一個容器處於執行狀態、正在啟動狀態或正在重啟狀態。

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

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

  • Unknown:由於某種原因無法獲取該Pod狀態,可能由於網路通訊不暢導致。

36、簡述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資料中心。

37、簡述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進行健康檢查。

38、簡述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掉。

39、簡述Kubernetes Pod的LivenessProbe探針的常見方式?

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

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

  • TCPSocketAction:通過容器的IP地址和埠號執行TCP檢查,若能建立TCP連線,則表明容器健康。

  • HTTPGetAction:通過容器的IP地址、埠號及路徑呼叫HTTP Get方法,若響應的狀態碼大於等於200且小於400,則表明容器健康。

40、簡述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。

41、簡述Kubernetes初始化容器(init container)?

init container的執行方式與應用容器不同,它們必須先於應用容器執行完成,當設定了多個init container時,將按順序逐個執行,並且只有前一個init container執行成功後才能執行後一個init container。當所有init container都成功執行後,Kubernetes才會初始化Pod的各種資訊,並開始建立和執行應用容器。

42、簡述Kubernetes deployment升級過程?

初始建立Deployment時,系統建立了一個ReplicaSet,並按使用者的需求建立了對應數量的Pod副本。

當更新Deployment時,系統建立了一個新的ReplicaSet,並將其副本數量擴充套件到1,然後將舊ReplicaSet縮減為2。

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

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

43、簡述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)來控制滾動更新的過程。

44、簡述Kubernetes DaemonSet型別的資源特性?

DaemonSet資源物件會在每個Kubernetes叢集中的節點上執行,並且每個節點只能執行一個pod,這是它和deployment資源物件的最大也是唯一的區別。因此,在定義yaml檔案中,不支援定義replicas。

它的一般使用場景如下:

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

  • 監控每個節點的的執行狀態。

45、簡述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的副本數量,完成擴縮容操作。

46、簡述Kubernetes Service型別?

通過建立Service,可以為一組具有相同功能的容器應用提供一個統一的入口地址,並且將請求負載分發到後端的各個容器應用上。其主要型別有:

  • ClusterIP:虛擬的服務IP地址,該地址用於Kubernetes叢集內部的Pod訪問,在Node上kube-proxy通過設定的iptables規則進行轉發;

  • NodePort:使用宿主機的埠,使能夠訪問各Node的外部客戶端通過Node的IP地址和埠號就能訪問服務;

  • LoadBalancer:使用外接負載均衡器完成到服務的負載分發,需要在spec.status.loadBalancer欄位指定外部負載均衡器的IP地址,通常用於公有云。

47、簡述Kubernetes Service分發後端的策略?

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

  • RoundRobin:預設為輪詢模式,即輪詢將請求轉發到後端的各個Pod上。

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

48、簡述Kubernetes Headless Service?

在某些應用場景中,若需要人為指定負載均衡器,不使用Service提供的預設負載均衡的功能,或者應用程式希望知道屬於同組服務的其他例項。Kubernetes提供了Headless Service來實現這種功能,即不為Service設定ClusterIP(入口IP地址),僅通過Label Selector將後端的Pod列表返回給呼叫的客戶端。

49、簡述Kubernetes外部如何訪問叢集內的服務?

對於Kubernetes,叢集外的客戶端預設情況,無法通過Pod的IP地址或者Service的虛擬IP地址:虛擬埠號進行訪問。通常可以通過以下方式進行訪問Kubernetes叢集內的服務:

  • 對映Pod到物理機:將Pod埠號對映到宿主機,即在Pod中採用hostPort方式,以使客戶端應用能夠通過物理機訪問容器應用。

  • 對映Service到物理機:將Service埠號對映到宿主機,即在Service中採用nodePort方式,以使客戶端應用能夠通過物理機訪問容器應用。

  • 對映Sercie到LoadBalancer:通過設定LoadBalancer對映到雲服務商提供的LoadBalancer地址。這種用法僅用於在公有云服務提供商的雲平臺上設定Service的場景。

50、簡述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提供的是對外服務,則實際上實現的是邊緣路由器的功能。

51、簡述Kubernetes映象的下載策略?

K8s的映象下載策略有三種:Always、Never、IFNotPresent。

  • Always:映象標籤為latest時,總是從指定的倉庫中獲取映象。

  • Never:禁止從倉庫中下載映象,也就是說只能使用本地映象。

  • IfNotPresent:僅當本地沒有對應映象時,才從目標倉庫中下載。

預設的映象下載策略是:當映象標籤是latest時,預設策略是Always;當映象標籤是自定義時(也就是標籤不是latest),那麼預設策略是IfNotPresent。

52、簡述Kubernetes的負載均衡器?

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

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

53、簡述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繫結到目標節點上。

54、簡述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映象並啟動容器。

55、簡述Kubernetes Scheduler使用哪兩種演算法將Pod繫結到worker節點?

Kubernetes Scheduler根據如下兩種排程演算法將 Pod 繫結到最合適的工作節點:

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

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

56、述Kubernetes kubelet的作用?

在Kubernetes叢集中,在每個Node(又稱Worker)上都會啟動一個kubelet服務程序。該程序用於處理Master下發到本節點的任務,管理Pod及Pod中的容器。每個kubelet程序都會在API Server上註冊節點自身的資訊,定期向Master彙報節點資源的使用情況,並通過cAdvisor監控容器和節點資源。

57、簡述Kubernetes kubelet監控Worker節點資源是使用什麼元件來實現的?

kubelet使用cAdvisor對worker節點資源進行監控。在 Kubernetes 系統中,cAdvisor 已被預設整合到 kubelet 元件內,當 kubelet 服務啟動時,它會自動啟動 cAdvisor 服務,然後 cAdvisor 會實時採集所在節點的效能指標及在節點上執行的容器的效能指標。

58、簡述Kubernetes如何保證叢集的安全性?

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

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

許可權方面:

  • 最小許可權原則:合理限制所有元件的許可權,確保元件只執行它被授權的行為,通過限制單個元件的能力來限制它的許可權範圍。

  • 使用者許可權:劃分普通使用者和管理員的角色。

叢集方面:

  • API Server的認證授權:Kubernetes叢集中所有資源的訪問和變更都是通過Kubernetes API Server來實現的,因此需要建議採用更安全的HTTPS或Token來識別和認證客戶端身份(Authentication),以及隨後訪問許可權的授權(Authorization)環節。

  • API Server的授權管理:通過授權策略來決定一個API呼叫是否合法。對合法使用者進行授權並且隨後在使用者訪問時進行鑑權,建議採用更安全的RBAC方式來提升叢集安全授權。

  • 敏感資料引入Secret機制:對於叢集敏感資料建議使用Secret方式進行保護。

  • AdmissionControl(准入機制):對kubernetes api的請求過程中,順序為:先經過認證 & 授權,然後執行准入操作,最後對目標物件進行操作。

59、簡述Kubernetes准入機制?

在對叢集進行請求時,每個准入控制程式碼都按照一定順序執行。如果有一個准入控制拒絕了此次請求,那麼整個請求的結果將會立即返回,並提示使用者相應的error資訊。

准入控制(AdmissionControl)准入控制本質上為一段准入程式碼,在對kubernetes api的請求過程中,順序為:先經過認證 & 授權,然後執行准入操作,最後對目標物件進行操作。常用元件(控制程式碼)如下:

  • AlwaysAdmit:允許所有請求

  • AlwaysDeny:禁止所有請求,多用於測試環境。

  • ServiceAccount:它將serviceAccounts實現了自動化,它會輔助serviceAccount做一些事情,比如如果pod沒有serviceAccount屬性,它會自動新增一個default,並確保pod的serviceAccount始終存在。

  • LimitRanger:觀察所有的請求,確保沒有違反已經定義好的約束條件,這些條件定義在namespace中LimitRange物件中。

  • NamespaceExists:觀察所有的請求,如果請求嘗試建立一個不存在的namespace,則這個請求被拒絕。

60、簡述Kubernetes RBAC及其特點(優勢)?

RBAC是基於角色的訪問控制,是一種基於個人使用者的角色來管理對計算機或網路資源的訪問的方法。

相對於其他授權模式,RBAC具有如下優勢:

  • 對叢集中的資源和非資源許可權均有完整的覆蓋。

  • 整個RBAC完全由幾個API物件完成, 同其他API物件一樣, 可以用kubectl或API進行操作。

  • 可以在執行時進行調整,無須重新啟動API Server。

61、簡述Kubernetes Secret作用?

Secret物件,主要作用是保管私密資料,比如密碼、OAuth Tokens、SSH Keys等資訊。將這些私密資訊放在Secret物件中比直接放在Pod或Docker Image中更安全,也更便於使用和分發。

62、簡述Kubernetes Secret有哪些使用方式?

建立完secret之後,可通過如下三種方式使用:

  • 在建立Pod時,通過為Pod指定Service Account來自動使用該Secret。

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

  • 在Docker映象下載時使用,通過指定Pod的spc.ImagePullSecrets來引用它。

63、簡述Kubernetes PodSecurityPolicy機制?

Kubernetes PodSecurityPolicy是為了更精細地控制Pod對資源的使用方式以及提升安全策略。在開啟PodSecurityPolicy准入控制器後,Kubernetes預設不允許建立任何Pod,需要建立PodSecurityPolicy策略和相應的RBAC授權策略(Authorizing Policies),Pod才能建立成功。

64、簡述Kubernetes PodSecurityPolicy機制能實現哪些安全策略?

在PodSecurityPolicy物件中可以設定不同欄位來控制Pod執行時的各種安全策略,常見的有:

  • 特權模式:privileged是否允許Pod以特權模式執行。

  • 宿主機資源:控制Pod對宿主機資源的控制,如hostPID:是否允許Pod共享宿主機的程序空間。

  • 使用者和組:設定執行容器的使用者ID(範圍)或組(範圍)。

  • 提升許可權:AllowPrivilegeEscalation:設定容器內的子程序是否可以提升許可權,通常在設定非root使用者(MustRunAsNonRoot)時進行設定。

  • SELinux:進行SELinux的相關配置。

65、簡述Kubernetes網路模型?

Kubernetes網路模型中每個Pod都擁有一個獨立的IP地址,並假定所有Pod都在一個可以直接連通的、扁平的網路空間中。所以不管它們是否執行在同一個Node(宿主機)中,都要求它們可以直接通過對方的IP進行訪問。設計這個原則的原因是,使用者不需要額外考慮如何建立Pod之間的連線,也不需要考慮如何將容器埠對映到主機埠等問題。

同時為每個Pod都設定一個IP地址的模型使得同一個Pod內的不同容器會共享同一個網路名稱空間,也就是同一個Linux網路協議棧。這就意味著同一個Pod內的容器可以通過localhost來連線對方的埠。

在Kubernetes的叢集裡,IP是以Pod為單位進行分配的。一個Pod內部的所有容器共享一個網路堆疊(相當於一個網路名稱空間,它們的IP地址、網路裝置、配置等都是共享的)。

66、簡述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協同工作。

67、簡述Kubernetes網路策略?

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

Network Policy的主要功能是對Pod間的網路通訊進行限制和准入控制,設定允許訪問或禁止訪問的客戶端Pod列表。Network Policy定義網路策略,配合策略控制器(Policy Controller)進行策略的實現。

68、簡述Kubernetes網路策略原理?

Network Policy的工作原理主要為:policy controller需要實現一個API Listener,監聽使用者設定的Network Policy定義,並將網路訪問規則通過各Node的Agent進行實際設定(Agent則需要通過CNI網路外掛實現)。

69、簡述Kubernetes中flannel的作用?

Flannel可以用於Kubernetes底層網路的實現,主要作用有:

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

  • 它能在這些IP地址之間建立一個覆蓋網路(Overlay Network),通過這個覆蓋網路,將資料包原封不動地傳遞到目標容器內。

70、簡述Kubernetes Calico網路元件實現原理?

Calico是一個基於BGP的純三層的網路方案,與OpenStack、Kubernetes、AWS、GCE等雲平臺都能夠良好地整合。

Calico在每個計算節點都利用Linux Kernel實現了一個高效的vRouter來負責資料轉發。每個vRouter都通過BGP協議把在本節點上執行的容器的路由資訊向整個Calico網路廣播,並自動設定到達其他節點的路由轉發規則。

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

71、簡述Kubernetes共享儲存的作用?

Kubernetes對於有狀態的容器應用或者對資料需要持久化的應用,因此需要更加可靠的儲存來儲存應用產生的重要資料,以便容器應用在重建之後仍然可以使用之前的資料。因此需要使用共享儲存。

72、簡述Kubernetes資料持久化的方式有哪些?

Kubernetes通過資料持久化來持久化儲存重要資料,常見的方式有:

EmptyDir(空目錄):沒有指定要掛載宿主機上的某個目錄,直接由Pod內保部對映到宿主機上。類似於docker中的manager volume。

場景:

  • 只需要臨時將資料儲存在磁碟上,比如在合併/排序演算法中;

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

特性:

  • 同個pod裡面的不同容器,共享同一個持久化目錄,當pod節點刪除時,volume的資料也會被刪除。

  • emptyDir的資料持久化的生命週期和使用的pod一致,一般是作為臨時儲存使用。

Hostpath:將宿主機上已存在的目錄或檔案掛載到容器內部。類似於docker中的bind mount掛載方式。

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

PersistentVolume(簡稱PV):如基於NFS服務的PV,也可以基於GFS的PV。它的作用是統一資料持久化目錄,方便管理。

73、簡述Kubernetes PV和PVC?

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

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

74、簡述Kubernetes PV生命週期內的階段?

某個PV在生命週期中可能處於以下4個階段(Phaes)之一。

  • Available:可用狀態,還未與某個PVC繫結。

  • Bound:已與某個PVC繫結。

  • Released:繫結的PVC已經刪除,資源已釋放,但沒有被叢集回收。

  • Failed:自動資源回收失敗。

75、簡述Kubernetes所支援的儲存供應模式?

Kubernetes支援兩種資源的儲存供應模式:靜態模式(Static)和動態模式(Dynamic)。

  • 靜態模式:叢集管理員手工建立許多PV,在定義PV時需要將後端儲存的特性進行設定。

  • 動態模式:叢集管理員無須手工建立PV,而是通過StorageClass的設定對後端儲存進行描述,標記為某種型別。此時要求PVC對儲存的型別進行宣告,系統將自動完成PV的建立及與PVC的繫結。

76、簡述Kubernetes CSI模型?

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

CSI包括CSI Controller和CSI Node:

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

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

77、簡述Kubernetes Worker節點加入叢集的過程?

通常需要對Worker節點進行擴容,從而將應用系統進行水平擴充套件。主要過程如下:

1、在該Node上安裝Docker、kubelet和kube-proxy服務;
2、然後配置kubelet和kubeproxy的啟動引數,將Master URL指定為當前Kubernetes叢集Master的地址,最後啟動這些服務;
3、通過kubelet預設的自動註冊機制,新的Worker將會自動加入現有的Kubernetes叢集中;
4、Kubernetes Master在接受了新Worker的註冊之後,會自動將其納入當前叢集的排程範圍。

78、簡述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的使用量也會增加。

79、簡述Kubernetes Requests和Limits如何影響Pod的排程?

當一個Pod建立成功時,Kubernetes排程器(Scheduler)會為該Pod選擇一個節點來執行。對於每種計算資源(CPU和Memory)而言,每個節點都有一個能用於執行Pod的最大容量值。排程器在排程時,首先要確保排程後該節點上所有Pod的CPU和記憶體的Requests總和,不超過該節點能提供給Pod使用的CPU和Memory的最大容量值。

80、簡述Kubernetes Metric Service?

在Kubernetes從1.10版本後採用Metrics Server作為預設的效能資料採集和監控,主要用於提供核心指標(Core Metrics),包括Node、Pod的CPU和記憶體使用指標。對其他自定義指標(Custom Metrics)的監控則由Prometheus等元件來完成。

81、簡述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目錄下的容器日誌輸出。

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

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

83、簡述Kubernetes叢集聯邦?

Kubernetes叢集聯邦可以將多個Kubernetes叢集作為一個叢集進行管理。因此,可以在一個數據中心/雲中建立多個Kubernetes叢集,並使用叢集聯邦在一個地方控制/管理所有叢集。

84、簡述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 上查詢、安裝、升級、回滾、解除安裝應用程式。

85、簡述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流程,很容易與標準和定製的持續整合/持續部署工具整合。

86、簡述OpenShift projects及其作用?

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

project允許一組使用者獨立於其他組組織和管理其內容,必須允許使用者訪問專案。如果允許建立專案,使用者將自動訪問自己的專案。

87、簡述OpenShift高可用的實現?

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

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

以及在OpenShift叢集中執行的應用程式的HA。

預設情況下,OpenShift為master節點提供了完全支援的本機HA機制。

對於應用程式或“pods”,如果pod因任何原因丟失,Kubernetes將排程另一個副本,將其連線到服務層和持久儲存。如果整個節點丟失,Kubernetes會為它所有的pod安排替換節點,最終所有的應用程式都會重新可用。pod中的應用程式負責它們自己的狀態,因此它們需要自己維護應用程式狀態(如HTTP會話複製或資料庫複製)。

88、簡述OpenShift的SDN網路實現?

預設情況下,Docker網路使用僅使用主機虛機網橋bridge,主機內的所有容器都連線至該網橋。連線到此橋的所有容器都可以彼此通訊,但不能與不同主機上的容器通訊。

為了支援跨叢集的容器之間的通訊,OpenShift容器平臺使用了軟體定義的網路(SDN)方法。軟體定義的網路是一種網路模型,它通過幾個網路層的抽象來管理網路服務。SDN將處理流量的軟體(稱為控制平面)和路由流量的底層機制(稱為資料平面)解耦。SDN支援控制平面和資料平面之間的通訊。

在OpenShift中,可以為pod網路配置三個SDN外掛:

  • ovs-subnet:預設外掛,子網提供了一個flat pod網路,其中每個pod可以與其他pod和service通訊。

  • ovs-multitenant:該為pod和服務提供了額外的隔離層。當使用此外掛時,每個project接收一個惟一的虛擬網路ID (VNID),該ID標識來自屬於該project的pod的流量。通過使用VNID,來自不同project的pod不能與其他project的pod和service通訊。

  • ovs-network policy:此外掛允許管理員使用NetworkPolicy物件定義自己的隔離策略。
    cluster network由OpenShift SDN建立和維護,它使用Open vSwitch建立overlay網路,master節點不能通過叢集網路訪問容器,除非master同時也為node節點。

89、簡述OpenShift角色及其作用?

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

90、簡述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組織中。

91、簡述什麼是中介軟體?

中介軟體是一種獨立的系統軟體或服務程式,分散式應用軟體藉助這種軟體在不同的技術之間共享資源。通常位於客戶機/ 伺服器的作業系統中間,是連線兩個獨立應用程式或獨立系統的軟體。

通過中介軟體實現兩個不同系統之間的資訊交換。

回覆下方  「關鍵詞」,獲取優質資源

回覆關鍵詞 「CDN」,即可獲取 89 頁 CDN 排坑指南手冊
回覆關鍵詞 「ECS」,即可獲取 96 頁 ECS 運維 Linux 系統診斷手冊
回覆關鍵詞 「linux」,即可獲取 185 頁 Linux 工具快速教程手冊
回覆關鍵詞 「Python進階」,即可獲取 106 頁 Python 進階文件 PDF
回覆關鍵詞 「Python自動化」,即可獲取 97 頁自動化文件 PDF
回覆關鍵詞 「Excel資料透視表」,即可獲取 136 頁 Excel資料透視表 PDF
回覆關鍵詞 「Python最強基礎學習文件」,即可獲取 68 頁 Python 最強基礎學習文件 PDF
回覆關鍵詞 「wx」,即可加入傑哥的IT之旅讀者交流群

作者:木二
連結:https://www.yuque.com/docs/share/d3dd1e8e-6828-4da7-9e30-6a4f45c6fa8e

本公眾號全部博文已整理成一個目錄,請在公眾號後臺回覆「 m 」獲取!

推薦閱讀:

1、 IT運維面試問題總結-資料庫、監控、網路管理(NoSQL、MongoDB、MySQL、Prometheus、Zabbix)
2、 IT運維面試問題總結-運維工具、開源應用(Ansible、Ceph、Docker、Apache、Nginx等)
3、 IT運維面試問題總結-基礎服務、磁碟管理、虛擬平臺和系統管理
4、 IT運維面試問題總結-Linux基礎


      
      
  
        
        
點個[在看],是對傑哥最大的支援!

本文分享自微信公眾號 - 傑哥的IT之旅(Jake_Internet)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。