Kubernetes是一個強大的開源系統，最初由谷歌開發，用于在集群環境中管理容器化應用程序。它的目標是提供更好的方法來管理不同基礎設施之間的相關分布式組件和服務。

在本指南中，我們將討論一些Kubernetes的基本概念。我們將討論系統的體系結構、它解決的問題，以及它用來處理容器部署和擴展的模型。

Kubernetes是什么？

在基本級別上，Kubernetes是一個用于跨機器集群運行和協調容器應用程序的系統。它是一個平臺，旨在通過提供可預測性、可伸縮性和高可用性的方法，完全管理容器化應用程序和服務的生命周期。

作為Kubernetes用戶，您可以定義應用程序的運行方式，以及它們與其他應用程序或外部交互的方式。您可以向上或向下擴展服務、執行優雅的滾動更新、不同版本應用程序的流量切換，以測試特性或回滾問題部署。Kubernetes提供了接口和可組合的平臺基元，允許您以高度的靈活性、強大性和可靠性定義和管理應用程序。

Kubernetes架構

要理解Kubernetes是如何提供這些功能的，了解它是如何在高層次上設計和組織的是很有幫助的。Kubernetes可以被視為一個以層（layer）為單位的系統，每個更高層抽象出更低層次的復雜性。

在其基礎上，Kubernetes使用共享網絡將單個物理或虛擬機組合到一個集群中，以便在每個服務器之間進行通信。這個集群是配置所有Kubernetes組件、功能和工作負載的物理平臺。

集群中的機器在Kubernetes生態系統中每個都有一個角色。一個服務器（或高可用部署中的一個小組）充當主服務器。這個服務器充當集群的網關和大腦，它為用戶和客戶機公開API，檢查其他服務器的健康狀況，決定如何最好地分割和分配工作（稱為“調度”），以及協調其他組件之間的通信。主服務器充當與集群的主要接觸點，并負責Kubernetes提供的大部分集中邏輯。

集群中的其他機器被指定為節點：服務器負責使用本地和外部資源接受和運行工作負載。為了幫助實現隔離、管理和靈活性，Kubernetes在容器中運行應用程序和服務，因此每個節點都需要配備一個容器運行時（比如Docker或rkt）。節點從主服務器接收工作指令，并相應地創建或銷毀容器，調整網絡規則以實現適當的流量路由與轉發操作。

如上所述，應用程序和服務本身在容器內的集群上運行。底層組件確保應用程序的期望狀態與集群的實際狀態匹配。用戶通過直接與主API服務器或與客戶機和庫通信與集群進行交互。要啟動應用程序或服務，需要以JSON或YAML的形式提交聲明性計劃，定義要創建什么以及應該如何管理它。然后，主服務器獲取計劃，通過檢查系統的需求和當前狀態，確定如何在基礎設施上運行它。這組根據指定計劃運行的用戶定義應用程序代表了Kubernetes的最后一層。

主服務器組件

如上所述，主服務器充當Kubernetes集群的主要控制平面。它是管理員和用戶的主要聯系點，也為相對不復雜的工作節點提供了許多集群范圍的系統。總體而言，主服務器上的組件協同工作來接受用戶請求，確定調度工作負載容器，驗證客戶端和節點，調整群集范圍網絡以及管理擴展和運行狀況檢查職責的最佳方法。

這些組件可以安裝在一臺機器上，也可以分布在多個服務器上。在本節中，我們將研究與主服務器相關的每個單獨組件。

etcd

Kubernetes需要運行的基本組件之一是全局可用的配置存儲。 由CoreOS團隊開發的etcd項目是一個輕量級的分布式鍵值存儲，可以配置為跨越多個節點。

Kubernetes使用etcd來存儲可以由集群中的每個節點訪問的配置數據。這可用于服務發現，并可幫助組件根據最新信息配置或重新配置自身。 它還有助于通過領導者選舉和分布式鎖定等功能維護群集狀態。通過提供簡單的HTTP/JSON API，用于設置或檢索值的界面非常簡單。

與控制平面中的大多數其他組件一樣，etcd可以在單個主服務器上配置，或者在生產方案中，可以在多臺計算機之間分配。唯一的要求是每個Kubernetes機器都可以訪問網絡。

kube-apiserver

最重要的主服務之一是API服務器。 這是整個群集的主要管理點，因為它允許用戶配置Kubernetes的工作負載和組織單位。 它還負責確保etcd存儲和已部署容器的服務詳細信息一致。 它充當各種組件之間的橋梁，以維護集群健康并傳播信息和命令。

API服務器實現RESTful接口，這意味著許多不同的工具和庫可以很容易地與它通信。 名為kubectl的客戶端可用作從本地計算機與Kubernetes集群交互的默認方法。

