IT運維面試問題總結

IT運維面試總結如下，後期更新於：//www.yuque.com/docs/share/d3dd1e8e-6828-4da7-9e30-6a4f45c6fa8e。

歡迎基於學習、交流目的的轉載和分享，禁止任何商業盜用，同時希望能帶上原文出處，尊重ITer的成果，也是尊重知識。

若發現任何錯誤或紕漏，留言回饋或右側添加本人回饋。

Linux基礎

簡述Linux主流的發行版？

Redhat、CentOS、Fedora、SuSE、Debian、Ubuntu、FreeBSD等。

簡述Linux啟動過程？

  • ⑴開機BIOS自檢，載入硬碟。
  • ⑵讀取MBR，MBR引導。
  • ⑶grub引導菜單(Boot Loader)。
  • ⑷載入內核kernel。
  • ⑸啟動init進程，依據inittab文件設定運行級別。
  • ⑹init進程，執行rc.sysinit文件。
  • ⑺啟動內核模組，執行不同級別的腳本程式。
  • ⑻執行/etc/rc.d/rc.local。
  • ⑼啟動tty，進入系統登陸介面。

簡述Linux刪除文件的原理？

Linux系統是通過link的數量來控制文件刪除的，只有當一個文件不存在任何link的時候，這個文件才會被刪除。一般來說每個文件兩個link計數器來控制：i_count和i_nlink。當一個文件被一個程式佔用的時候i_count就加1。當文件的硬鏈接多一個的時候i_nlink也加1。刪除一個文件，就是讓這個文件，沒有進程佔用，同時i_link數量為0。

簡述Linux運行級別？

  • 0：關機模式
  • 1：單用戶模式<==破解root密碼
  • 2：無網路支援的多用戶模式
  • 3：有網路支援的多用戶模式（文本模式，工作中最常用的模式）
  • 4：保留，未使用
  • 5：有網路支援的X-windows支援多用戶模式（桌面）
  • 6：重新引導系統，即重啟

簡述Linux常見目錄及其作用？

  • /（根目錄）：Linux文件系統的起點；
  • boot：存放Linux系統啟動做必須的文件；
  • var：存放經常變換的文件；
  • home：普通用戶的家目錄
  • root：Linux系統的root用戶家目錄；
  • bin：存放系統基本的用戶命令；
  • sbin：存放系統基本的管理命令；
  • use：存放Linux應用程式；
  • etc：存放Linux系統和各種程式的配置文件。

簡述Linux作業系統常見的文件系統有？

  • EXT3
  • EXT4
  • XFS

簡述Linux系統中的buffer和cache區別？

buffer和cache都是記憶體中的一塊區域，當CPU需要寫數據到磁碟時，由於磁碟速度比較慢，所以CPU先把數據存進buffer，然後CPU去執行其他任務，buffer中的數據會定期寫入磁碟；當CPU需要從磁碟讀入數據時，由於磁碟速度比較慢，可以把即將用到的數據提前存入cache，CPU直接從Cache中讀取數據。

簡述Linux中inode和block？

inode節點是一個64位元組長的表，表中包含了文件的相關資訊，如：位元組數、屬主UserID、屬組GroupID、讀寫執行許可權、時間戳等。在inode節點表中最重要的內容是：磁碟地址表。
文件名存放在目錄當中，但Linux系統內部不使用文件名，而是使用inode號碼識別文件。對於系統來說文件名只是inode號碼便於識別的別稱。即Linux文件系統通過把inode和文件名進行關聯來查找文件。當需要讀取該文件時，文件系統在當前目錄表中查找該文件名對應的項，由此得到該文件相對應的inode節點號，通過該inode節點的磁碟地址表把分散存放的文件物理塊連接成文件的邏輯結構。
文件是存儲在硬碟上的，硬碟的最小存儲單位叫做扇區sector，每個扇區存儲512位元組。作業系統讀取硬碟的時候，不會一個個扇區地讀取，這樣效率太低，而是一次性連續讀取多個扇區，即一次性讀取一個塊block。這種由多個扇區組成的塊，是文件存取的最小單位。塊的大小，最常見的是4KB，即連續八個sector組成一個block。
即512位元組組成一個扇區（sector），多個扇區組成一個塊（block），常見的塊單位位4KB，即連續八個扇區組成一個block。


一個文件必須佔用一個inode，但至少佔用一個block。

簡述Linux文件系統修復fsck過程？

成功修復文件系統的前提是要有兩個以上的主文件系統（即兩個系統），並保證在修復之前卸載將被修復的文件系統，然後使用命令fsck對受到破壞的文件系統進行修復。
fsck檢查文件系統分為5步，每一步檢查系統不同部分的連接特性並對上一步進行驗證和修改。
檢查從超級塊開始、然後是分配的磁碟塊、路徑名、目錄的連接性、鏈接數目以及空閑塊鏈表、inode。


簡述Linux中軟鏈接和硬鏈接的區別？

  • 軟鏈接

軟鏈接類似於Windows的快捷方式功能的文件，可以快速連接到目標文件或目錄。即再創建一個獨立的文件，而這個文件會讓數據的讀取指向它連接的那個文件的文件名。例如，文件A和文件B的inode號碼雖然不一樣，但是文件A的內容是文件B的路徑。讀取文件A時，系統會自動將訪問者導向文件B。這時，文件A就稱為文件B的軟鏈接。
因此，文件A依賴於文件B而存在，如果刪除了文件B，打開文件A就會報錯。

  • 硬鏈接

通過文件系統的inode鏈接來產生的新的文件名，而不是產生新的文件，稱為硬鏈接。
一般情況下，每個inode號碼對應一個文件名，但是Linux允許多個文件名指向同一個inode號碼。意味著可以使用不同的文件名訪問相同的內容。
創建硬鏈接，源文件與目標文件的inode號碼相同，都指向同一個inode。inode資訊中的鏈接數這時就會增加1。

  • 當一個文件擁有多個硬鏈接時，對文件內容修改，會影響到所有其他文件的內容；
  • 刪除一個文件名，不影響另一個文件名的訪問，刪除一個文件名，只會使得inode中的鏈接數減1。
  • 區別

軟鏈接與硬鏈接最大的區別：軟鏈接是文件A指向文件B的文件名，而不是文件B的inode號碼，文件B的inode鏈接數不會因此發生變化。

不能對目錄做硬鏈接，但是通過mkdir命令創建一個新目錄，通常其硬鏈接數應該有2個，因為常見的目錄本身為1個硬鏈接，而目錄下面的隱藏目錄.（點號）是該目錄的又一個硬鏈接，也算是1個連接數。

簡述TCP三次握手，四次斷開，及其優點和缺點，同時相對於UDP的差別？

TCP與UDP概念：

  • TCP：傳輸控制協議，即面向連接；
  • UDP：用戶數據報協議，無連接的，即發送數據之前不需要建立連接

TCP與UDP的優缺點上的區別：

  • TCP的優點：

可靠，穩定。TCP的可靠體現在TCP在傳遞數據之前，會有三次握手來建立連接，而且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開連接用來節約系統資源。

  • 三次握手：
  1. 第一次握手，主機A向主機B發出一個含同步序列號的標誌位的數據段給主機B ，向主機B請求建立連接。通過這個數據段，A向B聲明通訊請求，以及告知B可用某個序列號作為起始數據段進行響應；
  2. 第二次握手，主機B收到主機A的請求後，用一帶有確認應答(ACK)和同步序列號(SYN)標誌位的數據段響應A。通過此數據段，B向A聲明已收到A的請求，A可以傳輸數據了，同時告知A可用某個序列號作為起始數據段進行響應；
  3. 第三次握手，主機A收到主機B的數據段後，再發送一個確認應答，確認已收到主機B 的數據段，之後開始正式實際傳輸數據。

ACK：TCP報頭的控制位之一，對數據進行確認。確認由目的端發出，來告知發送端這個序列號之前的數據段都收到了。比如，確認號為X，則表示前X-1個數據段都收到了。只有當ACK=1時，確認號才有效，當ACK=0時，確認號無效，此時會要求重傳數據，保證數據的完整性。
SYN：同步序列號，這個標誌位只有在TCP建立連接時才會被置1，握手完成後SYN標誌位被置0。

  • 四次斷開：
  1. 當主機A完成數據傳輸後，將控制位FIN置1，提出停止TCP連接的請求；
  2. 主機B收到FIN後對其作出響應，確認這一方向上的TCP連接將關閉，將ACK置1；
  3. 主機B再提出反方向的關閉請求，將FIN置1；
  4. 主機A對主機B的請求進行確認，將ACK置1，雙方向的關閉結束。
  • TCP的缺點：

慢、效率低、佔用系統資源高、易被攻擊：TCP在傳遞數據之前，要先建連接，需要消耗時間，而且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每台設備上維護所有的傳輸連接。同時，每個連接都會佔用系統的CPU、記憶體等硬體資源。 而且，因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊。

DoS：拒絕服務（Denial of Servic），造成DoS的攻擊行為被稱為DoS攻擊，其目的是使電腦或網路無法提供正常的服務。最常見的DoS攻擊有電腦網路頻寬攻擊和連通性攻擊。
DDOS：分散式拒絕服務(DDoS:Distributed Denial of Service)，DDoS攻擊指藉助於客戶/伺服器技術，將多個電腦聯合起來作為攻擊平台，對一個或多個目標發動DDoS攻擊，從而成倍地提高拒絕服務攻擊的威力。

  • UDP的優點：

快、比TCP稍安全、沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。沒有TCP的這些機制，UDP被攻擊者利用的漏洞就要少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊。

UDP Flood攻擊檢測：短時間內向特定目標不斷發送 UDP 報文，致使目標系統負擔過重而不能處理合法的傳輸任務，就發生了 UDP Flood。啟用 UDP Flood 攻擊檢測功能時，要求設置一個連接速率閾值，一旦發現保護主機響應的 UDP 連接速率超過該值，防火牆會輸出發生 UDP Flood 攻擊的告警日誌，並且根據用戶的配置可以阻止發往該主機的後續連接請求。

  • UDP的缺點：

不可靠、不穩定。因為UDP沒有那些可靠的機制，在數據傳遞時，如果網路品質不好，就會很容易丟包。

  • TCP應用場景：

當對網路通訊品質有要求的時候，比如：整個數據要準確無誤的傳遞給對方，要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。

  • UDP應用場景：

當對網路通訊品質要求不高的時候，要求網路通訊速度能盡量的快。 比如QQ語音、QQ影片、TFTP 。

簡述TCP/IP及其主要協議？

TCP/IP協議是一個協議簇，其中包括很多協議的。
TCP/IP協議包括應用層、傳輸層、網路層、網路訪問層（網路介面層、網際層）。

  • 應用層：應用程式間溝通的層
    • 超文本傳輸協議(HTTP)：萬維網的基本協議；
    • 文件傳輸(TFTP)：簡單文件傳輸協議；
    • 遠程登錄(Telnet)：提供遠程訪問其它主機功能，它允許用戶登錄internet主機，並在這台主機上執行命令；
    • 網路管理(SNMP)：簡單網路管理協議，該協議提供了監控網路設備的方法，以及配置管理、統計資訊收集、性能管理及安全管理等；
    • 域名系統(DNS)：域名解析服務，該系統用於在internet中將域名及轉換成IP地址；
  • 傳輸層：提供了節點間的數據傳送服務，給數據包加入傳輸數據並把它傳輸到下一層中，這一層負責傳送數據，並且確定數據已被送達並接收。
    • 傳輸控制協議（TCP）
    • 用戶數據報協議（UDP）
  • 網路層：負責提供基本的數據封包傳送功能，讓每一個數據包都能夠到達目的主機（但不檢查是否被正確接收）。
    • Internet協議(IP) ：根據網間報文IP地址，從一個網路通過路由器傳到另一網路；
    • ICMP：Internet控制資訊協議(ICMP)；
    • ARP：地址解析協議(ARP) ——”最不安全的協議”。
    • RARP：反向地址解析協議(RARP)：
  • 網路訪問層：又稱作主機到網路層(host-to-network)，IP地址與物理地址硬體的映射及IP封裝成幀，基於不同硬體類型的網路介面，網路訪問層定義了與物理介質的連接。

簡述OSI模型及其主要協議？

OSI模型是一個開放式系統互聯參考模型，該模型人為的定義了七層結構。由下至上及其主要作用為：

  1. 物理層：OSI的物理層規定了通訊端點之間的機械特性、電氣特性、功能特性以及過程特性，該層為上層協議提供了一個傳輸數據的物理媒體。該層數據的單位稱為比特(bit)。其主要有：EIA/TIA、RS-232、EIA/TIA、RS-449、V.35、RJ-45、fddi令牌環網。
  2. 數據鏈路層：定義了在單個鏈路上如何傳輸數據，其主要作用包括：作用包括物理地址定址、數據的成幀、流量控制、數據的檢錯、重發等。該層數據的單位稱為幀(frame)。其主要有：ARP、RARP、SDLC、HDLC、PPP、STP、幀中繼。
  3. 網路層：定義了端到端的包傳輸，定義了能夠標識所有結點的邏輯地址，還定義了路由實現的方式和學習路由的方式。為了適應最大傳輸單元長度小於包長度的傳輸介質，網路層還定義了如何將一個包分解成更小的包的分段方法。主要負責尋找地址和路由選擇，網路層還可以實現擁塞控制、網際互連等功能。該層數據的單位稱為數據包(packet)。主要有：IP、IPX、RIP、OSPF。
  4. 傳輸層：主要功能：
    • 為端到端連接提供傳輸服務；
    • 這種傳輸服務分為可靠和不可靠的，其中TCP是典型的可靠傳輸，而UDP則是不可靠傳輸；
    • 為端到端連接提供流量控制，差錯控制，重新排序，服務品質等管理服務。

