什麼是 Kubernetes？

Kubernetes 是 DevOps 用於在叢集之間部署、管理及調整容器的開放原始碼的軟體。另一種開放原始碼技術 Docker 是通常與 Kubernetes 搭配使用的預設容器檔案格式。

容器

容器會將應用程式與其相依性和設定一起封裝，讓它能在不同環境中以一致的方式執行。隨著應用程式演進，您可能會在許多伺服器上執行許多容器，而手動協調這一切會變得很複雜。Kubernetes 可透過開放原始碼 API 和控制系統來解決這種複雜性，這套控制系統會決定要在何處執行哪些項目，並持續讓它們執行。

Kubernetes 能為您做的事

排程與資源放置

Kubernetes 會協調虛擬機器的叢集，並依據可用的計算資源和每個容器的資源需求來排程容器執行。

服務探索和負載平衡

Kubernetes 會管理服務探索和負載平衡，因此即使 Pod 隨著時間變更，流量仍可路由傳送到正確的 Pod。

配合需求進行調整

Kubernetes 會根據計算使用量和您設定的所需狀態來調整工作負載。

在發生故障時自我修復

Kubernetes 會檢查資源健康狀態，並可在發生問題時重新啟動或複寫容器。它會重新啟動或取代失敗的容器，並在工作負載就緒前保留流量。

支援受控變更

Kubernetes 支援執行應用程式的部署模式，包括根據您描述的所需狀態自動推出和復原。

設定和密碼管理

Kubernetes 會為密碼或權杖等敏感性資訊提供祕密及組態管理。

儲存體協調流程

Kubernetes 可根據 Kubernetes 的儲存體協調流程模型來掛接您選擇的儲存體系統 (例如本機存放區或公用雲端選項)。

快速物件詞彙

Kubernetes 的建置基礎是 API 物件，也就是您所宣告和管理的資源。以下是一些範例：

• Pod：可執行一或多個容器的基本單位。

• 服務：將應用程式公開並將流量路由傳送到變更中的 Pod 的一種穩定方式。

• 部署：用來描述所需應用程式狀態並隨著時間更新的一種方式 (通常與推出和復原相關)。

• 節點：叢集中執行 Pod 的機器。

• 控制平面：用於管理叢集狀態及排程決策的元件。

這一切如何相互配合

1. 您宣告應用程式的所需狀態 (應執行哪些項目、需要多少複本、資源需求)。

2. 控制平面透過 Kubernetes API 和備份存放區記錄並處理該要求。

3. 排程器將 Pod 放置在具有足夠資源的節點上。

4. 節點元件執行工作負載。

5. 控制器會持續協調，讓實際狀態符合所需狀態，並視需要調整、取代和更新工作負載。

主要建置組塊

叢集：控制平面加上工作節點

Kubernetes 叢集通常分成兩部分：管理叢集的控制平面，以及執行工作負載的背景工作角色節點。

控制平面元件

這些元件會管理叢集的整體狀態：

• kube-apiserver：公開 Kubernetes HTTP API (要求的入口)。

• etcd：叢集資料的一致且高可用性的索引鍵/值組存放區。

• kube-scheduler：尋找需要放置的 Pod，並將它們指派給節點。

• kube-controller-manager：執行控制器，將實際狀態調整為所需狀態。

• cloud-controller-manager (選用)：將 Kubernetes 連接到雲端提供者特定的控制邏輯。

節點元件

每個背景工作角色節點都會執行可維護 Pod 和網路規則的軟體：

• kubelet：確保 Pod 在節點上執行，包括其容器。

• kube-proxy (選用)：維護網路規則以支援服務。

• container runtime：在節點上執行容器。

Pod：基本工作單位

Kubernetes 不會直接抽象地排程個別容器。它會將一或多個容器分組成 Pod，讓 Pod 成為基本作業單位。接著，Pod 會朝您定義的所需狀態擴大或縮小。

實際上，這表示：

1. 您描述想要執行的應用程式。

2. Kubernetes 會將 Pod 排程到具有可用計算資源的機器上。

3. 控制器會讓叢集持續朝您要求的狀態前進。

服務網路功能

Pod 可能會出現和消失，因此 Kubernetes 提供基本元素 (可讓您組合的基本建置組塊，用於在叢集中描述並執行應用程式) 以提供穩定的方式來存取工作負載。

Pod 網路基礎