kube控制器管理器

控制器管理器是一項具有許多職責的通用服務。它主要管理不同的控制器，用于管理集群狀態，管理工作負載生命周期以及執行例行任務。例如，復制控制器可確保為Pod定義的副本數（相同副本）與當前在群集上部署的數量相匹配。這些操作的詳細信息將寫入etcd，其中控制器管理器通過API服務器監視更改。

當看到更改時，控制器讀取新信息并實現滿足所需狀態的過程。這可能涉及向上或向下擴展應用程序，調整端點等。

kube調度

實際將工作負載分配給集群中特定節點的過程是調度程序。此服務讀取工作負載的操作要求，分析當前的基礎結構環境，并將工作放在可接受的節點上。

調度程序負責跟蹤每臺主機上的可用容量，以確保未調度超出可用資源的工作負載。調度程序必須知道總容量以及已分配給每臺服務器上現有工作負載的資源。

云控制器管理器

Kubernetes可以部署在許多不同的環境中，并且可以與各種基礎架構提供商進行交互，以了解和管理集群中的資源狀態。盡管Kubernetes能夠支持附加存儲與負載均衡器等常規資源形式，但其仍需要將這些形式與由不同云服務供應商提供的實際資源映射起來。

云控制器管理器充當粘合劑，允許Kubernetes使提供者具有不同的功能，特性和API，同時在內部維護相對通用的構造。這允許Kubernetes根據從云提供商收集的信息更新其狀態信息，在系統中需要更改時調整云資源，以及創建和使用其他云服務以滿足提交到群集的工作要求。

節點服務器組件

在Kubernetes中，通過運行容器執行工作的服務器稱為節點。 節點服務器有一些要求，這些要求是與主組件通信，配置容器網絡以及運行分配給它們的實際工作負載所必需的。

一個容器運行時

每個節點必須具有的第一個組件是容器運行時。通常，通過安裝和運行Docker可以滿足此要求，但也可以使用rkt和runC等替代方案。

容器運行時負責啟動和管理容器，應用程序封裝在相對隔離但輕量級的操作環境中。集群上的每個工作單元在其基本級別上實現為必須部署的一個或多個容器。每個節點上的容器運行時是最終運行提交到集群的工作負載中定義的容器的組件。

kubelet

每個節點與群集組的主要聯系點是一個名為kubelet的小型服務。該服務負責向控制平面服務中繼信息，以及與etcd存儲交互以讀取配置細節或寫入新值。

kubelet服務與主組件通信以向集群進行身份驗證并接收命令和工作。以清單的形式接收工作，該清單定義工作量和操作參數。然后，kubelet進程負責維護節點服務器上的工作狀態。它控制容器運行時根據需要啟動或銷毀容器。

kube-代理

為了管理單個主機子網并使服務可用于其他組件，在每個節點服務器上運行一個名為kube-proxy的小型代理服務。此過程將請求轉發到正確的容器，可以進行原始負載平衡，并且通常負責確保網絡環境是可預測和可訪問的，但在適當時隔離。

Kubernetes對象和工作量

雖然容器是用于部署應用程序的底層機制，但Kubernetes在容器接口上使用了額外的抽象層來提供擴展，彈性和生命周期管理功能。用戶不是直接管理容器，而是定義由Kubernetes對象模型提供的各種基元組成的實例并與之交互。我們將介紹可用于定義下面這些工作負載的不同類型的對象。

Pod

Pod是Kubernetes處理的最基本單位。容器本身未分配給主機。相反，一個或多個緊密耦合的容器被封裝在稱為Pod的對象中。

Pod通常表示應作為單個應用程序控制的一個或多個容器。Pod由密集操作的容器組成，共享生命周期，并且應始終安排在同一節點上。它們完全作為一個單元進行管理，并共享其環境，數量和IP空間。盡管它們是容器化的實現，但您通常應該將Pod視為一個單一的整體應用程序，以便最好地概念化集群如何管理Pod的資源和調度。

通常，Pod包含滿足工作負載一般用途的主容器，以及可選的一些幫助密切相關任務的幫助容器。這些程序受益于在自己的容器中運行和管理，但與主應用程序緊密相關。例如，當外部存儲庫中檢測到更改時，Pod可能有一個運行主應用程序服務器的容器和一個幫助容器將文件下拉到共享文件系統。通常不鼓勵在Pod級別進行水平縮放，因為還有其他更高級別的對象更適合該任務。

通常，用戶不應自行管理Pod，因為它們不提供應用程序中通常需要的某些功能（如復雜的生命周期管理和擴展）。相反，鼓勵用戶使用更高級別的對象，這些對象使用Pod或Pod模板作為基本組件，但實現其他功能。

