Kubernetes 概念 - Amazon EKS
為什麼選擇 Kubernetes？叢集工作負載後續步驟

協助改善此頁面

想要為此使用者指南做出貢獻？ 捲動至此頁面底部，然後在 上選取編輯此頁面 GitHub。您的貢獻將幫助我們的使用者指南更適合所有人。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Kubernetes 概念

Amazon Elastic Kubernetes Service（AmazonEKS）是一種基於開源項目的 AWS 託管服務。Kubernetes雖然您需要瞭解 Amazon EKS 服務如何與 AWS 雲端整合 (特別是當您第一次建立 Amazon EKS 叢集時)，但是在啟動並執行 Amazon 叢集之後，您可以像處理任何其他EKS叢集的方式一樣使用 Amazon Kubernetes 叢集。因此，若要開始管理Kubernetes叢集和部署工作負載，您至少需要對Kubernetes概念有基本的了解。

此頁面將Kubernetes概念劃分為三個部分：為什麼選擇 Kubernetes？叢集、和工作負載。第一部分描述運行Kubernetes服務的價值，特別是像 Amazon 這樣的託管服務EKS。「工作負載」區段涵蓋Kubernetes應用程式的建置、儲存、執行和管理方式。[叢集] 區段會列出組成Kubernetes叢集的不同元件，以及建立和維護Kubernetes叢集的責任。

當您瀏覽此內容時，連結會引導您進一步瞭解 Amazon EKS 和Kubernetes文件中Kubernetes概念的詳細說明，以防您想深入探討我們在此處介紹的任何主題。如需 Amazon 如何EKS實作Kubernetes控制平面和運算功能的詳細資訊，請參閱Amazon EKS 架構。

為什麼選擇 Kubernetes？

Kubernetes在執行關鍵任務、生產品質的容器化應用程式時，可提升可用性和可擴充性。不只是在單一機器Kubernetes上執行 (儘管這是可能的)，而是讓您跨可擴充或收縮以滿足需求的電腦組執行應用程式，藉此Kubernetes達成這些目標。 Kubernetes包含的功能可讓您更輕鬆地執行以下操作：

  • 在多部機器上部署應用程式 (使用 Pod 中部署的容器)

  • 監控容器健康狀況並重新啟動失敗

  • 根據負載擴展和縮減容器

  • 使用新版本更新容器

  • 在容器之間分配資源

  • 平衡機器之間的流量

將這些類型的複雜工作Kubernetes自動化後，應用程式開發人員可以專注於建置和改善其應用程式工作負載，而不必擔心基礎結構。開發人員通常會建立描述應用程式所需狀態的組態YAML檔案 (格式化為檔案)。這可能包括要執行的容器、資源限制、Pod 複本數目、CPU/記憶體配置、相似性規則等。

的屬性 Kubernetes