每個 Pod 都會取得自己的叢集範圍 IP 位址，而且在 Kubernetes 網路模型中，Pod 可以跨節點通訊，而不需要網路位址轉譯 (NAT)。

服務

Service API 會為一組後端 Pod 提供穩定的 IP 位址或主機名稱，即使個別 Pod 隨著時間變更也一樣。

EndpointSlice

Kubernetes 會維護端點配量物件，以追蹤目前由哪些 Pod 支援服務。

輸入/閘道 API

為了將服務公開給叢集外的用戶端，Kubernetes 支援 Gateway API (以及作為其前身的輸入)。

LoadBalancer 服務

有些環境可以使用 LoadBalancer 服務類型，將服務公開到外部。

您可以在叢集中執行的附加元件

Kubernetes 叢集通常包含附加元件，可將功能擴充到核心元件之外。例如：

• DNS，用於整個叢集的名稱解析。

• Web UI (儀表板)，用於叢集管理。

• 容器資源監視，用於收集計量。

• 叢集層級記錄，用於集中收集記錄。

Kubernetes 可以在機器叢集上執行容器化應用程式，並讓它們維持在您描述的狀態。它會把工作放到適合的機器上、將流量路由傳送到正確的位置，以及監視失敗與變更，以完成作業。

基本流程

1. 您描述想要執行的項目

大多數 Kubernetes 工作負載一開始都會先宣告「所需狀態」(應執行什麼、要有多少複本，以及應如何公開)。Kubernetes 以宣告式設定和自動化為建置核心。

2. Kubernetes 決定應該在哪裡執行

Kubernetes 會根據可用的計算資源，以及每個容器的需求，將容器排程到叢集中的機器上。容器會在 Pod 內執行，而 Pod 是 Kubernetes 放置在機器上的單位。

3. Kubernetes 會持續檢查實際狀態是否符合您的所需狀態

控制器會監視叢集和工作，並使用 API 伺服器進行變更，讓目前狀態更接近所需狀態。

容器排程與日常管理

排程是指「應該在哪裡執行？」 的決策。

1. 排程的是 Pod，而不是個別容器

Kubernetes 會先將容器分組到 Pod，再將這些 Pod 放置到機器上。

2. 排程器會將 Pod 指派到合適的節點

kube-scheduler 會找出尚未指派的 Pod，並為它們選取節點。

3. 節點代理程式會讓 Pod 持續執行

在每個節點上，kubelet 會確保 Pod 正在執行 (包括其容器)。

負載平衡與服務探索

容器和 Pod 可以建立、移動或取代，因此應用程式需要穩定的方法來尋找彼此。

服務探索與負載平衡是內建行為

Kubernetes 會管理服務探索並使用負載平衡，因此即使 Pod 隨著時間變更，流量仍可正確路由傳送。

服務可為一組會變動的 Pod 提供穩定位址

Service API 會為一或多個 Pod 支援的服務提供穩定的 IP 位址或主機名稱，而 Kubernetes 會透過 EndpointSlice 物件追蹤支援的 Pod。

流量路由會隨著 Pod 變更而更新

當服務後方的 Pod 變更時，服務路由會自動調整，讓流量持續送達目前的後端。

調整應用程式 (以及為什麼「所需狀態」很重要)

Kubernetes 可以依照您設定的狀態調整工作負載，包括根據計算使用率進行調整。

常見的調整構想包括：

• 更多複本 (更多 Pod)，以因應更高的需求。

• 當需求下降時，複本數較少。

• 資源追蹤，讓放置決策能反映 CPU 和記憶體需求。

這與「所需狀態」模型相呼應：您指定目標，控制器會持續朝該目標前進。

自我修復：發生問題時會如何處理

Kubernetes 包含自我修復行為，目標是維持工作負載的健康情況與可用性。其中包括：

• 重新啟動失敗的容器 (容器層級重新啟動)。

• 取代失敗的 Pod，以維持要求的複本數 (複本取代)。

• 重新排程工作負載，當節點無法使用時。

• 將失敗的 Pod 從服務端點中移除，讓流量只會送往健康的 Pod (服務的負載平衡)。

自我修復會檢查容器健康情況，並在發生問題時重新啟動或複製它們。

Kubernetes KPI 的角色

關鍵效能指標 (KPI，或稱計量)可用來了解叢集健康情況與工作負載行為。

KPI 的來源