復制控制器和復制集

通常，在與Kubernetes合作時，不是使用單個Pod，而是管理相同，復制的Pod組。這些是從Pod模板創建的，可以通過稱為復制控制器和復制集的控制器進行水平擴展。

復制控制器是一個對象，它定義Pod模板和控制參數，以通過增加或減少運行副本的數量來水平擴展Pod的相同副本。這是在Kubernetes中本地分配負載和增加可用性的簡單方法。復制控制器知道如何根據需要創建新的Pod，因為復制控制器配置中嵌入了與Pod定義非常相似的模板。

復制控制器負責確保群集中部署的Pod數量與其配置中的Pod數量相匹配。如果Pod或底層主機出現故障，控制器將啟動新的Pod以進行補償。如果控制器配置中的副本數量發生更改，控制器將啟動或終止容器以匹配所需的數字。復制控制器還可以執行滾動更新，將一組Pod逐個滾動到新版本，從而最大限度地降低對應用程序可用性的影響。

復制集是復制控制器設計的迭代，在控制器識別其要管理的Pod方面具有更大的靈活性。復制集開始取代復制控制器，因為它們具有更強的副本選擇功能，但它們無法進行滾動更新以將后端循環到新版本，如復制控制器。相反，復制集旨在用于提供該功能的其他更高級別單元內部。

與Pod一樣，復制控制器和復制集很少是您直接使用的單元。雖然它們基于Pod設計以增加水平擴展和可靠性保證，但它們缺少一些在更復雜的對象中發現的細粒度生命周期管理功能。

Deployment

Deployment是直接創建和管理的最常見工作負載之一。Deployment使用復制集作為構建塊，為整個體系添加靈活的生命周期管理功能。

雖然使用復制集構建的部署可能會復制復制控制器提供的功能，但Deployment解決了滾動更新實現中存在的許多難點。使用復制控制器更新應用程序時，用戶需要為將替換當前控制器的新復制控制器提交計劃。使用復制控制器時，跟蹤歷史記錄，在更新期間從網絡故障中恢復以及回滾不良更改等任務要么很困難，要么由用戶負責。

Deployment是一個高級對象，旨在簡化復制Pod的生命周期管理。通過更改配置可以輕松修改部署，Kubernetes將調整副本集，管理不同應用程序版本之間的轉換，并可選擇自動維護事件歷史記錄和撤消功能。由于這些功能，Deployment可能是您最常使用的Kubernetes對象類型。

有狀態集

有狀態集是專門的Pod控制器，提供排序和唯一性保證。首先，當您有與部署順序，持久數據或穩定網絡相關的特殊要求時，這些用于進行更細粒度的控制。例如，有狀態集通常與面向數據的應用程序相關聯，如數據庫，即使重新安排到新節點，也需要訪問相同的卷。

有狀態集通過為每個Pod創建唯一的，基于數字的名稱來提供穩定的網絡標識符，即使將Pod移動到另一個節點也會持久存在。同樣，當需要重新安排時，可以使用Pod傳輸持久存儲卷。即使在刪除Pod后，卷仍然存在，以防止意外數據丟失。

在部署或調整比例時，有狀態集根據其名稱中的編號標識符執行操作。這提供了更高的可預測性和對執行順序的控制，這在某些情況下很有用。

守護進程集

守護程序集是另一種特殊形式的Pod控制器，它在集群中的每個節點上運行Pod的副本（如果指定，則為子集）。在部署有助于執行維護并為節點本身提供服務的Pod時，這通常很有用。

例如，收集和轉發日志，聚合度量以及運行增加節點本身功能的服務是守護進程集的流行候選者。由于守護程序集通常提供基本服務并且在整個機群中都需要，因此它們可以繞過Pod調度限制，從而阻止其他控制器將Pod分配給某些主機。例如，由于其獨特的職責，主服務器經常被配置為不可用于正常的Pod調度，但是守護進程集能夠逐個Pod地覆蓋限制以確保基本服務正在運行。

Job和Cron Jobs

到目前為止，我們所描述的工作負載都假定為長期運行，類似服務的生命周期。Kubernetes使用稱為Job的工作負載來提供更多基于任務的工作流，其中運行的容器在完成工作后的一段時間后會成功退出。如果您需要執行一次性或批量處理而不是運行連續服務，則Job非常有用。

以jobs為基礎的是cron jobs。與Linux上的傳統cron守護程序和按計劃執行腳本的類Unix系統一樣，Kubernetes中的cron jobs提供了一個用于運行具有調度組件的jobs的接口。 Cron jobs可用于安排job在將來執行或定期重復執行。 Kubernetes cron jobs基本上是對經典cron行為的重新實現，使用集群作為平臺而不是單個操作系統。

