什麼是 Kubernetes 架構？ 重要性+最佳實踐

自 2014 年以來，Kubernetes 在採用方面經歷了巨大的增長。受 Google 內部集群管理解決方案 Borg 的啟發，Kubernetes 簡化了應用程序的部署和管理。 與所有容器編排軟件一樣，Kubernetes 在 IT 專業人士中越來越受歡迎，因為它安全且簡單。 然而，與所有工具一樣，了解其架構如何幫助您更有效地使用它。

讓我們了解 Kubernetes 架構的基礎，從它是什麼、它做什麼以及為什麼重要開始。

谷歌創建了適應性強的 Kubernetes 容器管理系統，它可以跨多種設置處理容器化應用程序。 它有助於自動化容器化應用程序部署、進行更改以及擴展和縮減這些應用程序。

不過，Kubernetes 不僅僅是一個容器編排器。 同樣，桌面應用程序可以在 MacOS、Windows 或 Linux 上運行； 它是雲原生應用程序的操作系統，因為它充當這些程序的雲平台。

什麼是容器？

容器是一種用於打包應用程序及其依賴項的標準方法，以便可以輕鬆地跨運行時環境執行應用程序。 使用容器，您可以採取基本措施，通過將應用程序的代碼、依賴項和配置打包到一個易於使用的構建塊中來減少部署時間和提高應用程序的可靠性。

公司應用程序中的容器數量可能變得難以管理。 為了充分利用您的容器，Kubernetes 可以幫助您編排它們。

Kubernetes 有什麼用？

Kubernetes 是一個用於運行容器工作負載的適應性和可擴展性極強的平台。 Kubernetes 平台不僅提供創建雲原生應用程序的環境，還有助於管理和自動化部署。

它旨在減輕應用程序運營商和開發人員協調底層計算、網絡和存儲基礎設施的工作，使他們能夠專注於以容器為中心的自助服務操作流程。 開發人員還可以創建專門的部署和管理程序，以及由多個容器組成的應用程序的更高級別的自動化。

Kubernetes 可以處理所有重要的後端工作負載，包括單體應用程序、無狀態或有狀態程序、微服務、服務、批處理作業以及介於兩者之間的一切。

通常選擇 Kubernetes 有以下好處。

• Kubernetes 的基礎架構優於許多 DevOps 技術。
• Kubernetes 將容器分解成更小的組件以進行精確管理。
• Kubernetes 會快速且定期地部署軟件更新。
• Kubernetes 提供了一個用於開發雲原生應用程序的平台。

Kubernetes 架構和組件

基本的 Kubernetes 架構包含許多組件，也稱為 K8s 組件，因此在我們開始之前，記住以下概念很重要。

• 基本的 Kubernetes 架構由管理節點和執行容器化應用程序的工作節點的控制平面組成。
• 當控制平面管理執行和通信時，工作節點實際上運行這些容器。
• 一個 Kubernetes 集群是一組節點，每個集群至少有一個工作節點。

Kubernetes 架構圖

Kubernetes 控制平面

控制平面是 Kubernetes 集群設計的中樞神經系統中心，容納了集群的控制組件。 它還記錄集群中所有 Kubernetes 對象的配置和狀態。

Kubernetes 控制平面與計算單元保持定期通信，以確保集群按預期運行。 控制器監督對象狀態並使系統對象的物理、觀察狀態或當前狀態適應所需的狀態或規範以響應集群變化。

控制平面由幾個基本元素組成，包括應用程序編程接口 (API) 服務器、調度程序、控制器管理器和 etcd。 這些基本的 Kubernetes 組件保證容器在適當的資源下運行。 這些組件都可以在單個主節點上運行，但許多公司將它們複製到多個節點上以實現高可用性。

1. Kubernetes API 服務器

Kubernetes API 服務器是 Kubernetes 控制平面的前端。 它通過為各種應用程序提供 API 管理來促進更新、擴展、配置數據和其他類型的生命週期編排。 因為 API server 是網關，所以用戶必須能夠從集群外部訪問它。 在這種情況下，API 服務器是通往 pod、服務和節點的隧道。 用戶通過 API 服務器進行身份驗證。

2. Kubernetes 調度器

kube-scheduler 記錄每個計算節點的資源利用率統計信息，評估集群是否健康，並決定是否部署新容器以及在何處部署新容器。 調度程序評估集群的整體健康狀況和 pod 的資源需求，例如中央處理器 (CPU) 或內存。 然後它選擇合適的計算節點並調度任務、pod 或服務，考慮資源約束或保證、數據局部性、服務質量要求、反親和性或親和性標準。

3. Kubernetes控制器管理器

