七張圖瞭解Kubernetes內部的架構

Kubernetes是用於管理容器化應用程序集羣的工具。在計算機領域中，此過程一般稱爲編排。

用管絃樂編排比喻上面的服務編排是很恰當的，就像樂隊指揮同樣，Kubernetes協調地將許多微服務組合在一塊兒構成了應用程序。 Kubernetes會自動且持續地監視集羣並對其組成進行調整。

瞭解Kubernetes架構對於部署和維護容器化的應用程序相當重要。

什麼是Kubernetes

Kubernetes或簡稱k8s，是一個用於自動執行應用程序部署的系統。現代應用程序分散在雲，虛擬機和服務器之間。手動管理應用程序再也不是可行的選擇。

K8s將虛擬機和物理機轉換爲統一的API切面。而後，開發人員可使用Kubernetes API來部署，擴展和管理容器化的應用程序。

它的體系結構還爲分佈式系統提供了一個靈活的框架。K8s爲您的應用程序自動協調擴展和故障轉移，並提供部署模式。

它有助於管理運行應用程序的容器，並確保生產環境中沒有停機時間。例如，若是某個容器發生故障，則另外一個容器會自動取代其位置，而最終用戶根本不會注意到。

Kubernetes不只是一個編排系統。它是一組獨立的，相互關聯的控制過程。它的做用是在當前狀態下連續工做，並朝着指望的方向移動過程。

Kubernetes架構和組成

Kubernetes具備去中心化的架構，不會線性處理任務。它基於聲明性模型運行並實現"所需狀態"的概念。下面這些步驟說明了Kubernetes的基本過程:

• 管理員建立應用程序的所需狀態並將其放入清單文件manifest.yml中。
• 使用CLI或提供的用戶界面將清單文件提供給Kubernetes API Server。 Kubernetes的默認命令行工具稱爲kubectl。
• Kubernetes將清單文件（描述了應用程序的指望狀態）存儲在稱爲鍵值存儲（etcd）的數據庫中。
• Kubernetes隨後在集羣內的全部相關應用程序上實現所需的狀態。
• Kubernetes持續監控集羣的元素，以確保應用程序的當前狀態不會與所需狀態有所不一樣。

如今，咱們將探索標準Kubernetes集羣的各個組成部分，以更詳細地瞭解該過程。

主節點

Kubernetes的主節點經過API從CLI（命令行界面）或UI（用戶界面）接收輸入。這些是你提供給Kubernetes的命令。

你能夠定義想要讓Kubernetes維護的Pod，副本集和Service。例如，要使用的容器鏡像，要公開的端口以及要運行的Pod副本數量。還能夠爲該集羣中運行的應用程序提供"所需狀態"的參數。

API Server

API Server是Kubernetes控制程序的前端，也是用戶惟一能夠直接進行交互的Kubernetes組件，內部系統組件以及外部用戶組件均經過相同的API進行通訊。

鍵值存儲etcd

鍵值存儲（也稱爲etcd）是Kubernetes用來備份全部集羣數據的數據庫。它存儲集羣的整個配置和狀態。主節點查詢etcd以檢索節點，容器和容器的狀態參數。

Controller

控制器的做用是從API Server得到所需狀態。它檢查要控制的節點的當前狀態，肯定是否與所需狀態存在任何差別，並解決它們（若是有）。

Scheduler

調度程序會監視來自API Server的新請求，並將其分配給運行情況良好的節點。它對節點的質量進行排名，並將Pod部署到最適合的節點。若是沒有合適的節點，則將Pod置於掛起狀態，直到出現合適的節點。

注意：最好不要在主節點上運行用戶應用程序。讓 Kubernetes主節點能夠徹底專一於管理集羣。

工做節點

工做節點監聽API Server發送過來的新的工做分配；他們會執行分配給他們的工做，而後將結果報告給Kubernetes主節點。

Kubelet

kubelet在羣集中的每一個節點上運行。它是Kubernetes內部的主要代理。經過安裝kubelet，節點的CPU，RAM和存儲成爲所處集羣的一部分。它監視從API Server發送來的任務，執行任務，並報告給主節點。它還會監視Pod，若是Pod不能徹底正常運行，則會向控制程序報告。而後，基於該信息，主服務器能夠決定如何分配任務和資源以達到所需狀態。

Container Runtime

容器運行時從容器鏡像庫中拉取鏡像，而後啓動和中止容器。容器運行時由第三方軟件或插件（例如Docker）擔當。

Kube-proxy

kube-proxy確保每一個節點都得到其IP地址，實現本地iptables和規則以處理路由和流量負載均衡。

Pod