該層數據的單位稱為數據段(segment)。主要有：TCP、UDP、SPX、DCCP、SCTP、RTP、RSVP、PPTP。

  1. 會話層：他定義了如何開始、控制和結束一個會話，即負責建立和斷開通訊連接（數據流動的邏輯通路）。主要有：RPC、SQL、NetBIOS。
  2. 表示層：定義數據格式及加密。主要負責數據格式的轉換，確保一個系統的應用層資訊可被另一個系統應用層讀取。主要有：加密、ASII、TIFF、JPEG、HTML、PICT。
  3. 應用層：與其他電腦進行通訊的一個應用，它是對應應用程式的通訊服務的，為應用程式提供服務並規定應用程式中通訊相關的細節。主要有：Telnet、HTTP、FTP、WWW、NFS、SMTP。

簡述IP協議、IP地址？

IP協議(Internet Protocol)：又稱互聯網協議，是支援網間互連的數據報協議。它提供網間連接的完善功能，包括IP數據報規定互連網路範圍內的IP地址格式。
為了實現連接到互聯網上的結點之間的通訊，必須為每個結點（入網的電腦）分配一個地址，並且應當保證這個地址是全網唯一的，這便是IP地址。
目前的IP地址（IPv4：IP第4版本）由32個二進位位表示，每8位二進位數為一個整數，中間由小數點間隔，整個IP地址空間有4組8位二進位數，由表示主機所在的網路的地址以及主機在該網路中的標識共同組成。 為了便於定址和層次化的構造網路，IP地址被分為A、B、C、D、E五類，商業應用中只用到A、B、C三類。

  • A類地址：網路標識由第一組8位二進位數表示，網路中的主機標識佔3組8位二進位數，網路標識的第一位二進位數取值必須為”0″。A類地址允許有126個網段，每個網路大約允許有1670萬台主機，通常分配給擁有大量主機的網路（如主幹網）。 1.0.0.1－127.255.255.254
  • B類地址：網路標識由前兩組8位二進位數表示，網路中的主機標識佔兩組8位二進位數，網路標識的前兩位二進位數取值必須為”10″。B類地址允許有16384個網段，每個網路允許有65533台主機，適用於結點比較多的網路（如區域網）。 128.1.0.1－191.255.255.254
  • C類地址：網路標識由前3組8位二進位數表示，網路中主機標識佔1組8位二進位數，網路標識的前3位二進位數取值必須為”110″。具有C類地址的網路允許有254台主機，適用於結點比較少的網路（如校園網）。 192.0.1.1－223.255.255.254

為了便於記憶，通常習慣採用4個十進位數來表示一個IP地址，十進位數之間採用句點”.”予以分隔。這種IP地址的表示方法也被稱為點分十進位法。

簡述靜態路由和動態路由及其特點？

靜態路由：由系統管理員創建的路由，適用於網關數量有限的場合，且網路拓樸結構不經常變化的網路。其缺點是不能動態地適用網路狀況的變化，當網路狀況變化後需要網路管理員手動修改路由表。
動態路由：由路由選擇協議動態構建的路由，路由協議之間通過交換各自所擁有的路由資訊實時更新路由表的內容。動態路由可以自動學習網路的拓樸結構，並更新路由表。其缺點是路由廣播更新資訊將佔據大量的網路頻寬。

簡述NAT的幾種類型，及其原理？

常見的NAT主要有DNA和SNAT。
SNAT：指在數據包從網卡發送出去的時候，把數據包中的源地址部分替換為指定的IP。此時，接收方就認為數據包的來源是被替換的那個IP的主機。
DNAT：指數據包從網卡發送出去的時候，修改數據包中的目的IP。此時，若訪問A，但因此DNAT的存在，所有訪問A的數據包的目的IP全部修改為B，那麼，實際上訪問的是B。


簡述包過濾防火牆和代理應用防火牆的區別？

包過濾防火牆：工作在網路層，根據包頭中的源IP地址、目標IP地址、協議類型、埠號進行過濾；
代理應用防火牆：工作在應用層，使用代理伺服器技術，將內網對外網的訪問，變為防火牆對外網的訪問，可以對包的內容進行分辨，從而過濾。

基礎服務

簡述Linux中常見的系統服務，其作用分別是？

常見的系統服務及其作用有：

  • NTP/Chrony：用於時鍾同步；
  • DHCP：動態主機配置協議，用於自動分配主機地址，默認使用UDP 63埠；
  • DNS：域名解析，運行在UDP協議之上，默認使用53埠；
  • NFS：網路文件系統，依賴於RCP協議，其基本原則是「容許不同的客戶端及服務端通過一組RPC分享相同的文件系統」，它是獨立於作業系統，容許不同硬體及作業系統的系統共同進行文件的分享。
  • Postfix：郵件服務；
  • rsync：遠程數據備份服務。
  • VPN：虛擬專用網。

更多服務參考：//c.biancheng.net/view/1059.html。

簡述FTP主要的工作模式？

FTP工作模式是以服務端角度來區分，有主動模式和被動模式。

  • 主動模式是指由FTP服務端主動向客戶端發起連接，服務端埠號為20（用於傳輸）和21（用於控制），即20埠向客戶端的一個大於1024的隨機埠傳輸數據；
  • 被動模式是指由FTP客戶端向服務端發起連接，服務端採用隨機埠等待客戶端的隨機埠來訪問，從而傳輸數據。

簡述FTP兩種登錄方式以及兩種傳輸模式？

  • FTP有兩種登錄方式：匿名登錄和授權登錄。

使用匿名登錄時，用戶名為：anonymous，密碼為：任何合法email地址；
使用授權登錄時，用戶名為用戶在遠程FTP系統中的用戶帳號，密碼為用戶在遠程系統中的用戶密碼。
區別：使用匿名登錄只能訪問FTP目錄下的資源，默認配置下只能下載；而授權登錄訪問的許可權大於匿名登錄，且上載、下載均可。

  • FTP文件傳輸有兩種文件傳輸模式：ASCII模式和binary模式。

ASCII模式用來傳輸文本文件；其他文件的傳輸使用binary模式。

簡述DHCP的流程？

新節點通過DHCP獲取地址資訊的主要流程有如下四個過程：

  1. 尋找DHCP Server
    客戶機第一次登錄網路的時，向網路上發出一個DHCPDISCOVER廣播（包中包含客戶機的MAC地址和電腦名等資訊）。其源地址為0.0.0.0，目標地址為255.255.255.255。
  2. 提供IP地址租用
    服務端監聽到客戶機發出的DHCP discover廣播後，從剩餘地址池中選擇最前面的空置IP，連同其它TCP/IP設定，通過廣播方式響應給客戶端一個DHCP OFFER數據包（包中包含IP地址、子網掩碼、地址租期等資訊）。源IP地址為DHCP Server的IP地址，目標地址為255.255.255.255。同時，DHCP Server為此客戶保留它提供的IP地址，從而不會為其他DHCP客戶分配此IP地址。
  3. 接受IP租約
    客戶機挑選最先響應的DHCP OFFER（一般是最先到達的那個），同時向網路廣播DHCP REQUEST數據包（包中包含客戶端的MAC地址、接受的租約中的IP地址、提供此租約的DHCP伺服器地址等），聲明將接受某一台伺服器提供的IP地址。此時，由於還沒有得到DHCP Server的最後確認，客戶端仍然使用0.0.0.0為源IP地址，255.255.255.255為目標地址進行廣播。
  4. 租約確認
    服務端接收到客戶端的DHCP REQUEST之後，會廣播返回給客戶機一個DHCP ACK消息包，表明已經接受客戶機的選擇，並將這一IP地址的合法租用以及其他的配置資訊都放入該廣播包發給客戶機。
    客戶機在接收到DHCP ACK廣播後，會向網路發送三個針對此IP地址的ARP解析請求以執行衝突檢測，查詢網路上有沒有其它機器使用該IP地址；如果發現該IP地址已經被使用，客戶機會發出一個DHCP DECLINE數據包給DHCP Server，拒絕此IP地址租約，並重新發送DHCP discover資訊。此時，在DHCP伺服器管理控制台中，會顯示此IP地址為BAD_ADDRESS。
    如果網路上沒有其它主機使用此IP地址，則客戶機的TCP/IP使用租約中提供的IP地址完成初始化，從而可以和其他網路中的主機進行通訊。

簡述DNS查詢可能需要哪些過程？

通常DNS查詢有如下過程，任何一過程查詢成功則返回查詢結果，不再進行下一步查詢：

  1. 用戶輸入網址，優先調取本地hosts查詢記錄；
  2. 使用本地dns快取查詢記錄；
  3. 使用網路設置的主dns查詢記錄；
  4. 使用dns伺服器中的快取；
  5. dns伺服器轉發查詢，轉發至上一級ISP DNS伺服器，依次循環；
  6. 若dns伺服器未配置轉發查詢，則將查詢需求發至13台根dns；
  7. 返回查詢IP結果給客戶端。

簡述DNS常見的伺服器角色類型？

  • 緩衝域名伺服器
  • 主域名伺服器
  • 從域名伺服器

簡述NFS文件系統及其作用？

網路文件系統是應用層的一種應用服務，它主要應用於Linux和Linux系統、Linux和Unix系統之間的文件或目錄的共享。對於用戶而言可以通過NFS方便的訪問遠地的文件系統，使之成為本地文件系統的一部分。採用NFS之後省去了登錄的過程，方便了用戶訪問系統資源。

簡述Samba作用及其使用場景？

Samba是在Linux上實現SMB協議的一個免費軟體，由伺服器及客戶端程式構成。SMB（Server Messages Block，資訊服務塊）是一種在區域網上共享文件和印表機的一種通訊協議，它為區域網內的不同電腦之間提供文件及印表機等資源的共享服務。SMB協議是客戶機/伺服器型協議，客戶機通過該協議可以訪問伺服器上的共享文件系統、印表機及其他資源。主要用於windows與Linux之間的文件共享。

簡述VPN概念以及常見的類型？

VPN是指在公共的網路上建立專用網路的技術，但是兩個節點間並沒有物理上的專用的端到端鏈路，而是通過廣域網或者運營商提供的網路平台之上的邏輯網路，用戶數據在邏輯鏈路中傳輸，同時VPN採用身份驗證和加密技術，充分保證了安全性。常見的VPN有：IPSec VPN、PPTP VPN、L2TP VPN、SSL VPN。

簡述YUM服務工作步驟？

客戶端在通過yum安裝軟體時，會先訪問repo倉庫，下載倉庫的元數據，根據元數據去查詢所需要的rpm及其各種依賴關係。之後再在倉庫進行相關下載，並自動解決rpm包的依賴關係。同時repo倉庫應該是一個文件伺服器，一般linux主機在下載過元數據的同時會將其保留在快取中，以便後續使用。本質上是將底層的物理硬碟抽象的封裝起來，然後以邏輯卷的方式呈現給上層應用。

磁碟管理

簡述LVM概念及其特點？

LVM是對磁碟分區進行管理的一種機制，建立在硬碟和分區之上的一個邏輯層，用來提高磁碟管理的靈活性。通過LVM可將若干個磁碟分區連接為一個整塊的卷組(Volume Group)，形成一個存儲池。可以在卷組上隨意創建邏輯卷(Logical Volumes)，並進一步在邏輯卷上創建文件系統，與直接使用物理存儲在管理上相比，提供了更好靈活性。

  • 設計概念
    • 物理存儲介質（The physical media）：LVM存儲介質可以是磁碟分區、整個磁碟、RAID陣列或SAN磁碟，設備必須初始化為LVM物理卷，才能與LVM結合使用；
    • 物理卷PV（physical volume）：物理卷就是LVM的基本存儲邏輯塊，但和基本的物理存儲介質（如分區、磁碟等）比較，卻包含有與LVM相關的管理參數，創建物理卷它可以用硬碟分區，也可以用硬碟本身；
    • 卷組VG（Volume Group）：一個LVM卷組由一個或多個物理卷組成；
    • 邏輯卷LV（logical volume）：LV建立在VG之上，可以在LV之上建立文件系統；
    • PE（physical extents）：PV物理卷中可以分配的最小存儲單元，PE的大小是可以指定的，默認為4MB；
    • LE（logical extent）：LV邏輯卷中可以分配的最小存儲單元，在同一個卷組中，LE的大小和PE是相同的，並且一一對應。
  • 特點
    • 優點
      • 可以在系統運行的狀態下動態的擴展文件系統的大小。
      • 文件系統可以跨多個磁碟，因此文件系統大小不會受物理磁碟的限制。
      • 可以增加新的磁碟到LVM的存儲池中。
      • 可以以鏡像的方式冗餘重要的數據到多個物理磁碟。
      • 可以方便的導出整個卷組到另外一台機器。
    • 缺點
      • 在從卷組中移除一個磁碟的時候必須使用reducevg命令，有一定的限制：這個命令要求root許可權，並且不允許在快照卷組中使用。
      • 當卷組中的一個磁碟損壞時，整個卷組都會受到影響。
      • 因為加入了額外的操作，存儲性能受到影響。

簡述RAID0、RAID1、RAID5原理及特點、使用場景？

RAID通常可以把硬碟整合成一個大磁碟，然後在大磁碟上再分區，提高數據量利用率、冗餘性，根據其特點不同，常見的有RAID0、RADI1、RAID5。
RAID 0：指由多個盤組合成邏輯上的一個盤。
優點：讀寫快，容量利用率最高。
缺點：沒有冗餘，任何一塊磁碟失效將影響到所有數據。

RAID 1：偶數盤，進行鏡像。
優點：最高的冗餘性。
缺點：浪費資源，成本高，數據利用率低。

RAID 5：奇數盤，至少3塊磁碟。分散式奇偶校驗的獨立磁碟結構，它的奇偶校驗碼存在於所有磁碟上 任何一個硬碟損壞，都可以根據其它硬碟上的校驗位來重建損壞的數據。
優點：實現數據一定程度的冗餘，同時也提升數據的讀寫性能。
缺點：構建此模式需要一定數量的磁碟。

冗餘從好到壞：RAID 1 > RAID 10 > RAID 5 > RAID 0 
性能從好到壞：RAID 0 > RAID 10 > RAID 5 > RAID 1
成本從低到高：RAID 0 > RAID 5 > RAID 1 > RAID 10











簡述iSCSI存儲及其優點？