在 Kubernetes 環境中，多個控制器管理端點（pod 和服務）、令牌和服務帳戶（命名空間）、節點和復制（自動縮放）的狀態。 kube-controller 管理器，通常稱為雲控制器管理器或控制器，是一個守護進程，通過執行各種控制器職責來管理 Kubernetes 集群。

控制器在運行 Kubernetes 核心控制循環時監控集群中的對象。 它通過 API 服務器監視它們的期望狀態和現有狀態。 如果被管理對象的當前狀態和預期狀態不匹配，控制器會採取糾正措施，使對象狀態更接近所需狀態。 Kubernetes 控制器還處理基本的生命週期任務。

4.等

etcd 是一個分佈式、容錯的鍵值存儲數據庫，用於保存配置數據和集群狀態信息。 儘管 etcd 可以獨立設置，但它通常作為 Kubernetes 控制平面的一部分。

集群狀態使用 raft 共識算法保存在 etcd 中。 這有助於處理複製狀態機上下文中的典型問題，並且需要許多服務器就值達成一致。 Raft 建立了 leader、candidate 和 follower 三種角色，通過投票選出 leader 來達成共識。

因此，etcd 是所有 Kubernetes 集群組件的單一真實來源 (SSOT)，響應控制平面查詢並收集有關容器、節點和 pod 狀態的不同信息。 etcd 還用於存儲配置信息，如 ConfigMap、子網、機密和集群狀態數據。

Kubernetes 工作節點

工作節點是運行控制平面管理的容器的系統。 kubelet——核心 Kubernetes 控制器——在每個節點上運行，作為與控制平面交互的代理。 此外，每個節點都運行一個容器運行時引擎，例如 Docker 或 rkt。 用於監視、日誌記錄、服務發現和可選附加功能的其他組件也在該節點上運行。

一些關鍵的 Kubernetes 集群架構組件如下。

節點

一個 Kubernetes 集群必須至少有一個計算節點，但根據容量需求可以有更多。 因為 Pod 是協調和調度在節點上執行的，所以需要額外的節點來增加集群容量。 節點執行 Kubernetes 集群的工作。 它們鏈接應用程序以及網絡、計算和存儲資源。

數據中心中的節點可能是雲原生虛擬機 (VM) 或裸機服務器。

容器運行時引擎

每個計算節點都使用容器運行時引擎來運行和管理容器生命週期。 Kubernetes 支持開放容器倡議兼容的運行時，如 Docker、CRI-O 和 rkt。

Kubelet 服務

每個計算節點上都包含一個 kubelet。 它是一個與控制平面通信以保證 pod 中的容器正常運行的代理。 當控制平面要求在節點中執行特定操作時，kubelet 通過 API 服務器獲取 Pod 規範並進行操作。 然後確保相關容器處於良好的工作狀態。

Kube 代理服務

每個計算節點都有一個稱為 kube-proxy 的網絡代理，它有助於 Kubernetes 網絡服務。 為了管理集群內外的網絡連接，kube-proxy 要么轉發流量，要么依賴於操作系統的包過濾層。

kube-proxy 進程在每個節點上運行，以確保服務對其他方可用，並處理特定的主機子網劃分。 它在其節點上充當網絡代理和服務負載平衡器，處理用戶數據報協議 (UDP) 和傳輸控制協議 (TCP) 流量的網絡路由。 實際上，kube-proxy 為所有服務端點路由流量。

豆莢

到目前為止，我們已經介紹了內部和基礎設施相關的想法。 然而，Pod 對 Kubernetes 至關重要，因為它們是開發人員與之交互的主要外向組件。

Pod 是 Kubernetes 容器模型中最簡單的單元，代表應用程序的單個實例。 每個 Pod 包含一個容器或幾個緊密相關的容器，這些容器在邏輯上組合在一起並執行管理容器功能的規則。

Pod 的壽命有限，在升級或縮減後最終會死亡。 雖然是短暫的，但它們通過連接到持久存儲來執行有狀態的應用程序。

Pod 也可以水平擴展，這意味著它們可以增加或減少運行的實例數量。 他們還能夠進行滾動更新和金絲雀部署。

Pod 一起在節點上運行，因此它們共享內容和存儲，並且可以通過本地主機與其他 Pod 通信。 容器可能跨越多台計算機，pod 也可以。 一個節點可以操作多個 pod，每個 pod 收集許多容器。

Pod 是 Kubernetes 生態系統中的中央管理單元，作為共享資源和上下文的容器的邏輯邊界。 Pod 分組方法允許多個依賴進程同時運行，從而減輕了虛擬化和容器化之間的差異。