• Kubernetes 系統元件會輸出對於儀表板和警示有用的計量 (Prometheus 格式)。

• 計量通常可在元件的 /metrics HTTP 端點取得，包括 kube-apiserver、kube-scheduler、kubelet、kube-proxy 和 kube-controller-manager 等元件。

KPI 可協助您找出的項目範例

• 叢集健康訊號 (元件層級計量與錯誤模式)

• 工作負載穩定性 (例如頻繁重新啟動或取代)

• 容量壓力 (資源配置與需求的關係，與調整決策相關)

這在日常作業中的重要性

監視可讓團隊更完整地檢視叢集資源、Kubernetes API、容器和記錄，進而縮短問題與修正之間的意見反應迴圈。

當團隊需要以一致的方式在多部機器上執行大量容器，同時由平台負責流量路由、調整和復原時，Kubernetes 往往會是首選。

可擴縮性

Kubernetes 可以針對目標狀態調整工作負載，亦即隨著需求變更而擴大或縮小，而且可以根據計算使用率進行調整。

一般使用案例

• 流量變動大的網頁應用程式 (行銷活動、季節性高峰)：隨著負載變化調整複本數。

• 批次或事件驅動處理：在突增時新增容量，之後再縮減。

• 微服務：調整特定服務而無需調整整個應用程式。

資源效率

Kubernetes 支援自動量化封裝，也就是根據 CPU 和記憶體需求將容器放置在節點上，以更有效地使用可用資源。Kubernetes 在管理工作負載時，也會追蹤資源配置。

一般使用案例

• 供多個團隊共用的叢集：將工作負載放置到有可用資源的位置，以減少資源浪費。

• 混合工作負載叢集 (服務加上作業)：不必手動放置，也能讓節點保持忙碌。

服務探索和負載平衡

Kubernetes 可以使用 DNS 或 IP 位址公開工作負載，並且能分散網路流量，以維持部署穩定。它也會管理服務探索，並在工作負載變更時納入負載平衡。

一般使用案例

• 微服務通訊：當 Pod 變更時，服務會透過穩定的名稱彼此尋找。

• 穩定端點背後的內部 API：只將流量路由傳送到目前的後端。

自我修復

Kubernetes 的設計可用來取代失敗的容器、在節點無法使用時重新排程工作負載，並維持所需狀態。例如，重新啟動容器、取代複本，以及將不健康的 Pod 從服務端點中移除，讓流量只會導向健康的 Pod。

一般使用案例

• 持續運作的服務：自動重新啟動或取代失敗的執行個體，不需要手動介入。

• 節點經常流失的叢集：當節點停止運作時，重新排程工作負載。

• 位於服務後方的服務：停止將流量路由傳送到不健康的 Pod。

更安全的發行

Kubernetes 支援自動部署和復原。您描述所需狀態後，Kubernetes 會以受控速度讓實際狀態朝該目標前進。

一般使用案例

• 頻繁更新應用程式：逐步套用變更，然後在需要時還原。

• 同時部署多個服務的團隊：讓各個應用程式的發行機制保持一致。

可攜性

容器化應用程式與基礎結構是分開的，且 Kubernetes 可協助將它們從本機電腦移至實際執行環境 (涵蓋內部部署、無伺服器、混合式雲端和多雲端環境)，同時維持環境之間的一致性。

一般使用案例

• 開發/測試/實際執行環境一致性：在不同環境中維持相同的封裝和排程模型。

• 混合式部署：將系統的一部分執行於內部部署，另一部分執行於雲端，並使用相同的協調流程方法。

Kubernetes 提供一種通用方式，透過宣告式設定和機器學習自動化來執行容器化工作負載，並有大量且持續成長的工具與社群支援作為後盾。

為什麼這在雲端原生應用程式中仍然重要

隨著團隊建置由許多服務、短期工作負載和頻繁更新所組成的系統，Kubernetes 仍然是實用的基礎，因為它著重於可重複的作業：

• 跨環境的一致作業 (容器會連同相依性一起封裝，並以相同方式在各環境中執行)。

• 廣泛且活躍的生態系統，提供廣泛可用的服務、支援和工具。

• 透過社群建置的附加元件、外掛程式，以及可讓核心 API 在不同版本間維持一致的相容性計劃，實現擴充性。

如果您正在建置或執行工作負載，Azure Kubernetes Service (AKS) 可協助您部署及管理容器化應用程式，而 Azure 會管理控制平面。