其他Kubernetes組件

除了可以在群集上運行的工作負載之外，Kubernetes還提供了許多其他抽象，可幫助您管理應用程序，控制網絡和啟用持久性。我們將在這里討論一些更常見的例子。

Services

到目前為止，我們一直在使用傳統的類似于Unix的術語“Services”：表示長期運行的進程，通常是網絡連接的，能夠響應請求。但是，在Kubernetes中，Services是一個組件，充當基本內部負載平衡器和Pod的大使。Services將執行相同功能的Pod的邏輯集合組合在一起，以將它們顯示為單個實體。

這允許您部署可以跟蹤和路由到特定類型的所有后端容器的Services。內部消費者只需要了解Services提供的穩定端點。同時，Services抽象允許您根據需要擴展或替換后端工作單元。無論其路由到的Pod的變化如何，服務的IP地址都保持穩定。通過部署Services，您可以輕松獲得可發現性并簡化容器設計。

每當您需要為一個或多個Pod提供對另一個應用程序或外部使用者的訪問權限時，您應該配置一項服務。例如，如果您有一組運行Web服務器的Pod應該可以從Internet訪問，則Services將提供必要的抽象。同樣，如果您的Web服務器需要存儲和檢索數據，您可能希望配置內部服務以授予它們訪問數據庫窗格的權限。

雖然默認情況下Services只能使用內部可路由的IP地址，但只要選擇多種策略之一，就可以在群集外部使用它們。 NodePort配置通過在每個節點的外部網絡接口上打開靜態端口來工作。到外部端口的流量將使用內部群集IP服務自動路由到相應的Pod。

或者，LoadBalancer服務類型使用云提供程序的Kubernetes負載均衡器集成創建外部負載均衡器以路由到服務。云控制器管理器將創建適當的資源并使用內部Services服務地址對其進行配置。

存儲卷和持久存儲卷

在許多容器化環境中，可靠地共享數據并保證容器重啟之間的可用性是一項挑戰。容器運行時通常提供一些機制來將存儲連接到容器，該容器持續超出容器的生命周期，但實現通常缺乏靈活性。

為了解決這個問題，Kubernetes使用自己的卷抽象，允許數據由Pod中的所有容器共享，并在Pod終止之前保持可用。這意味著緊密耦合的Pod可以輕松共享文件而無需復雜的外部機制。 Pod中的容器故障不會影響對共享文件的訪問。 Pod終止后，共享卷被破壞，因此它不是真正持久數據的好解決方案。

持久卷是一種機制，用于抽象與Pod生命周期無關的更強大的存儲。相反，它們允許管理員為群集配置存儲資源，用戶可以請求并聲明正在運行的Pod。使用持久卷完成Pod后，卷的回收策略將確定是否保留卷，直到手動刪除或立即刪除數據。持久性數據可用于防止基于節點的故障，并分配比本地可用的存儲量更大的存儲量。

Label和Annotation

還有一條與其它概念相關，但又獨立于其外的Kubernetes組織抽象存在，就是labeling。Kubernetes中的Label是一個語義標簽，可以附加到Kubernetes對象上，以將它們標記為組的一部分。然后，可以在針對管理或路由的不同實例進行選擇時選擇這些。例如，每個基于控制器的對象使用Label來標識它們應該操作的Pod。服務使用標簽來理解他們應該將請求路由到的后端Pod。

Label以簡單的鍵值對的形式給出。每個單元可以有多個Label，但每個單元每個鍵只能有一個條目。通常，“name”鍵用作通用標識符，但您還可以通過開發階段，公共可訪問性，應用程序版本等其他標準對對象進行分類。

Annotation是一種類似的機制，允許您將任意鍵值信息附加到對象。雖然Label應該用于將Pod與選擇標準語義信息相匹配，但Annotation更自由，并且可以包含更少的結構化數據。通常，Annotation是一種向對象添加豐富元數據的方法，這對于選擇目的沒有幫助。

結論

Kubernetes是一個令人興奮的項目，它允許用戶在高度抽象的平臺上運行可伸縮的、高可用的容器化工作負載。雖然Kubernetes的體系結構和內部組件集乍一看可能令人生畏，但它們的功能、靈活性和健壯的特性集在開源領域是無與倫比的。通過了解基本構建塊是如何組合在一起的，您可以開始設計系統，充分利用平臺的功能來按比例運行和管理工作負載。

本文轉自DockOne-簡單介紹Kubernetes

總結

以上是生活随笔為你收集整理的简单介绍Kubernetes的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。