其他 Kubernetes 架構組件

Kubernetes 維護應用程序的容器，但也可以管理集群中的關聯應用程序數據。 Kubernetes 的用戶可以在不了解底層存儲基礎設施的情況下請求存儲資源。

Kubernetes 卷是 pod 可以訪問和存儲數據的目錄。 卷類型決定了卷的內容、它是如何形成的以及支持它的媒體。 持久卷 (PV)是特定於集群的存儲資源，通常由管理員提供。 PV 也可以比給定的 pod 更長壽。

Kubernetes 依賴於存儲在容器註冊表中的容器映像。 它可能是第三方註冊或組織創建的註冊。

命名空間是存在於物理集群中的虛擬集群。 它們旨在為眾多用戶和團隊創建獨立的工作環境。 他們還通過限制他們可以訪問的 Kubernetes 對象來防止團隊相互干擾。 Pod 內的 Kubernetes 容器可以通過本地主機與其他 Pod 通信，並共享 IP 地址和網絡命名空間。

Kubernetes 與 Docker Swarm

Kubernetes 和 Docker 都是提供容器管理和應用擴展的平台。 Kubernetes提供了一種有效的容器管理解決方案，非常適合具有復雜設置的高需求應用程序。 相比之下， Docker Swarm是為簡單而構建的，使其成為快速部署和維護的基本應用程序的絕佳選擇。

• Docker Swarm 比 Kubernetes 更容易部署和配置。
• Kubernetes 提供基於流量的一體式可擴展性，而 Docker Swarm 優先考慮快速擴展。
• 自動負載平衡在 Docker Swarm 中可用，但在 Kubernetes 中不可用。 但是，第三方解決方案可能會將外部負載均衡器鏈接到 Kubernetes。

貴公司的需求決定了正確的工具。

容器編排解決方案

容器編排系統使開發人員能夠啟動多個容器以進行應用程序部署。 IT 經理可以使用這些平台來自動管理實例、採購主機和連接容器。

以下是一些最好的容器編排工具，它們可以促進部署、識別失敗的容器實施以及管理應用程序配置。

Kubernetes 架構最佳實踐和設計原則

實施考慮安全性、治理、監控、存儲、網絡、容器生命週期管理和編排的平台戰略至關重要。 然而，Kubernetes 在採用和擴展方面具有廣泛的挑戰性，特別是對於同時管理本地和公共雲基礎設施的企業而言。 為了簡化它，下面討論了在構建 kubernetes 集群時必須考慮的一些最佳實踐。

• 確保您始終擁有最新版本的 Kubernetes。
• 投資於開發和運營團隊的培訓。
• 建立全公司治理。 確保您的工具和提供程序與 Kubernetes 編排兼容。
• 通過在持續集成和交付 (CI/CD) 工作流程中包含圖像掃描技術來提高安全性。 從 GitHub 存儲庫下載的開源代碼應始終謹慎對待。
• 在整個集群中實施基於角色的訪問控制(RBAC)。 基於最小特權和零信任的模型應該成為規範。
• 僅使用非 root 用戶並將文件系統設置為只讀以進一步保護容器。
• 避免使用默認值，因為簡單的聲明不容易出錯並且可以更好地傳達目的。
• 在使用基本的 Docker Hub 鏡像時，要小心，因為它們可能包含惡意軟件​​或被不需要的代碼所淹沒。 從精簡、乾淨的代碼開始，逐步提升。 較小的圖片增長得更快，佔用的存儲空間更少，拉取圖像的速度也更快。
• 使容器盡可能簡單。 每個容器一個進程允許編排器報告該進程是否健康。
• 有疑問時崩潰。 不要在失敗時重啟，因為 Kubernetes 會重啟失敗的容器。
• 具有描述性。 描述性標籤有利於現在和未來的開發人員。
• 說到微服務，不要太具體。 邏輯代碼組件中的每個功能都不能是它的微服務。
• 在可能的情況下，自動化。 您可以通過自動化 CI/CD 工作流來完全跳過手動 Kubernetes 部署。
• 使用 liveliness 和 readiness 探針來協助管理 pod 生命週期； 否則，Pod 可能會在初始化或接收用戶請求之前就被終止。

考慮你的容器

由於容器在企業中的廣泛使用，以容器為中心的管理軟件 Kubernetes 已成為部署和運行容器化應用程序的事實標準。 Kubernetes 架構簡單直觀。 雖然它使 IT 經理能夠更好地控制其基礎架構和應用程序性能，但要充分利用該技術還有很多東西需要學習。

想進一步探索這個主題？ 了解容器化在雲計算中日益增長的相關性！