iSCSI是Internet小型電腦系統介面，是一個基於TCP/IP的協議，用於通過IP網路模擬SCSI高性能本地存儲匯流排，從而為遠程存儲設備提供數據傳輸和管理。iSCSI跨本地和廣域網，通過分散式伺服器和數組提供獨立於位置的數據存儲檢索。
iSCSI優點

  • 使用SAN擺脫了本地布線限制，促進了本地或遠程數據中心的存儲整合；
  • iSCSI結構是邏輯性的，僅使用軟體配置來進行新的存儲分配，無需其他電纜和物理磁碟；
  • iSCSI使用多個遠程數據中心簡化了數據複製、遷移和災難恢復。

簡述文件存儲、塊存儲、對象存儲？

文件存儲：允許將數據組織為傳統的文件系統。數據保存在一個文件中，該文件具有名稱和一些相關的元數據，例如修改時間戳、所有者和訪問許可權。提供基於文件的存儲使用目錄和子目錄的層次結構來組織文件的存儲方式。
塊存儲：塊存儲提供了一個像硬碟驅動器一樣工作的存儲卷，組織成大小相同的塊。通常，要麼作業系統用文件系統格式化基於塊的存儲卷，要麼應用程式(如資料庫)直接訪問它來存儲數據。
對象存儲：對象存儲允許將任意數據和元數據存儲為一個單元，並在平面存儲池中標記為惟一標識符。使用API存儲和檢索數據，而不是將數據作為塊或在文件系統層次結構中訪問。 

虛擬平台

簡述什麼是雲計算及其基本特徵？

雲計算是一種採用按量付費的模式，基於虛擬化技術，將相應計算資源（如網路、存儲等）池化後，提供便捷的、高可用的、高擴展性的、按需的服務（如計算、存儲、應用程式和其他 IT 資源）。
雲計算通常有如下基本特徵：

  • 自主服務：可按需的獲取雲端的相應資源（主要指公有雲）；
  • 網路訪問：可隨時隨地使用任何聯網終端設備接入雲端從而使用相應資源。
  • 資源池化：
  • 快速彈性：可方便、快捷地按需獲取和釋放計算資源。
  • 按量計費：

簡述雲計算常見部署模式？

  • 私有云：雲平台資源只給某個單位、或某部分用戶內部使用。
  • 公有云：雲平台資源開放給社會公眾服務。
  • 社區云：雲平台資源給幾個固定的單位內使用。
  • 混合云：兩個或兩個以上不同類型的雲平台。

簡述雲計算三種服務模式？

  • IaaS：基礎設施即服務，雲服務商將IT系統的基礎設施（如計算資源、存儲資源、網路資源）池化後作為服務進行售賣；
  • PaaS：平台即服務，雲服務商將IT系統的平台軟體層（資料庫、OS、中間件、運行庫）作為服務進行售賣；
  • SaaS：軟體即服務，雲服務商將IT系統的應用軟體層作為服務進行售賣。

簡述雲計算和虛擬化的區別？

雲計算：IT能力服務化，按需使用，按量計費，多租戶隔離，是一個系統的輕量級管理控制面。
虛擬化：環境隔離，資源復用，降低隔離損耗，提升運行性能，提供高級虛擬化特性。
虛擬化是實現雲計算的技術支撐之一，但並非雲計算的核心關注點。


簡述私有雲相對公有雲有哪些優勢？

  • 數據安全性更高；
  • 可節省上雲遷移過程中的大量成本；
  • 業務快速部署，縮短業務周期；
  • 降低企業成本，自主可控。

簡述什麼是KVM？

KVM指基於內核的虛擬機（Kernel-based Virtual Machine），它是一個Linux的一個內核模組，該內核模組使得Linux變成了一個 Hypervisor，從而實現虛擬化：

  • 它由 Quramnet 開發，該公司於 2008年被 Red Hat 收購。
  • 它支援 x86 (32 and 64 位)、s390、Powerpc 等 CPU。
  • 它從 Linux 2.6.20 起就作為一模組被包含在 Linux 內核中。
  • 它需要支援虛擬化擴展的 CPU。
  • 它是完全開源的。

系統管理

簡述Rsync及其特點？

Rsync是Linux系統中的數據鏡像備份工具，通過rsync可以將本地系統數據通過網路備份到任何遠程主機上。rysnc不僅僅能對不同位置的文件和目錄進行同步，還可以差異計算，壓縮傳輸文件來最小化數據傳輸，和cp命令相比，rysnc的優勢在於高效的差異演算法。並且，rysnc還支援網路數據傳輸，在複製文件的同時，會把源端與目的端的文件進行比較，只有當文件不一樣的時候在進行複製。具有以下特性：

  • 可以鏡像保存整個目錄樹和文件系統。
  • 可以同步增量數據，文件傳輸效率高，同步時間短。
  • 可以保留原有文件的許可權、時間等屬性。
  • 加密傳輸數據，保證了數據的安全性。

簡述iptables規則工作過程？

iptables防火牆是一層層過濾的，實際是按照配置規則的順序從上到下，從前到後進行過濾的。
如果匹配上了規則，即明確表明是阻止還是通過，此時數據包就不能向下匹配新規則了。
如果所有規則中沒有明確表明是阻止還是通過這個數據包，也就是沒有匹配上規則，向下進行匹配，直到匹配默認規則得到明確的阻止還是通過。
防火牆的默認規則是對應鏈的所有的規則執行完才會執行的，即最後執行的規則。



簡述iptables有幾個鏈、表及每個表的作用？

iptables有5個鏈：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING。
iptables有4個表：Filter、NAT、Mangle、RAW。

  • Filter：主要和主機自身有關，真正負責主機防火牆功能（過濾流入流出主機的數據包）。filter表是iptables默認使用的表。filter定義了三個鏈（chains）：
    • INPUT：負責過濾所有目標地址是本機地址的數據包，通俗的講，就是過濾進入主機的數據包
    • FORWARD：負責轉發流經主機的數據包。起轉發的作用，和nat關係很大，
    • OUTPUT：處理所有源地址是本機地址的數據包，通俗的講，就是處理從主機發出去的數據包

