導讀etcd是CoreOS團隊發起的開源項目，是一個管理配置信息和服務發現（servicediscovery）的項目，它的目標是構建一個高可用的分布式鍵值（ke....

etcd 是 CoreOS 團隊發起的開源項目，是一個管理配置信息和服務發現（service discovery）的項目，它的目標是構建一個高可用的分布式鍵值（key-value）數據庫，基于 Go 語言實現，今天小編就來聊一聊關于kubernetes底層系統選擇?接下來我們就一起去研究一下吧!

kubernetes底層系統選擇

簡述 ETCD 及其特點？

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

轉自：https://blog.csdn.net/estarhao/article/details/114703958?spm=1001.2014.3001.5501

參考：go語言中文文檔：www.topgoer.com

特點：

• 簡單：支持 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 原理

ubernetes 中的某個 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 節點進行擴容，從而將應用系統進行水平擴展。

主要過程如下：

• 在該 Node 上安裝 Docker、kubelet 和 kube-proxy 服務；
• 然后配置 kubelet 和 kubeproxy 的啟動參數，將 Master URL 指定為當前 Kubernetes 集群 Master 的地址，最后啟動這些服務；
• 通過 kubelet 默認的自動注冊機制，新的 Worker 將會自動加入現有的 Kubernetes 集群中；
• 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 插件:

• 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 節點。

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

簡述什么是中間件？

中間件是一種獨立的系統軟件或服務程序，分布式應用軟件借助這種軟件在不同的技術之間共享資源。

通常位于客戶機/服務器的操作系統中間，是連接兩個獨立應用程序或獨立系統的軟件。

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