运维面试题总结
集群相關
簡述 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 擁有以下明顯優勢：
?
簡述 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 涉及多個組件之間聯動，主要流程如下：
?
簡述 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 的副本數量，完成擴縮容操作。
?
?
?
?
總結
- 上一篇： Nginx(六)：配置nginx高可用集
- 下一篇： latex表格名的引用问题