對於filter表的控制是實現本機防火牆功能的重要手段，特別是對INPUT鏈的控制。

  • nat：負責網路地址轉換，即來源與目的ip地址的port的轉換，一般用於區域網共享上網或特殊的埠轉換服務相關，nat功能就相當於網路的acl控制。。nat定義了三個鏈（chains）：
    • OUTPUT：和主機發出去的數據包有關，改變主機發出數據包的目標地址。
    • PREROUTING：在數據包到達防火牆時進行路由判斷之前執行的規則。作用時改變數據包的目的地址，目的埠等。
    • POSTROUTING：在數據包離開防火牆時進行路由判斷之後執行的規則，作用改變數據包的源地址，源埠等。
  • RAW：RAW表只使用在PREROUTING鏈和OUTPUT鏈上，因為優先順序最高，從而可以對收到的數據包在連接跟蹤前進行處理。一但用戶使用了RAW表，在某個鏈上，RAW表處理完後，將跳過NAT表和 ip_conntrack處理，即不再做地址轉換和數據包的鏈接跟蹤處理了。RAW表可以應用在那些不需要做nat的情況下，以提高性能。如大量訪問的web伺服器，可以讓80埠不再讓iptables做數據包的鏈接跟蹤處理，以提高用戶的訪問速度。
  • Mangle：實現流量整形，主要用於修改數據包的ToS( Type of Service ，服務類型）、TTL(Time toLive，生存周期）以及為數據包設置 Mark 標記，以實現 QoS(Quality of Service，服務品質）調整以及策略路由等應用。

簡述iptables各個表的優先順序？

4個表的優先順序由高到低的順序為：raw–>mangle–>nat–>filter。

簡述iptables處理經過的數據包的流程？

iptables利用表和鏈處理每個經過的數據包，具體流程（步驟）如下：

  1. 數據包到達網路介面，比如 eth0。
  2. 進入 raw 表的 PREROUTING 鏈，這個鏈的作用是在連接跟蹤之前處理數據包。
  3. 如果進行了連接跟蹤，則進行處理。
  4. 進入 mangle 表的 PREROUTING 鏈，在此可以修改數據包，比如 TOS 等。
  5. 進入 nat 表的 PREROUTING 鏈，可以在此做DNAT，但不做過濾。
  6. 決定路由，看是交給本地主機還是轉發給其它主機，即決定是否繼續往內還是往外。

到了這裡需要分兩種不同的情況進行討論了。

  • 若數據包決定要轉發給其它主機，這時候它會依次經過：
  1. 進入 mangle 表的 FORWARD 鏈，這裡是在第一次路由（即步驟6）決定之後，在進行最後的路由決定之前，仍然可以對數據包進行某些修改。
  2. 進入 filter 表的 FORWARD 鏈，這裡可以對所有轉發的數據包進行過濾。
  3. 進入 mangle 表的 POSTROUTING 鏈，這裡將完成了所有的路由決定，但數據包仍然在本地主機，還可以進行某些修改。
  4. 進入 nat 表的 POSTROUTING 鏈，這裡一般都是用來做 SNAT ，不在這裡進行過濾。
  5. 進入出去的網路介面，然後進行發送。
  • 另一種情況是，數據包就是發給本地主機的，那麼它會依次穿過：
  1. 進入 mangle 表的 INPUT 鏈，這裡是在第一次路由（即步驟6）決定之後，在進行最後的路由決定之前，仍然可以對數據包進行某些修改。
  2. 進入 filter 表的 INPUT 鏈，這裡可以對流入的所有數據包進行過濾，無論它來自哪個網路介面。
  3. 交給本地主機的應用程式進行處理。
  4. 處理完畢後進行路由決定，看該往那裡發出。
  5. 進入 raw 表的 OUTPUT 鏈，這裡是在連接跟蹤處理本地的數據包之前。
  6. 連接跟蹤對本地的數據包進行處理。
  7. 進入 mangle 表的 OUTPUT 鏈，這裡可以修改數據包，但不做過濾。
  8. 進入 nat 表的 OUTPUT 鏈，可以對防火牆自己發出的數據做 NAT 。
  9. 再次進行路由決定。
  10. 進入 filter 表的 OUTPUT 鏈，可以對本地出去的數據包進行過濾。
  11. 進入 mangle 表的 POSTROUTING 鏈，同上一種情況的第9步。
  12. 進入 nat 表的 POSTROUTING 鏈，同上一種情況的第10步。
  13. 進入出去的網路介面，然後進行發送。

運維工具

簡述Ansible及其優勢？

Ansible是一款極其簡單的開源的自動化運維工具，基於Python開發，集合了眾多運維工具(puppet, cfengine, chef, func, fabric)的優點。實現了批量系統配置，批量程式部署，批量運行命令等功能。
同時Ansible是基於模組工作，其實現批量部署的是ansible所運行的模組。
Ansible其他重要的優勢：

  • 跨平台支援：Ansible在物理、虛擬、雲和容器環境中為Linux、Windows、UNIX和網路設備提供無代理支援。
  • 人類可讀的自動化：Ansible playbook以YAML文本文件的形式編寫，易於閱讀，有助於確保每個人都理解他們將要做的事情。
  • 對應用程式的完美描述：Ansible playbook可以進行任何更改，並且可以描述和記錄應用程式環境的每個細節。
  • 易於管理的版本控制：Ansible劇本和項目是純文本。它們可以像源程式碼一樣處理，並放在現有的版本控制系統中。
  • 支援動態庫存：Ansible管理的機器列表可以從外部資源動態更新，以便隨時捕獲所有受管伺服器的正確的當前列表，無論基礎設施或位置如何。
  • 易於與其他系統集成的編排：HP SA、Puppet、Jenkins、Red Hat Satellite，以及存在於環境中的其他系統，都可以被利用並集成到Ansible工作流中。

簡述Ansible工作機制及其特性？

Ansible是一款自動化運維工具，基於Python開發，具有批量系統配置, 批量程式部署, 批量運行命令等功能。
其工作機制如下：

  1. 用戶使用Ansible或Playbook，在伺服器中斷輸入Ansible的Ad-Hoc命令集或Playbook；
  2. Ansible遵循預先編排的規則將Playbooks逐條拆解為Play；
  3. Play組織成Ansible可識別的任務（Task）；
  4. Task會調用任務所涉及的所有模組（Module）和插件（Plugin）；
  5. 讀取Inventroy中定義的主機列表；
  6. 通過SSH認證（默認）將任務集以臨時文件或命令的形式傳輸到遠程客戶端執行並返回執行結果。

其特性如下：

  1. no agents：不需要在被管控主機上安裝任何客戶端，只需SSH、Python即可，建議Python版本為2.6.6以上；
  2. no server：無伺服器端, 使用時直接運行命令即可；
  3. modules in any languages：基於模組工作, 豐富的內置模組，可使用任意語言開發模組；
  4. yaml, not code：使用yaml語言訂製劇本playbook，易於管理，API簡單明了；
  5. ssh by default：基於SSH工作，整個過程簡單、方便、安全，建議使用公鑰方式認證；
  6. strong multi-tier solution：可實現多級指揮。

簡述Ansible中如何保存敏感數據？

在ansible內容中保留秘密數據並仍然公開共享，那麼可以在playbooks中使用Vault。Ansible Vault，它包含在Ansible中，可以加密和解密Ansible使用的任何結構化數據文件。

簡述Ansible適合的場景？

Ansible將編排與配置管理、供應和應用程式部署結合併統一在一個易於使用的平台上。Ansible的一些主要場景包括:

  • 配置管理：集中配置文件管理和部署是Ansible的一個常見場景。
  • 應用程式部署：當使用Ansible定義應用程式，並使用Ansible Tower管理部署時，團隊可以有效地管理從開發到生產的整個應用程式生命周期。
  • 部署：當在系統上部署或安裝應用程式時，Ansible和Ansible Tower可以幫助簡化供應系統的流程，無論是PXE啟動的裸金屬伺服器或虛擬機，還是從模板創建虛擬機或雲實例。
  • 持續交付：創建CI/CD管道需要許多團隊的協調和參與。如果沒有一個簡單的自動化平台，團隊協作很難完成。而Ansible playbook在應用程式的整個生命周期中可以保持適當的部署(和管理)
  • 安全性和審計：當安全策略在Ansible中定義時，可以將站點範圍的安全策略的掃描和修復集成到其他自動化流程中。安全性是部署的所有內容中不可或缺的一部分。
  • 編排：配置本身不能定義環境，需要定義多個配置如何交互，並確保可以將不同的部分作為一個整體來管理。

簡述Ansible Inventory？

Ansible中受管主機列在主機清單（inventory）文本文件中，清單還將這些系統組織成group，以便更容易地進行批量管理。一個Inventory定義了Ansible將管理的主機集合。這些主機還可以分配至組，可以對組進行批量管理。組可以包含子組，主機可以是多個組的成員。Inventory根據類型可分為靜態清單和動態清單：

  • 靜態主機Inventory可以由文本文件定義。
  • 動態主機Inventory可以由腳本或其他程式根據需要使用外部資訊提供者生成。

簡述Ansible配置文件優先順序？

Ansible 只使用最高優先順序配置文件中的設置，其它配置文件中的設置將被忽略。即使存在其他優先順序較低的文件，它們的設置也將被忽略，並且不會與所選配置文件中的設置相結合。
$ANSIBLE_CONFIG環境變數指定的任何文件都將覆蓋所有其他配置文件。如果沒有設置該變數，接下來將檢查運行ansible命令的目錄以查找ansible.cfg文件。如果該文件不存在，則檢查用戶的主目錄以查找.ansible.cfg文件。如上配置文件都不存在時，才使用全局/etc/ansible/ansible.cfg文件。

簡述Ansible ad-hoc命令？

Ad-Hoc命令是一種快速執行單個Ansible任務的方法，適合於不需要永久保存該任務，臨時執行的場景。Ad-Hoc是簡單的控制台操作，無需編寫劇本就可以運行。它們對於快速測試和更改非常有用。

簡述Ansible ad-hoc和playbook的區別？

  • Ad-Hoc 命令可以作為一次性命令對一組目標主機運行單個、簡單的任務。
  • Ad-Hoc 不適合複雜配置管理或編配場景，Ad-Hoc 一次只能調用一個模組和一組參數。當需要多個操作時，必須使用多個 Ad-Hoc 來執行。
  • playbook可以實現以一種簡易重複的方式對一組目標主機運行多個複雜的任務。
  • Playbook 是描述要在受管主機上實施的必要配置或程式性步驟的文件。
  • Playbook 為配置管理和部署提供了強大而靈活的解決方案。
  • Playbook 可以將冗長而複雜的管理任務轉變為可輕鬆重複的歷程，並且可預測成果然而。
  • playbook 是一個文本文件，其中包含一個或多個按順序運行的play的列表。
  • playbook中，可以將playbook中的tasks保存為人類可讀且可立即運行的形式。
  • play 是一組有序的任務，應該對從目錄中選擇的主機運行。

簡述Ansible變數？

Ansible 利用變數存儲整個 Ansible 項目文件中可重複使用的值，從而可以簡化項目的創建和維護，並減少錯誤的發生率。在定義Ansible變數時，通常有如下三種範圍的變數：

  • global範圍：從命令行或Ansible配置中設置的變數；
  • play範圍：在 play 和相關結構中設置的變數；
  • host範圍：inventory、facts 或 register 的變數，在主機組和個別主機上設置的變數。

簡述Ansible如何實現任務的循環？

簡單循環：

  • Ansible支援使用loop在一組item上迭代任務；
  • loop可以使用列表中的每個項、列表中每個文件的內容、生成的數字序列或使用更複雜的結構來重複任務。
  • 使用loop使管理員不必編寫使用相同模組的多個任務。

複雜（嵌套）循環：

  • with_nested鍵用於嵌套循環，循環在循環中運行。它需要一個包含兩個或多個列表的列表。例如，將一個列表劃分為兩個列表，任務將迭代第一個列表中的每一項與第二個列表中的每一項。

簡述Ansible hanlder？

Ansible模組被設計成冪等的，即在一個適當編寫的劇本中，劇本及其任務可以在不更改受管主機的情況下多次運行，除非它們需要進行更改以使受管主機達到所需的狀態。
然而，有時當一個任務對系統進行了更改後同時需要運行另一個任務。例如，對服務的配置文件的更改可能需要重新載入服務，以便更改後的配置生效。此時就需要使用hanlder程式。handler程式是響應由其他任務組成的通知的任務。每個handler程式都有一個全局惟一的名稱，並在劇本中任務塊的末尾觸發。
如果沒有任務通過名稱調用handler程式，它將不會運行。
如果一個或多個任務都調用handler程式，它將在劇中的所有其他任務完成後僅運行一次。
因為handler程式是任務，所以可以在handler程式中使用與處理任何其他任務相同的模組。通常，handler程式用於重新啟動主機和重新啟動服務。
handler程式可以視為非活動任務，只有在使用notify語句顯式調用時才會觸發這些任務。





簡述Ansible Block？

在 playbook 中， blocks 是囊括了任務的子句；
blocks 允許對任務進行邏輯分組，並可用於控制任務的執行方式，例如，管理員可以定義一組主要任務和一組附加任務，附加任務僅在第一組失敗時執行。為此，可利用三個關鍵字在 playbook 中使用塊：

  • block：定義要運行的主要任務；
  • rescue：定義將在 block 子句中定義的任務失敗時運行的任務；
  • always：定義始終都獨立運行的任務，不論 block 和 rescue 子句中定義的任務是成功還是失敗。

簡述Ansible如何處理play錯誤的？

Ansible審查每個任務的返回程式碼，以確定任務是否成功或失敗。默認情況下，當一個任務失敗時，Ansible會立即中止該主機上的其他操作，並跳過所有後續任務。
實際生產中，若希望即使任務失敗也能繼續執行play，Ansible也包含了多種特性用於管理任務錯誤：
忽略任務失敗：在任務中使用ignore_errors關鍵字忽略錯誤，即使任務失敗，也繼續在主機上執行playbook。


簡述Ansible角色？

數據中心有各種不同類型的主機。如web伺服器、資料庫伺服器，基於開發環境的伺服器。隨著時間的推移，具有處理所有這些情況的任務和人員的Ansible playbook將變得龐大而複雜。

  • 角色允許將複雜的劇本組織成獨立的、更小的劇本和文件。
  • 角色提供了一種從外部文件載入任務、處理程式和變數的方法。
  • 角色也可關聯和引用靜態的文件和模板。
  • 角色可以編寫成滿足普通用途需求，並且能被重複利用。
  • 定義角色的文件具有特定的名稱，並以嚴格的目錄結構進行組織。

簡述Ansible Galaxy？

Ansible Galaxy是一個由各種Ansible管理員和用戶編寫的Ansible角色的公共庫。它是一個包含數千個Ansible角色的歸檔文件，並且有一個可搜索的資料庫，幫助Ansible用戶識別可能幫助他們完成管理任務的角色。Ansible Galaxy包括指向新用戶和角色開發人員的文檔和影片的鏈接。

簡述Ansible如何控制任務的並行執行？

通過在所有主機上並行運行任務，Ansible可以對劇本的執行進行更多的控制。默認情況下，Ansible默認最多並行5個，因此它將同時在5台不同的機器上運行一個特定的任務。Ansible可以通過配置forks來設置並行執行任務數量。
同時Ansible也可以通過serial來減少ork數量所指定的並行書，serial關鍵字主要用於控制滾動更新，避免一次性更新過多的節點。

簡述Ansible故障後的排查思路？

  • 日誌判斷：默認情況下，Ansible沒有配置為將其輸出，記錄到任何日誌文件中。可通過ansible.cfg配置文件default部分中的log_path參數或$ANSIBLE_LOG環境變數進行配置。然後通過日誌進行定位。
  • Debug模組：調試模組是Ansible可用的模組之一，它可以更好地了解控制節點上正在進行的操作。這個模組可以在playbook執行時為某個變數提供值。
  • syntax-check：通過ansible-playbook 命令的 –syntax-check命選項檢查劇本的YAML語法。
  • diff：Ansible還提供了–diff選項。此選項報告對受管主機上的模板文件所做的更改。如果與–check選項一起使用，這些更改將顯示出來，而不是實際執行。從而判斷Ansible整個過程需要做何種更改。

開源應用

簡述Ceph的優勢及其特點？

Ceph是一個分散式的數據對象存儲，Ceph相對其他存儲系統具有如下優勢：

  • CRUSH演算法： ceph摒棄了傳統的集中式存儲元數據定址的方案，而使用CRUSH演算法完成數據的定址操作。能夠實現各類負載的副本放置規則，例如跨機房、機架感知等。Crush演算法有相當強大的擴展性，理論上支援數千個存儲節點，從而增強了Ceph彈性擴展和高可用性。
  • 高可用：通過CRUSH演算法指定副本的物理存儲位置以分隔故障域，支援數據強一致性，ceph可以忍受多種故障場景並自動嘗試並行修復。
  • 高擴展性：Ceph本身並沒有主控節點，擴展起來比較容易，並且理論上，它的性能會隨著磁碟數量的增加而線性增長。
  • 特性豐富：Ceph支援三種調用介面：對象存儲，塊存儲，文件系統掛載。三種方式可以一同使用。

Ceph主要特點如下：

  • 統一存儲；
  • 無任何單點故障；
  • 數據多份冗餘；
  • 存儲容量可擴展；
  • 自動容錯及故障自愈。

簡述Ceph存儲體系架構？

Ceph體系架構主要由RADOS和RADOS GW和RBD以及CephFS構成。

  • RADOS（Reliable, Autonomic Distributed Object Store）是Ceph的底層核心，RADOS本身也是分散式存儲系統，CEPH所有的存儲功能都是基於RADOS實現。RADOS由兩個組件組成：OSD和Monitor。
    • OSD主要提供存儲資源，每一個disk、SSD、RAID group或者一個分區都可以成為一個OSD，而每個OSD還將負責向該對象的複雜節點分發和恢復；
    • Monitor維護Ceph集群並監控Ceph集群的全局狀態，提供一致性的決策。
  • RADOS GW和RBD：RADOS GateWay、RBD其作用是在librados庫的基礎上提供抽象層次更高、更便於應用或客戶端使用的上層介面。其中，RADOS GW是一個提供與Amazon S3和Swift兼容的RESTful API的gateway，以供相應的對象存儲應用開發使用。 RBD則提供了一個標準的塊設備介面，常用於在虛擬化的場景下為虛擬機創建volume。
  • CEPHFS：CEPHFS則提供了POSIX介面，用戶可直接通過客戶端掛載使用。

簡述Ceph Pool有幾種類型？

Ceph存儲池Pool是Ceph存儲集群用於存儲對象的邏輯分區。池類型確定池用於確保數據持久性的保護機制，Ceph有兩種Pool類型：
replication類型：在集群中分布每個對象的多個副本。
erasure coding類型：將每個對象分割成塊，並將它們與其他擦除編碼塊一起分發，以使用自動糾錯機制保護對象。


簡述Ceph Pool、PG、ODDs的關係？

Ceph存儲池Pool是Ceph存儲集群用於存儲對象的邏輯分區。
Pool中存在一定的數量的PG，PG將對象存儲在一組由CRUSH演算法確定的osd中。
Ceph使用CRUSH演算法將對象分配給池中的一個PG，根據池的配置和CRUSH演算法，PG自動映射到一組OSDs。
一個PG里包含一堆對象，一個對象只能屬於一個PG。



簡述Ceph節點的角色？

所有Ceph存儲集群的部署都始於部署一個個Ceph節點、網路和Ceph存儲集群。Ceph存儲集群至少需要一個Ceph Monitor和兩個OSD守護進程。而運行Ceph文件系統客戶端時，則必須要有元數據伺服器（Metadata Server）。

  • Ceph OSDs：Ceph OSD守護進程（ Ceph OSD ）的功能是存儲數據，處理數據的複製、恢復、回填、再均衡，並通過檢查其他OSD守護進程的心跳來向Ceph Monitors提供一些監控資訊。當Ceph存儲集群設定為有2個副本時，至少需要2個OSD守護進程，集群才能達到active+clean狀態（Ceph默認有3個副本）。
  • Monitors：Ceph Monitor維護著展示集群狀態的各種圖表，包括監視器圖、OSD圖、歸置組（PG）圖、和CRUSH 圖。
  • MDSs：Ceph元數據伺服器（MDS）為Ceph文件系統存儲元數據（也就是說，Ceph塊設備和Ceph 對象存儲不使用MDS）。元數據伺服器使得POSIX文件系統的客戶端，可以在不對Ceph存儲集群造成負擔的前提下，執行諸如ls、find等基本命令。

簡述Ceph的適應場景？

Ceph的應用場景主要由它的架構確定，Ceph提供對象存儲、塊存儲和文件存儲。

  • LIBRADOS應用

Librados提供了應用程式對RADOS的直接訪問，目前Librados已經提供了對C、C++、Java、Python、Ruby和PHP的支援。

  • RADOSGW應用

此類場景基於Librados之上，增加了HTTP協議，提供RESTful介面並且兼容S3、Swfit介面。RADOSGW將Ceph集群作為分散式對象存儲，對外提供服務。

  • RBD應用

此類場景也是基於Librados之上的，細分為下面兩種應用場景。
第一種應用場景為虛擬機提供塊設備。通過Librbd可以創建一個塊設備（Container），然後通過QEMU/KVM附加到VM上。通過Container和VM的解耦，使得塊設備可以被綁定到不同的VM上。
第二種應用場景為主機提供塊設備。這種場景是傳統意義上的理解的塊存儲。
以上兩種方式都是將一個虛擬的塊設備分片存儲在RADOS中，都會利用數據條帶化提高數據並行傳輸，都支援塊設備的快照、COW（Copy-On-Write）克隆。最重要的是RBD還支援Live migration。


  • CephFS（Ceph文件系統）

此類應用是基於RADOS實現的PB級分散式文件系統，其中引入MDS（Meta Date Server），它主要為兼容POSIX文件系統提供元數據，比如文件目錄和文件元數據。

簡述Docker的特性？

Docker主要有如下特性：

  • 標準化
    • 保證一致的運行環境
    • 彈性伸縮，快速擴容
    • 方便遷移
    • 持續集成、持續交付與持續部署
  • 高性能
    • 不需要進行硬體虛擬以及運行完整的作業系統
  • 輕量級
    • 快速啟動
    • 隔離性
    • 進程隔離

簡述Docker容器的幾種狀態？

Docker容器可以有四種狀態：

  • 運行
  • 已暫停
  • 重新啟動
  • 已退出

簡述Dockerfile、Docker鏡像和Docker容器的區別？

Dockerfile 是軟體的原材料，Docker 鏡像是軟體的交付品，而 Docker 容器則可以認為是軟體的運行態。從應用軟體的角度來看，Dockerfile、Docker 鏡像與 Docker 容器分別代表軟體的三個不同階段，Dockerfile 面向開發，Docker 鏡像成為交付標準，Docker 容器則涉及部署與運維。

簡述Docker與KVM（虛擬機）的區別？

  • 容器部署簡單，虛擬機部署相對複雜。

虛擬化技術依賴物理CPU和記憶體，是硬體級別的；
而docker構建在作業系統上，利用作業系統的containerization技術，所以docker甚至可以在虛擬機上運行。

  • 容器秒級啟動，虛擬機通常分鐘級啟動。

傳統的虛擬化技術在構建系統的時候較為複雜，需要大量的人力；
而docker可以通過Dockfile來構建整個容器，重啟和構建速度很快。

  • 容器需要的資源（如磁碟、CPU、記憶體）相對更少。
  • 容器比較輕便，虛擬機相對較重。

虛擬化系統一般都是指作業系統級概念，比較複雜，稱為「系統」；
而docker開源而且輕量，稱為「容器」，單個容器適合部署少量應用，比如部署一個redis、一個memcached。

簡述Docker主要使用的技術？

容器主要使用如下技術：

  • Cgroup：資源控制
  • Namespace：訪問隔離
  • rootfs：文件系統隔離
  • 容器引擎（用戶態工具）：生命周期控制

簡述Docker體系架構？

Docker體系相對簡單，主要涉及如下5個組件：

  • Docker客戶端 – Docker

docker客戶端則扮演著docker服務端的遠程控制器，可以用來控制docker的服務端進程。

  • Docker服務端 – Docker Daemon

docker服務端是一個服務進程，管理著所有的容器。**

  • Docker鏡像 – Image

docker鏡像，一個能夠運行在docker容器上的一組程式文件，是一個只讀的模板，不包含任何動態數據。。

  • Docker容器 – Docker Container

docker容器，就是運行程式的載體，容器是鏡像運行時的實體。

  • Docker鏡像倉庫 — Registry

Docker倉庫是集中存放鏡像文件的場所，Docker倉庫分為公開倉庫（Public）和私有倉庫（Private）兩種形式。

簡述Docker如何實現網路隔離？

Docker利用了網路的命名空間特性，實現了不同容器之間的網路隔離。命名空間可以支援網路協議棧的多個實例，獨立的協議棧被隔離到不同的命名空間中。
因此處於不同命名空間中的網路棧是完全隔離的，彼此之間無法通訊。每個獨立的命名空間中可以有自己獨立的路由表及獨立的iptables設置來提供包轉發、NAT及IP包過濾等功能。

簡述Linux文件系統和Docker文件系統？

Linux文件系統：由bootfs和rootfs組成，bootfs主要包含bootloader和kernel，bootloader主要是引導載入kernel，當kernel被載入到記憶體之後bootfs就被卸載掉了。rootfs包含的就是典型linux系統中/dev,/proc,/bin,/etc等標準目錄。
Docker文件系統：Docker容器是建立在Aufs分層文件系統基礎上的，Aufs支援將不同的目錄掛載到同一個虛擬文件系統下，並實現一種layer的概念。Aufs將掛載到同一虛擬文件系統下的多個目錄分別設置成read-only，read-write以及whiteout-able許可權。docker 鏡像中每一層文件系統都是read-only。

簡述Docker網路模式？

Docker使用Linux的Namespaces技術來進行資源隔離，其中Network Namespace實現隔離網路。
一個Network Namespace提供了一份獨立隔離的網路環境，包括網卡、路由、Iptable規則等，Docker網路有如下四種模式：

  • host模式：host模式下容器將不會獲得獨立的Network Namespace，該模式下與宿主機共用一個Network Namespace。容器將不會虛擬出自己的網卡，不會配置獨有的IP等，而是使用宿主機的IP和埠。
  • container模式：Container 網路模式是 Docker 中一種較為特別的網路的模式，處於container模式下的 Docker 容器會共享其他容器的網路環境，因此，兩個或以上的容器之間不存在網路隔離，而配置container模式的容器又與宿主機以及除此之外其他的容器存在網路隔離。
  • none模式：none模式下，Docker容器擁有自己的Network Namespace，但是，並不為Docker容器進行任何網路配置和構造任何網路環境。Docker 容器採用了none 網路模式，那麼容器內部就只能使用loopback網路設備，不會再有其他的網路資源。Docker Container的none網路模式意味著不給該容器創建任何網路環境，容器只能使用127.0.0.1的本機網路。
  • bridge模式：bridge模式是Docker默認的網路設置，此模式會為每一個容器分配Network Namespace、設置IP等，並將該宿主機上的Docker容器連接到一個虛擬網橋上。

簡述Docker跨主機通訊的網路實現方式？

docker跨主機通訊按原理可通過以下三種方式實現：

  • 直接路由方式：直接在不同宿主機之間添加靜態路由；
  • 橋接方式（如pipework）：通過靜態指定容器IP為宿主機IP同一個網路的形式，即可實現。
  • Overlay隧道方式：使用overlay網路實現，Overlay網路指在現有網路層之上疊加的虛擬化技術，實現應用在網路上的承載，並能與其他網路業務分離，並且以基於IP的網路技術為主，如flannel、ovs+gre。

簡述flannel網路模型實現原理？

Flannel為每個host分配一個subnet，容器從subnet中分配IP，這些IP可以在host間路由，容器間無需使用nat和埠映射即可實現跨主機通訊。每個subnet都是從一個更大的IP池中劃分的，flannel會在每個主機上運flanneld的agent，負責從池子中分配subnet。
Flannel使用etcd存放網路配置、已分配的subnet、host的IP等資訊，Flannel數據包在主機間轉發是由backend實現的，目前已經支援UDP、VxLAN、host-gw、AWS VPC和GCE路由等多種backend。

簡述什麼是Apache伺服器？

Apache伺服器是一個非常流行、功能強大並且開源的Web伺服器，基於HTTP超文本傳輸協議運行，這一協議提供了伺服器和客戶端Web瀏覽器通訊的標準。它支援SSL、CGI文件、虛擬主機等許多功能特性。

簡述Apache虛擬主機？

Apache虛擬主機相當於一個在同一台伺服器中卻相互獨立的站點，從而實現一台主機對外提供多個 web 服務，每個虛擬主機之間是獨立的，互不影響的。Apache具有兩種類型的虛擬主機：基於名稱的虛擬主機和基於IP的虛擬主機。

簡述Apache的Worker MPM和Prefork MPM之間的區別？

它們都是MPM，Worker和Prefork有它們各自在Apache上的運行機制，取決於哪種模式啟動Apache。Worker MPM和Prefork MPM基本的區別在於它們產生子進程的處理過程。

  1. Prefork MPM中，一個主httpd進行被啟動，這個主進程會管理所有其它子進程為客戶端請求提供服務。Worker MPM中一個httpd進程被激活，則會使用不同的執行緒來為客戶端請求提供服務.
  2. Prefork MPM使用多個子進程，每一個進程帶有一個執行緒，Worker MPM使用多個子進程，每一個進程帶有多個執行緒。
  3. Prefork MPM中的連接處理，每一個進程一次處理一個連接而在Worker MPM中每一個執行緒一次處理一個連接。
  4. 記憶體佔用Prefork MPM佔用龐大的記憶體，而Worker MPM佔用更小的記憶體。

簡述Nginx是什麼及其主要特點？

Nginx是一款自由的、開源的、高性能的HTTP伺服器和反向代理伺服器。可以作為一個HTTP伺服器進行網站的發布處理，同時也可以作為反向代理進行負載均衡的實現。其主要特點有：

  • 佔有記憶體少，並發能力強。
  • Nginx使用基於事件驅動架構，使得其可以支援數以百萬級別的TCP連接。
  • 高度的模組化和自由軟體許可證使得第三方模組非常豐富。
  • Nginx是一個跨平台伺服器，可以運行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等作業系統上。

簡述Nginx和Apache的差異？

  • Nginx是一個基於事件的Web伺服器，Apache是一個基於流程的伺服器；
  • Nginx所有請求都由一個執行緒處理，Apache單個執行緒處理單個請求；
  • Nginx避免子進程的概念，Apache是基於子進程的；
  • Nginx在記憶體消耗和連接方面更好，Apache在記憶體消耗和連接方面一般；
  • Nginx的性能和可伸縮性不依賴於硬體，Apache依賴於CPU和記憶體等硬體；
  • Nginx支援熱部署，Apache不支援熱部署；
  • Nginx對於靜態文件處理具有更高效率，Apache相對一般；
  • Nginx在反向代理場景具有明顯優勢，Apache相對一般。

簡述Nginx主要應用的場景？

基於Nginx的特性，Nginx的應用場景主要有：

  • http伺服器：Nginx是一個http服務可以獨立提供http服務，可以做網頁靜態伺服器。
  • 虛擬主機：可以實現在一台伺服器虛擬出多個網站。
  • 正反代理：負載均衡或加速，當網站的訪問量達到一定程度後，單台伺服器不能滿足用戶的請求時，需要用多台伺服器集群可以使用Nginx做反向代理，並且多台伺服器可以平均分擔負載。

簡述Nginx HTTP連接和請求的關係？

HTTP是建立在TCP上，一次HTTP請求需要先建立TCP三次握手（稱為TCP連接），在連接的基礎上再進行HTTP請求。
HTTP請求建立在一次TCP連接基礎上，對於HTTP會話，一次TCP連接可以建立多次HTTP請求。

簡述Nginx支援哪些訪問控制方式？

  • 連接限制：Nginx自帶的limit_conn_module模組（TCP連接頻率限制模組）和limit_req_mudule模組（HTTP請求頻率限制模組）支援對連接頻率以及請求頻率、來源進行限制，通常可可以用來防止DDOS攻擊。
  • IP限制：Nginx使用http_access_module模組可實現基於IP的訪問控制，但通過代理可以繞過限制。
  • 帳號限制：Nginx使用http_auth_basic_module模組可實現用戶密碼的登錄限制。
  • 流量限制：Nginx使用http_core_moduleblock模組可實現客戶端傳送響應的速率限制。

簡述Nginx Master進程和Worker節點？

master進程主要用來管理worker進程，包含：接收來自外界的訊號，向各worker進程發送訊號，監控worker進程的運行狀態，當worker進程退出後(異常情況下)，會自動重新啟動新的worker進程。
worker進程則是處理基本的網路事件。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。

簡述Nginx如何處理HTTP請求？

首先，Nginx 在啟動時，會解析配置文件，獲取需要監聽的埠與 IP 地址，然後在 Nginx 的 Master 進程裡面先初始化好這個監控的Socket（創建 Socket，設置 addr、綁定ip和埠，然後listen 監聽)。
然後，再 fork 出多個子進程出來。
之後，子進程會競爭 accept 新的連接。此時，客戶端就可以向 nginx 發起連接了。當客戶端與nginx完成TCP三次握手，與 nginx 建立好一個連接後。此時，某一個子進程會 accept 成功，得到這個建立好的連接的 Socket ，然後創建 nginx 對連接的封裝。
接著，設置讀寫事件處理函數，並添加讀寫事件來與客戶端進行數據的交換。
最後，Nginx 或客戶端來主動關掉連接，完成整個HTTP請求的處理。




簡述Nginx對於HTTP請求採用哪兩種機制進行處理？

Nginx 是一個高性能的 Web 伺服器，能夠同時處理大量的並發請求。它結合多進程機制和非同步非阻塞機制 。

  • 多進程機制：伺服器每當收到一個客戶端請求時，就有伺服器主進程 （master process）生成一個子進程（worker process）和客戶端建立連接進行交互，直到連接斷開，該子進程就結束了。
    • 使用進程的好處是各個進程之間相互獨立，不需要加鎖，減少了使用鎖對性能造成影響。
    • 其次，採用獨立的進程，可以讓進程互相之間不會影響 ，如果一個進程發生異常退出時，其它進程正常工作，master進程則很快啟動新的worker進程，確保服務不會中斷，從而將風險降到最低。
    • 缺點是作業系統生成一個子進程需要進行 記憶體複製等操作，在資源和時間上會產生一定的開銷。當有大量請求時，會導致系統性能下降 。
  • 非同步非阻塞機制：每個工作進程使用非同步非阻塞方式，可以處理多個客戶端請求 。
    • 當某個工作進程接收到客戶端請求以後，調用 IO 進行處理，如果不能立即得到結果，就去處理其他請求（即為非阻塞 ）。而客戶端在此期間也無需等待響應，可以進行其他任務（即為 非同步 ）。
    • 當IO返回時，就會通知此工作進程。該進程得到通知，暫時掛起當前處理的事務去響應客戶端請求 。

簡述Nginx支援哪些類型的虛擬主機？

對於Nginx而言，每一個虛擬主機相當於一個在同一台伺服器中卻相互獨立的站點，從而實現一台主機對外提供多個 web 服務，每個虛擬主機之間是獨立的，互不影響的。通過 Nginx 可以實現虛擬主機的配置，Nginx 支援三種類型的虛擬主機配置：

  • 基於 IP 的虛擬主機（較少使用）
  • 基於域名的虛擬主機
  • 基於埠的虛擬主機

簡述Nginx快取及其作用？

快取對於Web至關重要，尤其對於大型高負載Web站點。Nginx快取可作為性能優化的一個重要手段，可以極大減輕後端伺服器的負載。通常對於靜態資源，即較少經常更新的資源，如圖片，css或js等進行快取，從而在每次刷新瀏覽器的時候，不用重新請求，而是從快取裡面讀取，這樣就可以減輕伺服器的壓力。

簡述Nginx作為代理快取後，客戶端訪問的過程？

使用Nginx作為代理快取後，可加快客戶端的訪問，其過程大致如下：

  1. 第一步：客戶端第一次向Nginx請求數據A；
  2. 第二步：當Nginx發現快取中沒有數據A時，會向服務端請求數據A；
  3. 第三步：服務端接收到Nginx發來的請求，則返回數據A到Nginx，並且快取在Nginx；
  4. 第四步：Nginx返回數據A給客戶端應用；
  5. 第五步：客戶端第二次向Nginx請求數據A；
  6. 第六步：當Nginx發現快取中存在數據A時，則不會請求服務端；
  7. 第七步：Nginx把快取中的數據A返回給客戶端應用。

簡述Nginx代理及其類型？

代理（forward）是一個位於客戶端和原始伺服器(origin server)之間的伺服器，即代理伺服器。為了從原始伺服器取得內容，客戶端向代理伺服器發送一個請求並指定目標原始伺服器，然後代理伺服器向原始伺服器轉交請求並將獲得的內容返回給客戶端。
其通常有如下三種代理模式：

  • 正向代理（forward proxy）：一個位於客戶端和原始伺服器(origin server)之間的伺服器，為了從原始伺服器取得內容，客戶端向代理髮送一個請求並指定目標(原始伺服器)，然後代理向原始伺服器轉交請求並將獲得的內容返回給客戶端。
  • 反向代理（reverse proxy）：指以代理伺服器來接受 Internet上的連接請求，然後將請求，發給內部網路上的伺服器並將從伺服器上得到的結果返回給 Internet 上請求連接的客戶端，此時代理伺服器對外就表現為一個反向代理伺服器。
  • 透明代理

簡述Nginx盜鏈及如何防護？

盜鏈指的是在自己的介面展示非本伺服器上的內容，通過技術手段獲得其他伺服器的資源。繞過他人資源展示頁面，在自己頁面向用戶提供此內容，從而減輕自己伺服器的負擔，因為真實的空間和流量來自其他伺服器。
因此，通常為了避免被盜鏈，通常Web伺服器建議配置防盜鏈。Nginx防盜鏈其主要防盜鏈思路是能區別哪些請求是非正常用戶請求，對於非正常用戶的請求直接回饋403或重定向至其他頁面。

簡述Nginx負載均衡的意義？

負載均衡是將負載分攤到多個操作單元上執行，從而提高服務的可用性和響應速度，帶給用戶更好的體驗。對於Web應用，通過負載均衡，可以將一台伺服器的工作擴展到多台伺服器中執行，提高整個網站的負載能力。其本質採用一個調度者，保證所有後端伺服器都將性能充分發揮，從而保持伺服器集群的整體性能最優，這就是負載均衡。

簡述Nginx負載均衡的優勢？

Nginx作為負載均衡器具有極大的優勢，主要體現在：

  • 高並發連接
  • 記憶體消耗少
  • 配置文件非常簡單
  • 成本低廉
  • 支援Rewrite重寫規則
  • 內置的健康檢查功能
  • 節省頻寬
  • 穩定性高

簡述Nginx負載均衡主要的均衡機制（策略）？

Nginx作為負載均衡器具有極大的優勢，其負載均衡策略可以劃分為兩大類：內置策略和擴展策略，擴展策略為第三方提供。

  • 內置策略
    • 輪詢（默認）：Nginx根據請求次數，將每個請求均勻分配到每台伺服器；
    • weight：加權輪詢，加權輪詢則是在第一種輪詢的基礎上對後台的每台服務賦予權重，伺服器的權重比例越大，被分發到的概率也就越大。
    • least_conn：最少連接，將請求分配給連接數最少的伺服器。Nginx會統計哪些伺服器的連接數最少。
    • ip_hash：IP 哈希，綁定處理請求的伺服器。第一次請求時，根據該客戶端的IP算出一個HASH值，將請求分配到集群中的某一台伺服器上。後面該客戶端的所有請求，都將通過HASH演算法，找到之前處理這台客戶端請求的伺服器，然後將請求交給它來處理。
  • 擴展策略
    • fair：按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
    • url_hash：按訪問url的hash結果來分配請求，使每個url定向到同一個後端伺服器，後端伺服器為快取時比較有效。

簡述Nginx負載均衡（反向代理）通過什麼方式實現後端RS的健康檢查？

nginx負載均衡（反向代理）包含內置的或第三方擴展來實現伺服器健康檢測的。如果後端某台伺服器響應失敗，nginx會標記該台伺服器失效，在特定時間內，請求不分發到該台上。

  • fail_timeout：該指令定義了多長時間伺服器將被標記為失敗。在fail_timeout後，伺服器還是failed，nginx將檢測該伺服器是否存活，如果探測成功，將標記為活的。
  • max_fails：該指令設置在fail_timeout期間內連續的失敗嘗試。默認情況下，max_fails為1。如果被設置為0，該伺服器的健康檢測將禁用。

簡述Nginx動靜分離？

為了提高網站的響應速度，減輕程式伺服器（Tomcat，Jboss等）的負載，對於靜態資源，如圖片、js、css等文件，可以在反向代理伺服器中進行快取，這樣瀏覽器在請求一個靜態資源時，代理伺服器就可以直接處理，而不用將請求轉發給後端伺服器。對於用戶請求的動態文件，如servlet、jsp，則轉發給Tomcat，Jboss伺服器處理，這就是動靜分離。即動態文件與靜態文件的分離。

簡述Nginx動靜分離的原理？

動靜分離可通過location對請求url進行匹配，將網站靜態資源（HTML，JavaScript，CSS，img等文件）與後台應用分開部署，提高用戶訪問靜態程式碼的速度，降低對後台應用訪問。通常將靜態資源放到nginx中，動態資源轉發到tomcat伺服器中。

簡述Nginx同源策略？

同源策略是一個安全策略。同源，指的是協議，域名，埠相同。瀏覽器處於安全方面的考慮，只允許本域名下的介面交互，不同源的客戶端腳本，在沒有明確授權的情況下，不能讀寫對方的資源。

簡述Nginx跨域及如何實現？

從一個域名的網頁去請求另一個域名的資源，或任何協議、域名、埠有一處不同的請求，就被當作是跨域，即都被當成不同源。
通常基於安全考慮，Nginx啟用了同源策略，即限制了從同一個源載入的文檔或腳本如何與來自另一個源的資源進行交互。這是一個用於隔離潛在惡意文件的重要安全機制。
Nginx若要實現跨域訪問，可通過JSONP和CORS進行實現。


簡述Nginx重定向及其使用的場景？

重定向(Redirect)指通過各種方法將各種網路請求重新定個方向轉到其它位置（如：網頁重定向、域名的重定向、路由選擇的變化也是對數據報文經由路徑的一種重定向）。
URL重寫是指通過配置conf文件，以讓網站的URL中達到某種狀態時則定向/跳轉到某個規則，比如常見的偽靜態、301重定向、瀏覽器定向等。當客戶端瀏覽某個網址時，將其訪問導向到另一個網址的技術。
其主要場景有如下兩個：

  • 將一串很長的網址，轉成較短的網址，從而實現便於傳播、易於記憶。
  • 調整或更換Web伺服器，網址（域名）又必須要變更（如訪問目錄、訪問擴展名HTML變為PHP、訪問域名），為了能使舊的訪問依舊生效，從而實現自動重定向到新的網站。

簡述Nginx地址重寫、地址轉發、反向代理？

地址重寫：為了實現地址的標準化，如地址欄中中輸入 www.baidu.com. 也可以輸入 www.baidu.cn。最後都會被重寫到 www.baidu.com 上。瀏覽器的地址欄也會顯示www.baidu.com。即nginx把收到客戶端請求的內容所對應的伺服器地址發給客戶端，讓客戶端自己去獲取，nginx同時返回302正確資訊。
地址轉發：指在網路數據傳輸過程中數據分組到達路由器或橋接器後，該設備通過檢查分組地址並將數據轉發到最近的區域網的過程。
反向代理：當瀏覽器訪問網站時，nginx反向代理伺服器會代替客戶端向後端伺服器查找所需的內容，然後nginx反向代理伺服器會把查找的內容返回給客戶端。


簡述Nginx地址重寫和地址轉發的差異？

地址重寫和地址轉發有以下不同點：

  • 地址重寫會改變瀏覽器中的地址，使之變成重寫成瀏覽器最新的地址。而地址轉發不會改變瀏覽器的地址的。
  • 地址重寫會產生兩次請求，而地址轉發只會有一次請求。
  • 地址轉發一般發生在同一站點項目內部，而地址重寫且不受限制。
  • 地址轉發的速度比地址重定向快。

簡述Nginx 301和302重定向及其區別？

301和302狀態碼都表示重定向，表示瀏覽器在拿到伺服器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址可以從響應的Location首部中獲取（客戶端輸入的地址A瞬間變成了另一個地址B）。其主要差異為：
301：代表永久性轉移(Permanently Moved)：舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換為重定向之後的網址；
302：代表暫時性轉移(Temporarily Moved)：舊地址A的資源還在（仍然可以訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。


簡述Nginx高可用的常見方案？

Keepalived + Nginx 實現Nginx的高可用：通過Keepalived來實現同一個虛擬IP映射到多台Nginx代理伺服器，從而實現Nginx的高可用性。
Heartbeat + Nginx 實現Nginx的高可用：通過Heartbeat的心跳檢測和資源接管、集群中服務的監測、失效切換等功能，結合Nginx來實現高可用性。

簡述SSL和HTTPS？

SSL（Secure Socket Layer）安全套接字層是一種數字證書，它使用ssl協議在瀏覽器和web server之間建立一條安全通道，數據資訊在client與server之間的安全傳輸。
HTTPS（Hypertext Transfer Protocol Secure）是超文本傳輸協議和SSL/TLS的組合，用以提供加密通訊及對網路伺服器身份的鑒定。
HTTPS也可以理解為HTTP over SSL，即HTTP連接建立在SSL安全連接之上。


簡述NoSQL是什麼？

NoSQL，指的是非關係型的資料庫。NoSQL 有時也稱作 Not Only SQL（意即”不僅僅是SQL”） 的縮寫，其顯著特點是不使用SQL作為查詢語言，數據存儲不需要特定的表格模式。

簡述NoSQL（非關係型）資料庫和SQL（關係型）資料庫的區別？

NoSQL和SQL的主要區別有如下區別：

  • 存儲方式：
    • 關係型資料庫是表格式的，因此存儲在表的行和列中。他們之間很容易關聯協作存儲，提取數據很方便。
    • NoSQL資料庫則與其相反，它是大塊的組合在一起。通常存儲在數據集中，就像文檔、鍵值對或者圖結構。
  • 存儲結構
    • 關係型資料庫對應的是結構化數據，數據表都預先定義了結構（列的定義），結構描述了數據的形式和內容。預定義結構帶來了可靠性和穩定性，但是修改這些數據比較困難。
    • NoSQL資料庫基於動態結構，使用與非結構化數據。由於NoSQL資料庫是動態結構，可以很容易適應數據類型和結構的變化。
  • 存儲規範
    • 關係型資料庫的數據存儲為了更高的規範性，把數據分割為最小的關係表以避免重複，獲得精簡的空間利用。
    • NoSQL數據存儲在平面數據集中，數據經常可能會重複。單個資料庫很少被分隔開，而是存儲成了一個整體，這樣整塊數據更加便於讀寫 。
  • 存儲擴展
    • 關係型資料庫數據存儲在關係表中，操作的性能瓶頸可能涉及到多個表，需要通過提升電腦性能來克服，因此更多是採用縱向擴展
    • NoSQL資料庫是橫向擴展的，它的存儲天然就是分散式的，可以通過給資源池添加更多的普通資料庫伺服器來分擔負載。
  • 查詢方式
    • 關係型資料庫通過結構化查詢語言來操作資料庫（即通常說的SQL）。SQL支援資料庫CURD操作的功能非常強大，是業界的標準用法。
    • NoSQL查詢以塊為單元操作數據，使用的是非結構化查詢語言（UnQl），它是沒有標準的。
    • 關係型資料庫表中主鍵的概念對應NoSQL中存儲文檔的ID。
    • 關係型資料庫使用預定義優化方式（比如索引）來加快查詢操作，而NoSQL更簡單更精確的數據訪問模式。
  • 事務
    • 關係型資料庫遵循ACID規則（原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)）。
    • NoSQL資料庫遵循BASE原則（基本可用（Basically Availble）、軟/柔性事務（Soft-state ）、最終一致性（Eventual Consistency））。
    • 由於關係型資料庫的數據強一致性，所以對事務的支援很好。關係型資料庫支援對事務原子性細粒度控制，並且易於回滾事務。
    • NoSQL資料庫是在CAP（一致性、可用性、分區容忍度）中任選兩項，因為基於節點的分散式系統中，不可能同時全部滿足，所以對事務的支援不是很好。 

簡述NoSQL（非關係型）資料庫和SQL（關係型）資料庫的各自主要代表？

SQL：MariaDB、MySQL、SQLite、SQLServer、Oracle、PostgreSQL。
NoSQL代表：Redis、MongoDB、Memcache、HBASE。

簡述MongoDB及其特點？

MongoDB是一個開源的、基於分散式的、面向文檔存儲的非關係型資料庫。是非關係型資料庫當中功能最豐富、最像關係資料庫的。其主要特點如下：
查詢豐富：MongoDB最大的特點是支援的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支援對數據建立索引。
面向文檔：文檔就是存儲在MongoDB中的一條記錄,是一個由鍵值對組成的數據結構。
模式自由：MongoDB每一個Document都包含了元數據資訊，每個文檔之間不強迫要求使用相同的格式，同時他們也支援各種索引。 
高可用性：MongoDB支援在複製集(Replica Set)通過非同步複製達到故障轉移，自動恢復，集群中主伺服器崩潰停止服務和丟失數據，備份伺服器通過選舉獲得大多數投票成為主節點，以此來實現高可用。
水平拓展：MongoDB支援分片技術，它能夠支援並行處理和水平擴展。
支援豐富：MongoDB另外還提供了豐富的BSON數據類型，還有MongoDB的官方不同語言的driver支援(C/C++、C#、Java、Node.js、Perl、PHP、Python、Ruby、Scala)。






簡述MongoDB的優勢有哪些？

  • 面向文檔的存儲：以 JSON 格式的文檔保存數據。
  • 任何屬性都可以建立索引。
  • 複製以及高可擴展性。
  • 自動分片。
  • 豐富的查詢功能。
  • 快速的即時更新。

簡述MongoDB適應的場景和不適用的場景？

MongoDB屬於典型的非關係型資料庫。

  • 主要適應場景
    • 網站實時數據：MongoDB 非常適合實時的插入，更新與查詢，並具備網站實時數據存儲所需的複製及高度伸縮性。
    • 數據快取：由於性能很高，MongoDB 也適合作為資訊基礎設施的快取層。在系統重啟之後，由 MongoDB 搭建的持久化快取層可以避免下層的數據源過載。
    • 高伸縮性場景：MongoDB 非常適合由數十或數百台伺服器組成的資料庫。
    • 對象或 JSON 數據存儲：MongoDB 的 BSON 數據格式非常適合文檔化格式的存儲及查詢。
  • 不適應場景
    • 高度事務性系統：例如銀行或會計系統。傳統的關係型資料庫目前還是更適用於需要大量原子性複雜事務的應用程式。
    • 傳統的商業智慧應用：針對特定問題的 BI 資料庫會對產生高度優化的查詢方式。對於此類應用，數據倉庫可能是更合適的選擇。
    • 需要複雜 SQL 查詢的場景。

簡述MongoDB中的庫、集合、文檔？

  • 庫：MongoDB可以建立多個資料庫，MongoDB默認資料庫為”db”。MongoDB的單個實例可以容納多個獨立的資料庫，每一個都有自己的集合和許可權，不同的資料庫也放置在不同的文件中。
  • 集合：MongoDB集合就是 MongoDB 文檔組，類似於 RDBMS （關係資料庫中的表格）。集合存在於資料庫中，集合沒有固定的結構。
  • 文檔：MongoDB的Document是一組鍵值(key-value)對(即 BSON)，相當於關係型資料庫的行。且不需要設置相同的欄位，並且相同的欄位不需要相同的數據類型。

簡述MongoDB支援的常見數據類型？

MongoDB支援豐富的數據類型，常見的有：

  • String：字元串。存儲數據常用的數據類型。
  • Integer：整型數值。用於存儲數值。
  • Boolean：布爾值。用於存儲布爾值（真/假）。
  • Array：用於將數組或列表或多個值存儲為一個鍵。
  • Date：日期時間。用 UNIX 時間格式來存儲當前日期或時間。
  • Binary Data：二進位數據。用於存儲二進位數據。
  • Code：程式碼類型。用於在文檔中存儲 JavaScript 程式碼。
  • Regular expression：正則表達式類型。用於存儲正則表達式。

簡述MongoDB索引及其作用？

索引通常能夠極大的提高查詢的效率，如果沒有索引，MongoDB在讀取數據時必須掃描集合中的每個文件並選取那些符合查詢條件的記錄。
這種掃描全集合的查詢效率是非常低的，特別在處理大量的數據時，查詢可能要花費幾十秒甚至幾分鐘，這對網站的性能是非常致命的。
索引是特殊的數據結構，索引存儲在一個易於遍歷讀取的數據集合中，索引是對資料庫表中一列或多列的值進行排序的一種結構。


簡述MongoDB常見的索引有哪些？

MongoDB常見的索引有：

  • 單欄位索引（Single Field Indexes）
  • 符合索引（Compound Indexes）
  • 多鍵索引（Multikey Indexes）
  • 全文索引（Text Indexes）
  • Hash索引（Hash Indexes）
  • 通配符索引（Wildcard Indexes）

簡述MongoDB複製（本）集原理？

mongodb的複製至少需要兩個節點。其中一個是主節點，負責處理客戶端請求，其餘的都是從節點，負責複製主節點上的數據。
mongodb各個節點常見的搭配方式為：一主一從、一主多從。
主節點記錄在其上的所有操作oplog，從節點定期輪詢主節點獲取這些操作，然後對自己的數據副本執行這些操作，從而保證從節點的數據與主節點一致。


簡述MongoDB的複製過程？

Primary節點寫入數據，Secondary通過讀取Primary的oplog（即Primary的oplog.rs表）得到複製資訊，開始複製數據並且將複製資訊寫入到自己的oplog。如果某個操作失敗，則備份節點停止從當前數據源複製數據。如果某個備份節點由於某些原因掛掉了，當重新啟動後，就會自動從oplog的最後一個操作開始同步。同步完成後，將資訊寫入自己的oplog，由於複製操作是先複製數據，複製完成後再寫入oplog，有可能相同的操作會同步兩份，MongoDB設定將oplog的同一個操作執行多次，與執行一次的效果是一樣的。
當Primary節點完成數據操作後，Secondary的數據同步過程如下：
1：檢查自己local庫的oplog.rs集合找出最近的時間戳。
2：檢查Primary節點local庫oplog.rs集合，找出大於此時間戳的記錄。
3：將找到的記錄插入到自己的oplog.rs集合中，並執行這些操作。




簡述MongoDB副本集及其特點？

MongoDB副本集是一組Mongod維護相同數據集的實例，副本集可以包含多個數據承載點和多個仲裁點。在承載數據的節點中，僅有一個節點被視為主節點，其他節點稱為次節點。
主要特點：

  • N 個節點的集群，任何節點可作為主節點，由選舉產生；
  • 最小構成是：primary，secondary，arbiter，一般部署是：primary，2 secondary。
  • 所有寫入操作都在主節點上，同時具有自動故障轉移，自動恢復；
  • 成員數應該為奇數，如果為偶數的情況下添加arbiter，arbiter不保存數據，只投票。

簡述MongoDB有哪些特殊成員？

MongoDB中Secondary角色存在一些特殊的成員類型：

  • Priority 0（優先順序0型）：不能升為主，可以用於多數據中心場景；
  • Hidden（隱藏型）：對客戶端來說是不可見的，一般用作備份或統計報告用；
  • Delayed（延遲型）：數據比副集晚，一般用作 rolling backup 或歷史快照。
  • Vote（投票型）：僅參與投票。

簡述MongoDB分片集群？

MongoDB分片集群（Sharded Cluster）：主要利用分片技術，使數據分散存儲到多個分片（Shard）上，來實現高可擴展性。
分片是將數據水平切分到不同的物理節點。當數據量越來越大時，單台機器有可能無法存儲數據或讀取寫入吞吐量有所降低，利用分片技術可以添加更多的機器來應對數據量增加以及讀寫操作的要求。

簡述MongoDB分片集群相對副本集的優勢？

MongoDB分片集群主要可以解決副本集如下的不足：

  • 副本集所有的寫入操作都位於主節點；
  • 延遲的敏感數據會在主節點查詢；
  • 單個副本集限制在12個節點；
  • 當請求量巨大時會出現記憶體不足；
  • 本地磁碟不足；
  • 垂直擴展價格昂貴。

簡述MongoDB分片集群的優勢？

MongoDB分片集群主要有如下優勢：

  • 使用分片減少了每個分片需要處理的請求數：通過水平擴展，群集可以提高自己的存儲容量。比如，當插入一條數據時，應用只需要訪問存儲這條數據的分片。
  • 使用分片減少了每個分片存儲的數據：分片的優勢在於提供類似線性增長的架構，提高數據可用性，提高大型資料庫查詢伺服器的性能。當MongoDB單點資料庫伺服器存儲成為瓶頸、單點資料庫伺服器的性能成為瓶頸或需要部署大型應用以充分利用記憶體時，可以使用分片技術。

簡述MongoDB分片集群的架構組件？

MongoDB架構組件主要有：

  • Shard：用於存儲實際的數據塊，實際生產環境中一個shard server角色可由幾台機器組成一個replica set承擔，防止主機單點故障。
  • Config Server：mongod實例，存儲了整個 ClusterMetadata，其中包括 chunk資訊。
  • Query Routers：前端路由，客戶端由此接入，且讓整個集群看上去像單一資料庫，前端應用可以透明使用。

簡述MongoDB分片集群和副本集群的區別？

副本集不是為了提高讀性能存在的，在進行oplog的時候，讀操作是被阻塞的；
提高讀取性能應該使用分片和索引，它的存在更多是作為數據冗餘，備份。

簡述MongoDB的幾種分片策略及其相互之間的差異？

MongoDB的數據劃分是基於集合級別為標準，通過shard key來劃分集合數據。主要分片策略有如下三種：

  • 範圍劃分：通過shard key值將數據集劃分到不同的範圍就稱為基於範圍劃分。對於數值型的shard key：可以虛構一條從負無窮到正無窮的直線（理解為x軸），每個shard key 值都落在這條直線的某個點上，然後MongoDB把這條線劃分為許多更小的沒有重複的範圍成為塊（chunks），一個chunk就是某些最小值到最大值的範圍。
  • 散列劃分：MongoDB計算每個欄位的hash值，然後用這些hash值建立chunks。基於散列值的數據分布有助於更均勻的數據分布，尤其是在shard key單調變化的數據集中。
  • 自定義標籤劃分：MongoDB支援通過自定義標籤標記分片的方式直接平衡數據分布策略，可以創建標籤並且將它們與shard key值的範圍進行關聯，然後分配這些標籤到各個分片上，最終平衡器轉移帶有標籤標記的數據到對應的分片上，確保集群總是按標籤描述的那樣進行數據分布。標籤是控制平衡器行為及集群中塊分布的主要方法。

差異：

  • 基於範圍劃分對於範圍查詢比較高效。假設在shard key上進行範圍查詢，查詢路由很容易能夠知道哪些塊與這個範圍重疊，然後把相關查詢按照這個路線發送到僅僅包含這些chunks的分片。
  • 基於範圍劃分很容易導致數據不均勻分布，這樣會削弱分片集群的功能。
  • 基於散列劃分是以犧牲高效範圍查詢為代價，它能夠均勻的分布數據，散列值能夠保證數據隨機分布到各個分片上。

簡述MongoDB分片集群採取什麼方式確保數據分布的平衡？

新加入的數據及伺服器都會導致集群數據分布不平衡，MongoDB採用兩種方式確保數據分布的平衡：

  • 拆分

拆分是一個後台進程，防止塊變得太大。當一個塊增長到指定塊大小的時候，拆分進程就會塊一分為二，整個拆分過程是高效的。不會涉及到數據的遷移等操作。

  • 平衡

平衡器是一個後台進程，管理塊的遷移。平衡器能夠運行在集群任何的mongd實例上。當集群中數據分布不均勻時，平衡器就會將某個分片中比較多的塊遷移到擁有塊較少的分片中，直到數據分片平衡為止。
分片採用後台操作的方式管理著源分片和目標分片之間塊的遷移。在遷移的過程中，源分片中的塊會將所有文檔發送到目標分片中，然後目標分片會獲取並應用這些變化。最後，更新配置伺服器上關於塊位置元數據。

簡述MongoDB備份及恢復方式？

mongodb備份恢復方式通常有以下三種：

  • 文件快照方式：此方式相對簡單，需要系統文件支援快照和mongod必須啟用journal。可以在任何時刻創建快照。恢復時，確保沒有運行mongod，執行快照恢復操作命令，然後啟動mongod進程，mongod將重放journal日誌。
  • 複製數據文件方式：直接拷貝數據目錄下的一切文件，但是在拷貝過程中必須阻止數據文件發生更改。因此需要對資料庫加鎖，以防止數據寫入。恢復時，確保mongod沒有運行，清空數據目錄，將備份的數據拷貝到數據目錄下，然後啟動mongod。
  • 使用mongodump和mongorestore方式：在Mongodb中我們使用mongodump命令來備份MongoDB數據。該命令可以導出所有數據到指定目錄中。恢復時，使用mongorestore命令來恢復MongoDB數據。該命令可以從指定目錄恢復相應數據。

簡述MongoDB的聚合操作？

聚合操作能夠處理數據記錄並返回計算結果。聚合操作能將多個文檔中的值組合起來，對成組數據執行各種操作，返回單一的結果。它相當於 SQL 中的 count(*) 組合 group by。對於 MongoDB 中的聚合操作，應該使用aggregate()方法。

簡述MongoDB中的GridFS機制？

GridFS是一種將大型文件存儲在MongoDB中的文件規範。使用GridFS可以將大文件分隔成多個小文檔存放，這樣我們能夠有效的保存大文檔，而且解決了BSON對象有限制的問題。

簡述MongoDB針對查詢優化的措施？

MongoDB查詢優化大致可能從如下步驟著手：

  • 第一步：找出慢速查詢

如下方式開啟內置的查詢分析器,記錄讀寫操作效率：
db.setProfilingLevel(n,{m}),n的取值可選0,1,2；

  • 0：默認值，表示不記錄；
  • 1：表示記錄慢速操作，如果值為1，m必須賦值單位為ms，用於定義慢速查詢時間的閾值；
  • 2：表示記錄所有的讀寫操作。

查詢監控結果：監控結果保存在一個特殊的集合system.profile里。

  • 第二步：分析慢速查詢

找出慢速查詢的原因，通常可能的原因有：應用程式設計不合理、不正確的數據模型、硬體配置問題、缺少索引等

  • 第三部：根據不同的分析結果進行優化，如建立索引。

簡述MongoDB的更新操作是否會立刻fsync到磁碟？

不會，磁碟寫操作默認是延時執行的，寫操作可能在兩三秒（默認在60秒內）後到達磁碟，可通過syncPeriodSecs參數進行配置。

簡述MySQL索引及其作用？

是資料庫管理系統中一個排序的數據結構，根據不同的存儲引擎索引分為Hash索引、B+樹索引等。常見的InnoDB存儲引擎的默認索引實現為：B+樹索引。
索引可以協助快速查詢、更新資料庫表中數據。

簡述MySQL中什麼是事務？

事務是一系列的操作，需要要符合ACID特性，即：事務中的操作要麼全部成功，要麼全部失敗。

簡述MySQL事務之間的隔離？

MySQL事務支援如下四種隔離：
未提交讀(Read Uncommitted)：允許臟讀，其他事務只要修改了數據，即使未提交，本事務也能看到修改後的數據值。也就是可能讀取到其他會話中未提交事務修改的數據。
提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數資料庫默認都是該級別 (不重複讀)。
可重複讀(Repeated Read)：可重複讀。無論其他事務是否修改並提交了數據，在這個事務中看到的數據值始終不受其他事務影響。
串列讀(Serializable)：完全串列化的讀，每次讀都需要獲得表級共享鎖，讀寫相互都會阻塞。




簡述MySQL鎖及其作用？

鎖機制是為了避免，在資料庫有並發事務的時候，可能會產生數據的不一致而誕生的的一個機制。鎖從類別上分為：
共享鎖：又叫做讀鎖，當用戶要進行數據的讀取時，對數據加上共享鎖，共享鎖可以同時加上多個。
排他鎖：又叫做寫鎖，當用戶要進行數據的寫入時，對數據加上排他鎖，排他鎖只可以加一個，他和其他的排他鎖,共享鎖都相斥。


簡述MySQL表中為什麼建議添加主鍵？

主鍵是資料庫確保數據行在整張表唯一性的保障，即使資料庫中表沒有主鍵，也建議添加一個自增長的ID列作為主鍵，設定了主鍵之後，在後續的刪改查的時候可能更加快速以及確保操作數據範圍安全。

簡述MySQL所支援的存儲引擎？

MySQL支援多種存儲引擎，常見的有InnoDB、MyISAM、Memory、Archive等。通常使用InnoDB引擎都是最合適的，InnoDB也是MySQL的默認存儲引擎。

簡述MySQL InnoDB引擎和MyISAM引擎的差異？

  • InnoDB支援事物，而MyISAM不支援事物。
  • InnoDB支援行級鎖，而MyISAM支援表級鎖。
  • InnoDB支援MVCC, 而MyISAM不支援。
  • InnoDB支援外鍵，而MyISAM不支援。
  • InnoDB不支援全文索引，而MyISAM支援。


簡述MySQL主從複製過程？

  1. Slave上面的IO執行緒連接上Master，並請求從指定日誌文件的指定位置（或者從最開始的日誌）之後的日誌內容；
  2. Master接收到來自Slave的IO執行緒的請求後，通過負責複製的IO執行緒根據請求資訊讀取指定日誌指定位置之後的日誌資訊，返回給Slave端的IO執行緒。返回資訊中除了日誌所包含的資訊之外，還包括本次返回的資訊在Master端binary log文件的名稱以及在Binary log中的位置；
  3. Slave的IO執行緒收到資訊後，將接收到的日誌內容依次寫入到Slave端的RelayLog文件（mysql-relay-lin.xxxxx）的最末端，並將讀取到的Master端的bin-log的文件名和位置記錄到master-info文件中，以便在下一次讀取的時候能夠明確知道從什麼位置開始讀取日誌；
  4. Slave的SQL執行緒檢測到Relay Log中新增加了內容後，會馬上解析該Log文件中的內容成為在Master端真實執行時候的那些可執行的查詢或操作語句，並在自身執行那些查詢或操作語句，這樣，實際上就是在master端和Slave端執行了同樣的查詢或操作語句，所以兩端的數據是完全一樣的。 

簡述MySQL常見的讀寫分離方案？

MySQL+Amoeba讀寫分離方案：Amoeba(變形蟲)項目，這個工具致力於MySQL的分散式資料庫前端代理層，它主要在應用層訪問MySQL的時候充當SQL路由功能。具有負載均衡、高可用性、SQL 過濾、讀寫分離、可路由相關的到目標資料庫、可並發請求多台資料庫合併結果。通過Amoeba你能夠完成多數據源的高可用、負載均衡、數據切片、讀寫分離的功能。
MySQL+MMM讀寫分離方案：MMM即Multi-Master Replication Manager for MySQL，mysql多主複製管理器是關於mysql主主複製配置的監控、故障轉移和管理的一套可伸縮的腳本套件(在任何時候只有一個節點可以被寫入)。MMM也能對從伺服器進行讀負載均衡，通過MMM方案能實現伺服器的故障轉移，從而實現mysql的高可用。MMM不僅能提供浮動IP的功能，如果當前的主伺服器掛掉後，會將你後端的從伺服器自動轉向新的主伺服器進行同步複製，不用手工更改同步配置。

簡述MySQL常見的高可用方案？

  • MySQL主從複製：Mysql內建的複製功能是構建大型，高性能應用程式的基礎。將Mysql的數據分布在多個節點（slaves）之上，複製過程中一個伺服器充當主伺服器，而一個或多個其它伺服器充當從伺服器。主伺服器將更新寫入二進位日誌文件，並維護文件的一個索引以跟蹤日誌循環。這些日誌可以記錄發送到從伺服器的更新。
  • MySQL雙主：參考MySQL主從複製。
  • MySQL雙主多從：參考MySQL主從複製。
  • MySQL複製+Keepalived高可用：MySQL自身的複製，對外基於Keepalived技術，暴露一個VIP，從而實現高可用。
  • Heartbeat + MySQL 實現MySQL的高可用：通過Heartbeat的心跳檢測和資源接管、集群中服務的監測、失效切換等功能，結合MySQL來實現高可用性。

簡述MySQL常見的優化措施？

MySQL可通過如下方式優化：

  1. 開啟查詢快取，優化查詢。
  2. 使用explain判斷select查詢，從而分析查詢語句或是表結構的性能瓶頸，然後有針對性的進行優化。
  3. 為搜索欄位建索引
  4. 對於有限定範圍取值的欄位，推薦使用 ENUM 而不是 VARCHAR。
  5. 垂直分表。
  6. 選擇正確的存儲引擎。

簡述MySQL常見備份方式和工具？

  • MySQL自帶

mysqldump：mysqldump支援基於innodb的熱備份，使用mysqldump完全備份+二進位日誌可以實現基於時間點的恢復，通常適合備份數據比較小的場景 。

  • 系統層面

tar備份：可以使用tar之類的系統命令對整個資料庫目錄進行打包備份。
lvm快照備份：可基於文件系統的LVM製作快照，進行對整個資料庫目錄所在的邏輯卷備份。

  • 第三方備份工具

可使用其他第三方工具進行備份，如xtrabackup工具，該工具支援innodb的物理熱備份，支援完全備份、增量備份，而且速度非常快，支援innodb存儲引起的數據在不同資料庫之間遷移，支援複製模式下的從機備份恢復備份恢復。

簡述常見的監控軟體？

常見的監控軟體有：

  • Cacti：是一套基於PHP、MySQL、SNMP及RRDTool開發的網路流量監測圖形分析工具。
  • Zabbix：Zabbix是一個企業級的高度集成開源監控軟體，提供分散式監控解決方案。可以用來監控設備、服務等可用性和性能。
  • Open-falcon：open-falcon是一款用golang和python寫的監控系統，由小米啟動這個項目。
  • Prometheus：Prometheus是由SoundCloud開發的開源監控報警系統和時序列資料庫(TSDB)。Prometheus使用Go語言開發，是Google BorgMon監控系統的開源版本。

簡述Prometheus及其主要特性？

Prometheus是一個已加入CNCF的開源監控報警系統和時序列資料庫項目，通過不同的組件完成數據的採集，數據的存儲和告警。
Prometheus主要特性：

  • 多維數據模型
    • 時間序列數據通過 metric 名和鍵值對來區分。
    • 所有的 metrics 都可以設置任意的多維標籤。
    • 數據模型更隨意，不需要刻意設置為以點分隔的字元串。
    • 可以對數據模型進行聚合，切割和切片操作。
    • 支援雙精度浮點類型，標籤可以設為全 unicode。
  • 靈活的查詢語句（PromQL），可以利用多維數據完成複雜的查詢
  • Prometheus server 是一個單獨的二進位文件，不依賴（任何分散式）存儲，支援 local 和 remote 不同模型
  • 採用 http 協議，使用 pull 模式，拉取數據，或者通過中間網關推送方式採集數據
  • 監控目標，可以採用服務發現或靜態配置的方式
  • 支援多種統計數據模型，圖形化友好
  • 高效：一個 Prometheus server 可以處理數百萬的 metrics
  • 適用於以機器為中心的監控以及高度動態面向服務架構的監控

簡述Prometheus主要組件及其功能？

Prometheus 的主要模組包含：prometheus server, exporters, push gateway, PromQL, Alertmanager, WebUI 等。

  1. prometheus server：定期從靜態配置的 targets 或者服務發現（主要是DNS、consul、k8s、mesos等）的 targets 拉取數據，用於收集和存儲時間序列數據。
  2. exporters：負責向prometheus server做數據彙報，暴露一個http服務的介面給Prometheus server定時抓取。而不同的數據彙報由不同的exporters實現，比如監控主機有node-exporters，mysql有MySQL server exporter。
  3. push gateway：主要使用場景為，當Prometheus 採用 pull 模式，可能由於不在一個子網或者防火牆原因，導致 Prometheus 無法直接拉取各個 target 數據。此時需要push gateway接入，以便於在監控業務數據的時候，將不同數據匯總, 由 Prometheus 統一收集。實現機制類似於zabbix-proxy功能。
  4. Alertmanager：從 Prometheus server 端接收到 alerts 後，會進行去除重複數據，分組，並路由到對收的接受方式，發出報警，即主要實現prometheus的告警功能。AlertManager的整體工作流程如下圖所示:
  5. webui：Prometheus內置一個簡單的Web控制台，可以查詢指標，查看配置資訊或者Service Discovery等，實踐中通常結合Grafana，Prometheus僅作為Grafana的數據源。

簡述Prometheus的機制？

Prometheus簡單機制如下：

  • Prometheus以其Server為核心，用於收集和存儲時間序列數據。Prometheus Server 從監控目標中拉取數據，或通過push gateway間接的把監控目標的監控數據存儲到本地HDD/SSD中。
  • 用戶介面介面通過各種UI使用PromQL查詢語言從Server獲取數據。
  • 一旦Server檢測到異常，會推送告警到AlertManager，由告警管理負責去通知相關方。

簡述Prometheus中什麼是時序數據？

Prometheus 存儲的是時序數據,，時序數據是指按照相同時序(相同的名字和標籤)，以時間維度存儲連續的數據的集合。時序(time series) 是由名字(Metric)，以及一組 key/value 標籤定義的，具有相同的名字以及標籤屬於相同時序。

簡述Prometheus時序數據有哪些類型？

Prometheus 時序數據分為 Counter, Gauge, Histogram, Summary 四種類型。

  • Counter：計數器表示收集的數據是按照某個趨勢（增加／減少）一直變化的，通常用它記錄服務請求總量，錯誤總數等。
  • Gauge：計量器表示搜集的數據是一個瞬時的，與時間沒有關係，可以任意變高變低，往往可以用來記錄記憶體使用率、磁碟使用率等。
  • Histogram：直方圖 Histogram 主要用於對一段時間範圍內的數據進行取樣，（通常是請求持續時間或響應大小），並能夠對其指定區間以及總數進行統計，通常我們用它計算分位數的直方圖。
  • Summary：匯總Summary 和 直方圖Histogram 類似，主要用於表示一段時間內數據取樣結果，（通常是請求持續時間或響應大小），它直接存儲了 quantile 數據，而不是根據統計區間計算出來的。

簡述Zabbix及其優勢？

Zabbix是一個企業級的高度集成開源監控軟體，提供分散式監控解決方案。可以用來監控設備、服務等可用性和性能。其主要優勢有：

  • 自由開放源程式碼產品，可以對其進行任意修改和二次開發，採用GPL協議；
  • 安裝和配置簡單；
  • 搭建環境簡單，基於開源軟體構建平台；
  • 完全支援Linux、Unix、Windows、AIX、BSD等平台，採用C語言編碼，系統佔用小，數據採集性能和速度非常快；
  • 數據採集持久存儲到資料庫，便於對監控數據的二次分析；
  • 非常豐富的擴展能力，輕鬆實現自定義監控項和實現數據採集。

簡述Zabbix體系架構？

Zabbix體系相對清晰，其主要組件有：

  • Zabbix Server：負責接收agent發送的報告資訊的核心組件，所有配置、統計數據及操作數據均由其組織進行。
  • Database Storage：專用於存儲所有配置資訊，以及有zabbix收集的數據。
  • Web interface（frontend）：zabbix的GUI介面，通常與server運行在同一台機器上。
  • Proxy：可選組件，常用於分散式監控環境中，代理Server收集部分被監控數據並統一發往Server端。
  • Agent：部署在被監控主機上，負責收集本地數據並發往Server端或者Proxy端。

簡述Zabbix所支援的監控方式？

目前由zabbix提供包括但不限於以下事項類型的支援：

  • Zabbix agent checks：這些客戶端來進行數據採集，又分為Zabbix agent（被動模式：客戶端等著伺服器端來要數據），Zabbix agent (active)（主動模式：客戶端主動發送數據到伺服器端）
  • SNMP agent checks：SNMP方式，如果要監控印表機網路設備等支援SNMP設備的話，但是又不能安裝agent的設備。
  • SNMP traps ：
  • IPMI checks：IPMI即智慧平台管理介面，現在是業界通過的標準。用戶可以利用IPMI監視伺服器的物理特性，如溫度、電壓、電扇工作狀態、電源供應以及機箱入侵等。

簡述Zabbix分散式及其適應場景？

zabbix proxy 可以代替 zabbix server 收集性能和可用性數據,然後把數據彙報給 zabbix server，並且在一定程度上分擔了zabbix server 的壓力。
此外，當所有agents和proxy報告給一個Zabbix server並且所有數據都集中收集時，使用proxy是實現集中式和分散式監控的最簡單方法。
zabbix proxy 使用場景:

  • 監控遠程區域設備
  • 監控本地網路不穩定區域
  • 當 zabbix 監控上千設備時,使用它來減輕 server 的壓力
  • 簡化分散式監控的維護

網路管理

簡述什麼是CDN？

CDN即內容分發網路，是在現有網路中增加一層新的網路架構，從而實現將源站內容發布和傳送到最靠近用戶的邊緣地區，使用戶可以就近訪問想要的內容，提高用戶訪問的響應速度。

集群相關

簡述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開源的容器集群管理系統（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組織中。

其他內容

簡述什麼是中間件？

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

Tags:

VirMach 便宜 VPS

QNews

QNews