在Kubernetes中，Pod是調度的最小元素。沒有它，容器就不能成爲集羣的一部分。若是你須要擴展應用程序，則只能經過添加或刪除Pod來實現。

Pod是Kubernetes中一個抽象化概念，由一個或多個容器組合在一塊兒得共享資源。根據資源的可用性，主節點會把Pod調度到特定工做節點上，並與容器運行時協調以啓動容器。

在Pod意外沒法執行任務的狀況下，Kubernetes不會嘗試修復它們。相反，它會在其位置建立並啓動一個新Pod。這個新Pod是原來的副本，除了DNS和IP地址都和之前的Pod同樣。此功能對開發人員設計應用程序的方式產生了深遠的影響。

因爲Kubernetes架構的靈活性，再也不須要將應用程序綁定到Pod的特定實例。取而代之的是，須要對應用程序進行設計，以便在集羣內任何位置建立的全新Pod能夠無縫取代舊Pod。Kubernetes會使用Service來協助此過程。

Kubernetes Service

Pod不是恆定的。 Kubernetes提供的最佳功能之一是沒法正常運行的Pod會自動被新的Pod取代。

可是，這些新的Pod具備一組不一樣的IP。這可能致使處理問題，而且因爲IP再也不匹配，IP流失。若是無人看管，此屬性將使吊艙高度不可靠。

爲了將穩定的IP地址和DNS名稱引入到不穩定的Pod世界中，Kubernetes引入了Service來提供可靠的網絡鏈接。

經過控制進出Pod的流量，Service提供了穩定的網絡終結點-固定的IP，DNS和端口。有了Service，能夠添加或刪除任何Pod，而沒必要擔憂基本網絡信息會改變。

Service是怎麼工做的

Pod經過稱爲標籤（Label）和選擇器（Selector）的鍵值對與Service相關聯。Service會自動發現帶有與選擇器匹配的標籤的新Pod。

此過程無縫地將新的Pod添加到Service，同時，從羣集中刪除已終止的Pod。

例如，若是所需狀態定義了須要一個Pod的三個副本，而運行一個副本的節點發生故障，則當前狀態將減小爲兩個Pod。Kubernetes觀察到所需的狀態是三個Pod。而後，它會調度一個新副原本代替發生故障的Pod，並將其分配給集羣中的另外一個節點。

經過添加或刪除容器來更新或縮放應用程序時，一樣適用。一旦咱們更新了所需狀態的定義，Kubernetes就會注意到差別並添加或刪除Pod以匹配清單文件manifest.yml裏定義的所需狀態。Kubernetes控制面板記錄，實現和運行後臺協調循環，該循環會不斷檢查環境是否符合用戶定義的環境要求。

Container Deployment

爲了充分了解Kubernetes的編排方式和內容，咱們須要瞭解一下容器部署的概念。

傳統部署

最初，開發人員在單個物理服務器上部署應用程序。這種部署帶來的問題是。物理資源的共享意味着一個應用程序能夠佔用服務器的大部分處理能力，從而限制了同一臺服務器上其餘應用程序的性能。

擴展硬件容量須要花費很長時間，增長不少成本。爲了解決硬件限制，組織開始虛擬化物理機。

虛擬化部署

虛擬化部署容許在單個物理服務器上建立隔離的虛擬環境，即虛擬機（VM）。該解決方案隔離了VM中的應用程序，限制了資源的使用並提升了安全性。一個應用程序不能再自由訪問另外一個應用程序處理的信息。

經過虛擬化部署，您能夠快速擴展並分散單個物理服務器的資源，隨意更新並控制硬件成本。每一個VM都有其操做系統，而且能夠在虛擬化硬件之上運行全部必要的系統。

容器化部署

容器部署是建立更加靈活和高效的模型的下一步。就像虛擬機同樣，容器具備單獨的內存，系統文件和處理空間。可是，嚴格隔離再也不是限制因素。

如今，多個應用程序能夠共享相同的基礎操做系統。此功能使容器比成熟的VM效率更高。它們可跨越雲，不一樣的設備以及幾乎全部OS發行版進行移植。

容器的結構還容許應用程序做爲較小的獨立部分運行。而後能夠在多臺計算機上動態部署和管理這些部分。複雜的結構和任務劃分太複雜，沒法手動管理。須要一個像Kubernetes這樣的自動化解決方案，以有效管理此過程當中涉及的全部活動部件。

總結

Kubernetes使用很是簡單的模型進行操做。咱們輸入但願系統運行的方式–所需狀態，Kubernetes將所需狀態與集羣中的當前狀態進行比較。而後，它的服務將兩個狀態對齊，並實現和維持所需狀態。

你如今應該對Kubernetes架構有了更好的瞭解，能夠繼續學習執行建立和維護集羣的實際任務。