為了實現其目標，Kubernetes具有以下屬性：

  • 容器化 — Kubernetes 是一種容器協調工具。若要使用Kubernetes，您必須先將應用程式容器化。視應用程式類型而定，這可能是一組微服務、批次工作或其他形式。然後，您的應用程式可以利用包含龐大工具生態系統的工Kubernetes作流程，讓容器可以作為映像儲存在容器登錄中、部署到Kubernetes叢集，並在可用節點上執行。您可以使用Docker或其他容器執行階段在本機電腦上建置和測試個別容器，然後再將它們部署到Kubernetes叢集。

  • 可擴充 — 如果您的應用程式需求超過這些應用程式執行中執行個體的容量，Kubernetes就可以擴充。視需要，Kubernetes可以判斷應用程式是否需要更多CPU記憶體，並透過自動擴充可用容量或使用更多現有容量來回應。如果有足夠的運算可用於只執行更多應用程式執行個體 (水平 Pod 自動調度資源)，或者在節點層級 (如果需要啟動更多節點來處理增加的容量 (叢集自動配置器或 Karpenter)，則可以在 Pod 層級完成擴展。由於不再需要容量，這些服務可以刪除不必要的 Pod 並關閉不需要的節點。

  • 可用 — 如果應用程式或節點運作狀態不佳或無法使用，Kubernetes可以將執行中的工作負載移至另一個可用節點。您只需刪除正在執行工作負載的工作負載或節點的執行個體，即可強制執行此問題。這裡的底線是，如果工作負載無法再在其他位置執行，就可以在其他位置提升。

  • 宣告式 — Kubernetes 使用主動式調解來持續檢查您為叢集宣告的狀態是否符合實際狀態。例如，透過將Kubernetes物件套用至叢集 (通常是透過YAML格式化的組態檔)，您可以要求啟動要在叢集上執行的工作負載。您可以稍後更改配置以執行某些操作，例如使用更高版本的容器或分配更多內存。 Kubernetes將做它需要做的事情來建立所需的狀態。這可能包括啟動或關閉節點、停止和重新啟動工作負載，或提取更新的容器。

  • 組合式 — 因為應用程式通常由多個元件組成，因此您希望能夠同時管理一組這些元件 (通常由多個容器表示)。儘管Docker撰寫提供了一種直接執行此操作的方法Docker，但 Kubernetes Kompose 命令可以幫助您使用。Kubernetes有關如何執行此操作的範例，請參閱將Docker構成檔案 Translate 為Kubernetes資源。

  • 可擴展 — 與專有軟件不同，開源Kubernetes項目旨在向您開放擴展Kubernetes任何您喜歡的方式以滿足您的需求。APIs和配置文件是開放的，以直接修改。鼓勵第三方編寫自己的控制器，以擴展基礎架構和最終用戶Kubernetes功能。Webhook 可讓您設定叢集規則以強制執行原則並適應不斷變化的條件。如需如何擴充Kubernetes叢集的詳細想法，請參閱延伸Kubernetes。

  • 可攜式 — 許多組織已將其作業標準化，Kubernetes因為它可以讓他們以相同的方式管理所有應用程式需求。開發人員可以使用相同的管道來建置和儲存容器化應用程式。然後，這些應用程式可以部署到執行內部部署、雲端、餐廳的 point-of-sales 終端機或分散在公司遠端站台的IOT裝置上的Kubernetes叢集。它的開源性質使人們有可能開發這些特殊的發Kubernetes行版，以及管理它們所需的意志工具。

管理 Kubernetes

Kubernetes源代碼是免費提供的，因此您可以使用自己的設備進行安裝和管理Kubernetes。但是，自我管理Kubernetes需要深厚的運營專業知識，並且需要時間和精力來維護。基於這些原因，大多數部署生產工作負載的人會選擇雲端供應商 (例如 AmazonEKS) 或現場部署供應商 (例如 Amazon EKS Anywhere)，並提供自己經過測試的Kubernetes分配和Kubernetes專家支援。這可讓您卸載維護叢集所需的大部分無差別繁重工作，包括：

  • 硬體 — 如果您沒有可Kubernetes根據需求執行的硬體， AWS Amazon 等雲端供應商EKS可以為您節省前期成本。透過 AmazonEKS，這表示您可以使用所提供的最佳雲端資源 AWS，包括電腦執行個體 (Amazon 彈性運算雲端)、您自己的私有環境 (AmazonVPC)、中央身分和許可管理 (IAM) 以及儲存 (AmazonEBS)。 AWS 管理運行所需的計算機，網絡，數據中心和所有其他物理組件Kubernetes。同樣地，您不必規劃資料中心處理最高需求日期的最大容量。對於 Amazon EKS Anywhere 或其他內部部署Kubernetes叢集，您必須負責管理Kubernetes部署中使用的基礎設施，但仍然可以仰賴 AWS 協助您掌握Kubernetes最新狀態。

  • 控制平面管理 — Amazon EKS 管理 AWS託管控Kubernetes制平面的安全性和可用性，該平面負責排程容器、管理應用程式的可用性和其他關鍵任務，因此您可以專注於應用程式工作負載。如果您的叢集中斷， AWS 應該可以將叢集還原至執行中狀態。對於 Amazon EKS 任何地方，您可以自己管理控制平面。

  • 經過測試的升級 — 升級叢集時，您可以仰賴 Amazon EKS 或 Amazon EKS Anywhere 來提供其Kubernetes分發的測試版本。

  • 附加元件 — 有數百個專案可擴充和使用，您可以新增至叢集的基礎架構，或使用Kubernetes這些專案來協助您執行工作負載。 AWS 提供可與叢集搭配使用的 Amazon EKS 附加元件，而不是自行建置和管理這些附加元件。Amazon EKS Anywhere 提供精選套件，其中包含許多熱門開放原始碼專案的組建。因此，您不必自行建置軟體或管理重要的安全性修補程式、錯誤修正或升級。同樣，如果默認值滿足您的需求，那麼通常只需要對這些附加組件進行非常少的配置。如需使用附加元件擴充叢集的詳細資訊，請參閱延伸叢集

Kubernetes在行動

下圖顯示您作為「Kubernetes管理員」或「應用程式開發人員」建立和使用Kubernetes叢集時可執行的重要活動。在此過程中，它說明了Kubernetes組件如何相互交互，以 AWS 雲為基礎雲提供者的示例。

集Kubernetes群在行動。

Kubernetes管理員使用特定於將在其上建立Kubernetes叢集之提供者類型的工具來建立叢集。此範例使用 AWS 雲端做為提供者，提供稱為 Amazon 的受管Kubernetes服務EKS。受管服務會自動配置建立叢集所需的資源，包括為叢集建立兩個新的虛擬私有雲端 (AmazonVPCs)、設定聯網、將許可對應到雲端中管理資產的Kubernetes許可，看到控制平面服務有可執行的地方，以及將零個或多個 Amazon EC2 執行個體配置為執行工作負載的Kubernetes節點。 AWS 為控制平面管理一個 Amazon VPC 本身，而另一個 Amazon 則VPC包含執行工作負載的客戶節點。

許多Kubernetes管理員未來的任務都是使用Kubernetes諸如kubectl. 該工具會直接向叢集的控制平面提出服務要求。對叢集進行查詢和變更的方式與您在任何Kubernetes叢集上執行這些變更的方式非常相似。

想要將工作負載部署到此叢集的應用程式開發人員可以執行多項工作。開發人員需要將應用程式建置到一或多個容器映像中，然後將這些映像推送至Kubernetes叢集可存取的容器登錄。 AWS 為此提供 Amazon 彈性容器註冊表（AmazonECR）。

若要執行應用程式，開發人員可以建立YAML格式化的組態檔，告知叢集如何執行應用程式，包括要從登錄中提取的容器，以及如何將這些容器包裝在 Pod 中。控制平面（調度程序）將容器排程到一個或多個節點，並且每個節點上的容器運行時實際上提取並運行所需的容器。開發人員也可以設定應用程式負載平衡器，以平衡每個節點上執行之可用容器的流量，並將應用程式公開，以便在公用網路上提供給外部世界。完成這一切後，想要使用該應用程序的人可以連接到應用程序端點進行訪問。

從Kubernetes叢集和工作負載的角度來看，下一節將詳細介紹這些功能的詳細資訊。

叢集

如果您的工作是啟動和管理Kubernetes叢集，您應該知道Kubernetes叢集的建立、增強、管理和刪除方式。您也應該知道組成叢集的元件是什麼，以及維護這些元件所需要採取的動作。

管理叢集的工具可處理Kubernetes服務與基礎硬體提供者之間的重疊。因此，這些任務的自動化傾向於由Kubernetes供應商（例如 Amazon EKS 或 Amazon EKS Anywhere）使用供應商特定的工具來完成。例如，要啟動 Amazon EKS 集群，您可以使用eksctl create cluster，而對於 Amazon EKS 任何地方，您可以使用eksctl anywhere create cluster。請注意，雖然這些命令會建立Kubernetes叢集，但它們是提供者特定的，而不是Kubernetes專案本身的一部分。

叢集建立和管理工具

該Kubernetes項目提供了用於手動創建Kubernetes集群的工具。所以，如果你想安裝Kubernetes在一台機器上, 或運行在一台機器上的控制平面，並手動添加節點, 您可以使用類似的CLI工具種, 縮小, 或安裝工具下列出. Kubernetes 為了簡化和自動化叢集建立和管理的完整生命週期，使用既有Kubernetes供應商 (例如 Amazon EKS 或 Amazon EKS Anywhere) 所支援的工具變得更加容易。

在 AWS 雲中，您可以使用CLI工具（例如 eksctl）或更多聲明式工具（例如 Terraform）創建 Amazon EKS 集群（請參閱地形的 Amazon EKS 藍圖）。您也可以從 AWS 管理主控台建立叢集。看到 Amazon 的EKS功能列表，你得到什麼與 AmazonEKS. KubernetesAmazon 承擔您的EKS責任包括：

若要在您自己的現場部署電腦和網路上執行叢集，Amazon 提供 Amazon EKS 隨處可用。您可以選擇使用自己的設備在裸機（小叮噹提供商）VMWarevSphere，S now 或 Nutanix 平台上運行 Amazon EKS 任何地方 CloudStack，而不是 AWS 雲端提供商。

Amazon EKS 任何地方基於 Amazon 使用EKS的相同 Amazon 發行軟件。EKS不過，Amazon EKS Anywhere 依賴Kubernetes叢集 API (CAPI) 界面的不同實作來管理 Amazon EKS Anywhere 叢集中機器的完整生命週期 (例如，CAPV適用 vSphere 和CAPC用於 CloudStack)。由於整個叢集都在您的設備上執行，因此您負擔管理控制平面及備份其資料的額外責任 (請參閱本文件稍後的 etcd)。

叢集元件

Kubernetes群集組件分為兩個主要區域：控制平面和工作節點。控制平面元件可管理叢集，並提供叢集的存取權APIs。背景工作者節點 (有時也稱為節點) 會提供執行實際工作負載的位置。節點元件包含在每個節點上執行以與控制平面通訊並執行容器的服務。叢集的工作節點集稱為「資料平面」。

控制平台

控制平面由一組管理叢集的服務組成。這些服務可能全部在單一電腦上執行，也可以分散在多部電腦上。在內部，這些例證稱為控制平面例證 (CPIs)。執行CPIs方式取決於叢集的大小和高可用性的需求。隨著叢集的需求增加，控制平面服務可以擴展以提供更多該服務的執行個體，並在執行個體之間進行負載平衡的要求。

Kubernetes控制平面元件執行的工作包括：

  • 與叢集元件 (API伺服器) 通訊 — API 伺服器 (kube-apiserver) 會公開，KubernetesAPI因此可以從叢集內部和外部發出對叢集的要求。換句話說，新增或變更叢集物件 (Pod、服務、節點等) 的要求可能來自外部命令，例如執行 Pod 的要求。kubectl同樣地，也可以從API伺服器向叢集內的元件發出要求，例如查詢kubelet服務的 Pod 狀態。

  • 儲存叢集的相關資料 (etcd索引鍵值存放區) — 此etcd服務提供追蹤叢集目前狀態的關鍵作用。如果etcd服務無法存取，您將無法更新或查詢叢集的狀態，儘管工作負載會持續執行一段時間。因此，重要叢集通常會有多個負載平衡的etcd服務執行個體一次執行，並在資料遺失或損毀時定期備份etcd索引鍵值存放區。請記住，在 Amazon 中，默認情況下EKS，這一切都是自動為您處理的。Amazon EKS 任何地方提供有關 etcd 備份和還原的說明。請參閱資etcd料模型以瞭解如何etcd管理資料。

  • 排程網繭至節點 (排程器) — 啟動或停止中網繭的請求Kubernetes會導向至Kubernetes排程器 (kube- Scheduler)。由於叢集可能有多個能夠執行 Pod 的節點，因此排程器必須由排程器選擇 Pod 應該在哪個節點 (或多個節點) 上執行。如果沒有足夠的可用容量無法在現有節點上執行要求的 Pod，除非您已進行其他規定，否則要求將失敗。這些規定可能包括啟用可自動啟動新節點以處理工作負載的服務，例如受管節點群組或 Karpenter。

  • 將元件保持在想要的狀態 (控制器管理員) — Kubernetes 控制器管理員會以精靈處理程序 (kube-controller-manager) 的形式執行，以監視叢集的狀態並變更叢集以重新建立預期的狀態。特別是，有幾個控制器可以監視不同的Kubernetes對象，其中包括statefulset-controller，endpoint-controller，cronjob-controllernode-controller，和其他控制器。

  • 管理雲端資源 (Cloud Controller Manager) — 雲端供應商Kubernetes與執行基礎資料中心資源要求的雲端供應商之間的互動，會由雲端控制器管理員 (cloud-controller-manager) 處理。由 Cloud Controller Manager 管理的控制器可包括路由控制器（用於設定雲端網路路由）、服務控制器（用於使用雲端負載平衡服務）和節點生命週期控制器（在節點的整個生命週期中保持與 Kubernetes 同步）。

工作者節點 (資料平面)

對於單一節點Kubernetes叢集，工作負載會在與控制平面相同的機器上執行。不過，較正常的組態是擁有一個或多個專用於執行Kubernetes工作負載的獨立電腦系統 (Nodes)。

當您第一次建立Kubernetes叢集時，某些叢集建立工具可讓您設定要新增至叢集的特定數目節點 (透過識別現有的電腦系統或讓提供者建立新的電腦系統)。在將任何工作負載新增至這些系統之前，服務會新增至每個節點以實作下列功能：

  • 管理每個節點 (kubelet) — API 伺服器會與每個節點上執行的 kubelet 服務通訊，以確保節點已正確註冊，且排程器要求的 Pod 正在執行中。kubelet 可以讀取 Pod 資訊清單，並設定儲存磁碟區或本機系統上 Pod 所需的其他功能。它也可以檢查本機執行中容器的健康狀況。

  • 在節點上執行容器 (容器執行階段) — 每個節點上的容器執行階段會管理針對指派給節點的每個 Pod 所請求的容器。這意味著它可以從適當的註冊表中提取容器映像，運行容器，停止它，並響應有關容器的查詢。預設 containerd 執行階段為容器。從 Kubernetes 1.24 開始，可以用作容器運行時的Docker（dockershim）的特殊集成已從中Kubernetes刪除。雖然您仍然可Docker以使用在本機系統上測試和執行容器，但若要Docker搭配Kubernetes使用，您現在必須在每個節點上安裝Docker引擎才能搭配使用Kubernetes。

  • 管理容器之間的網路 (kube-proxy) — 為了能夠使用服務支援網繭之間的通訊，Kubernetes需要一種方法來設定 Pod 網路來追蹤與這些網繭相關聯的 IP 位址和連接埠。kube-proxy 服務會在每個節點上執行，以允許 Pod 之間進行通訊。

擴充叢集

您可以新增一些服務Kubernetes來支援叢集，但不會在控制平面中執行。這些服務通常直接在 kube-system 命名空間中的節點上或其自己的命名空間中運行（通常與第三方服務提供者一樣）。一個常見的例子是 Core DNS 服務，它為叢集提供DNS服務。如需如何查看叢集上的 kube-system 中執行哪些叢集服務的詳細資訊，請參閱探查內建服務。

您可以考慮將不同類型的附加元件新增至叢集。為了保持叢集的健康狀態，您可以新增可觀察性功能，讓您執行記錄、稽核和指標等操作。有了這些資訊，您就可以疑難排解發生的問題，通常是透過相同的可觀察性介面。這些類型的服務的例子包括 Amazon GuardDuty CloudWatch, AWS 發行版 OpenTelemetry, Amazon VPC CNI 插件Kubernetes, 和 Graf Kubernetes ana 監控. 對於儲存，Amazon 的附加元件EKS包括 Amazon 彈性區塊存放區CSI驅動程式 (用於新增區塊儲存裝置)、Amazon Elastic File System CSI 驅動程式 (用於新增檔案系統儲存) 和數個第三方儲存附加元件 (例如 Amazon FSx 的 NetApp ONTAPCSI驅動程式)。

如需可用 Amazon EKS 附加元件的更完整清單，請參閱Amazon EKS 插件。

工作負載

Kubernetes將工作負載定義為「在上執行的應用程式」Kubernetes。該應用程式可以包含一組以 Pod 中的容器形式執行的微服務，也可以作為批次工作或其他類型的應用程式執行。的工作Kubernetes是確定已執行您對要設定或部署的物件所發出的要求。在部署應用程式時，您應該瞭解如何建置容器、如何定義 Pod，以及可以使用哪些方法來部署它們。

容器

您在中部署和管理的應用程式工作負載中最基本的元素Kubernetes是 Pod。Pod 代表保存應用程式元件以及定義描述 Pod 屬性之規格的方式。將其與類似於RPM或 Deb 軟件包（將軟件包裝在一起為 Linux 系統打包在一起，但本身並不作為實體運行）相反。

由於 Pod 是最小的可部署單位，因此它通常會保留單一容器。但是，在容器緊密耦合的情況下，多個容器可以位於 Pod 中。例如，Web 伺服器容器可能會封裝在具有附屬容器類型的 Pod 中，該容器可能會提供記錄、監視或其他與 Web 伺服器容器緊密相關的服務。在此情況下，位於同一個 Pod 中，可確保對於 Pod 的每個執行個體，兩個容器一律在同一個節點上執行。同樣地，Pod 中的所有容器共用相同的環境，Pod 中的容器在執行時，就像它們位於相同的隔離主機中一樣。這樣做的效果是容器共用單一 IP 位址，該 IP 位址可提供對 Pod 的存取，而且容器可以彼此通訊，就像它們在自己的本機主機上執行一樣。

網繭規格 (PodSpec) 定義所需的網繭狀態。您可以使用工作負載資源來管理網繭範本，來部署個別網繭或多個網繭。工作負載資源包括部署 (用於管理多個網繭複本)、StatefulSets(用於部署需要唯一的網繭，例如資料庫網繭)，以及 DaemonSets(網繭需要在每個節點上持續執行)。更多關於那些以後。

雖然 Pod 是您部署的最小單位，但容器是您建置和管理的最小單位。

建築容器

Pod 實際上只是圍繞一個或多個容器的結構，每個容器本身都保存文件系統，可執行文件，配置文件，庫和其他組件來實際運行應用程序。因為一家名為 Docker Inc. 的公司首先普及的容器，有些人稱容器為Docker容器。然而，「開放容器計劃」 已經定義了產業的容器執行階段、映像和散發方法。除此之外，容器是從許多現有 Linux 功能創建的，其他功能通常將容器稱為OCI容器，Linux 容器或只是容器。

當您建置容器時，通常會從Docker檔案開始 (字面上命名為該檔案)。在該碼頭文件中，您確定：

  • 基本映像檔 — 基礎容器映像檔是一種容器，通常是以最小版本的作業系統檔案系統 (例如 Red Hat Enterprise Linux 或 Ubuntu) 所建立，或是經過強化的最小系統，可提供軟體來執行特定類型的應用程式 (例如 nodejs 或 python 應用程式)。

  • 應用程式軟體 — 您可以將應用程式軟體新增至容器，方法與將其新增至 Linux 系統的方式相同。例如，在您的 Docker 文件中，您可以運行npm並yarn安裝 Java 應用程序或yum安裝RPM軟dnf件包。換句話說，使用 Dockerfile 中的RUN命令，您可以運行基本映像文件系統中可用的任何命令，以在生成的容器映像內安裝軟件或配置軟件。

  • 指示 — Docker 檔案參考描述了您在配置檔案時可以新增至 Docker 檔案的指示。這些指令包括用來建置容器本身中的內容 (ADD或來自本機系統的COPY檔案)、識別容器執行時要執行的命令 (CMD或ENTRYPOINT)，以及將容器連接至其執行的系統 (藉由識別USER要執行的身分、VOLUME要掛載的本機或連接埠EXPOSE)。

雖然命docker令和服務傳統上是用來建置容器 (docker build)，但其他可用來建立容器映像檔的工具包括podman和nerdctl。請參閱建置更好的容器映像檔或使用建置Docker來瞭解如何建置容器。

儲存容器

建立容器映像之後，您可以將其儲存在工作站的容器散發登錄中，或是公用容器登錄中。在工作站上執行私人容器登錄可讓您在本機儲存容器映像，讓您隨時可以取得容器映像檔。

若要以更公開的方式儲存容器映像檔，您可以將它們推送至公用容器登錄。公用容器登錄提供儲存和散發容器映像的中央位置。公用容器登錄的範例包括 Amazon 彈性容器登錄、Red Hat Quay 登錄和Docker集線器登錄。

在 Amazon 彈性 Kubernetes 服務 (亞馬遜EKS) 上執行容器化工作負載時，我們建議您提取存放在 Amazon 彈性容器登錄中的Docker官方映像副本。 AWS 自 2021 年以來，Amazon ECR 一直在存儲這些圖像。您可以在 Amazon ECR 公共圖庫中搜索流行的容器映像，特別是對於Docker集線器映像，您可以搜索 Amazon 圖ECRDocker庫。

執行容器

由於容器是以標準格式建置，因此容器可以在任何可執行容器執行階段 (例如Docker) 且其內容符合本機電腦架構 (例如x86_64或arm) 的機器上執行。要測試容器或僅在本地桌面上運行它，您可以使用docker run或podman run命令在本地主機上啟動容器。但是Kubernetes，對於每個 Worker 節點都已部署容器執行階段，並且由Kubernetes要求節點執行容器。

指派要在節點上執行的容器之後，節點會查看要求的容器映像版本是否已存在於節點上。如果沒有，請Kubernetes告知容器執行階段從適當的容器登錄中提取該容器，然後在本機執行該容器。請記住，容器映像檔是指在筆記型電腦、容器登錄和Kubernetes節點之間移動的軟體套件。容器是指該映像檔的執行中執行個體。

豆莢

容器準備就緒後，使用 Pod 就會包括設定、部署和使 Pod 可供存取。

設定網繭

定義網繭時，您可以為其指派一組屬性。這些屬性至少必須包含要執行的 Pod 名稱和容器映像。但是，您還需要使用 Pod 定義配置許多其他內容（有關可以進入 Pod 的詳細信息，請參閱PodSpec頁面）。其中包含：

  • 儲存空間 — 停止並刪除執行中的容器時，除非您設定更多永久儲存空間，否則該容器中的資料儲存將會消失。 Kubernetes支持許多不同的存儲類型，並在 Volumes 的保護傘下對它們進行抽象化。儲存類型包括 CAFs、NFS、i SCSI 和其他儲存空間。您甚至可以使用本地計算機上的本地塊設備。透過叢集提供的其中一種儲存區類型，您就可以將儲存磁碟區掛接至容器檔案系統中選取的掛載點。持續性磁碟區是在刪除網繭後繼續存在的磁碟區，而暫時磁碟區會在刪除網繭時刪除。如果您的叢集管理員StorageClasses為叢集建立了不同的選項，您可以選擇所使用的儲存屬性，例如磁碟區是否在使用後刪除或回收磁碟區、在需要更多空間時是否會擴充磁碟區，以及是否符合特定的效能需求。

  • 秘密 — 透過將 Secret 提供給 Pod 規格中的容器使用，您可以提供這些容器存取檔案系統、資料庫或其他受保護資產所需的權限。密鑰，密碼和令牌是可以存儲為秘密的項目之一。使用秘密可以讓您不必將此資訊儲存在容器映像檔中，而只需要將密碼提供給執行容器。類似於秘密ConfigMaps。A ConfigMap 傾向於保存較不重要的信息，例如用於配置服務的鍵值對。

  • 容器資源 — 用於進一步配置容器的物件可以採用資源配置的形式。對於每個容器，您可以請求內存量和可CPU以使用的內存量，以及對容器可以使用的這些資源的總量進行限制。如需範例，請參閱網繭和容器的資源管理。

  • 中斷 — Pod 可能會非自願中斷 (節點當機) 或自願中斷 (需要升級)。透過設定 Pod 中斷預算，您可以對發生中斷時應用程式保留的可用程式進行一些控制。如需範例，請參閱指定應用程式的中斷預算。

  • 命名空間 — Kubernetes 提供不同的方式來隔離Kubernetes元件和工作負載。針對相同命名空間中的特定應用程式執行所有 Pod，是一起保護和管理這些 Pod 的常用方式。您可以創建自己的命名空間來使用或選擇不指示命名空間（這會導Kubernetes致使用default命名空間）。 Kubernetes控制平面組件通常在kube-system命名空間中運行。

剛才描述的組態通常會聚集在一個YAML檔案中，以套用至Kubernetes叢集。對於個人Kubernetes叢集，您可能只是將這些YAML檔案儲存在本機系統上。但是，對於更重要的叢集和工作負載，GitOps是一種自動化工作負載和Kubernetes基礎架構資源的儲存和更新的熱門方式。

用來收集和部署 Pod 資訊的物件是由下列其中一種部署方法所定義。

部署 Pod

您選擇用於部署 Pod 的方法取決於您打算使用這些 Pod 執行的應用程式類型。以下是您的一些選擇：

  • 無狀態應用程式 — 無狀態應用程式不會儲存用戶端的工作階段資料，因此另一個工作階段不需要參考前一個工作階段發生的事情。如果 Pod 變得不健康，或者在不保存狀態的情況下四處移動它們，則可以更輕鬆地用新的 Pod 替換。如果您正在執行無狀態應用程式 (例如 Web 伺服器)，則可以使用部署來部署 Pod 和 ReplicaSets. A ReplicaSet 定義您要同時執行的 Pod 執行個體數目。雖然您可以 ReplicaSet 直接執行，但通常是直接在部署中執行複本，以定義一次應該執行多少 Pod 複本。

  • 可設定狀態的應用程式 — 可設定狀態的應用程式是 Pod 的身分識別以及 Pod 啟動的順序很重要的應用程式。這些應用程式需要穩定且需要以一致的方式部署和擴充的持續性儲存裝置。若要在中部署可設定狀態應用程式Kubernetes，您可以使用 StatefulSets. 通常以資料庫形式執行的應用 StatefulSet 程式範例。在 a 中 StatefulSet，您可以定義複本、Pod 及其容器、要掛接的儲存磁碟區，以及儲存資料的容器中的位置。如需部署為資料庫的範例，請參閱執行複寫的可設定狀態應用程式 ReplicaSet。

  • 每節點應用程式 — 有時您會想要在Kubernetes叢集中的每個節點上執行應用程式。例如，您的資料中心可能需要每台電腦執行監視應用程式或特定的遠端存取服務。對於Kubernetes，您可以使用 a DaemonSet來確保選取的應用程式在叢集中的每個節點上執行。

  • 應用程式執行到完成 — 您想要執行某些應用程式來完成特定工作。這可能包括運行每月狀態報告或清除舊數據的報告。Job 物件可用來設定應用程式以啟動和執行，然後在工作完成時結束。CronJob物件可讓您使用 Linux crontab格式定義的結構，將應用程式設定為在特定的小時、分鐘、月份、月份或星期幾執行。

讓應用程式可從網路存取

由於應用程式通常部署為一組微服務，並移動到不同的地方，因此Kubernetes需要一種方法讓這些微服務能夠彼此找到。此外，若要讓其他人存取Kubernetes叢集外部的應用程式，則Kubernetes需要在外部位址和連接埠上公開該應用程式的方法。這些與網路相關的功能分別是透過 Service 和 Ingress 物件完成的：

  • 服務 — 由於 Pod 可以四處移動到不同的節點和位址，因此需要與第一個 Pod 通訊的另一個 Pod 可能會發現很難找到它所在的位置。若要解決這個問題，Kubernetes可讓您將應用程式表示為服務。使用服務，您可以使用特定名稱識別網繭或一組網繭，然後指出從 Pod 公開該應用程式服務的連接埠，以及其他應用程式可用來連絡該服務的連接埠。叢集中的另一個 Pod 可以直接依名稱要求服務，並Kubernetes將該要求導向至執行該服務之 Pod 執行個體的適當連接埠。

  • Ingress — Ingress 可讓「Kubernetes服務」代表的應用程式提供給叢集外部的用戶端使用。Ingress 的基本功能包括負載平衡器 (由 Ingress 管理)、Ingress 控制器，以及將要求從控制器路由到服務的規則。您可以選擇多種入口控制器。Kubernetes

後續步驟

了解基本Kubernetes概念以及它們與 Amazon 的關係EKS將協助您瀏覽 Amazon EKS 文件和Kubernetes文件，以尋找管理 Amazon EKS 叢集和將工作負載部署到這些叢集所需的資訊。要開始使用 AmazonEKS，請從以下選項中進行選擇：