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

協助改進此頁面

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的在 GitHub 上編輯此頁面連結。

Kubernetes 概念

Amazon Elastic Kubernetes Service (Amazon EKS) 是以開放原始碼 Kubernetes 專案為基礎的 AWS 受管服務。雖然您需要了解 Amazon EKS 服務如何與 AWS 雲端整合 (特別是當您首次建立 Amazon EKS 叢集時)，但一旦 Amazon EKS 叢集啟動並執行，您使用 Amazon EKS 叢集的方式就會與任何其他 Kubernetes 叢集想通。因此，若要開始管理 Kubernetes 叢集並部署工作負載，您至少需要對 Kubernetes 概念有基本的了解。

此頁面將 Kubernetes 概念分為三個部分：為什麼選擇 Kubernetes？、叢集 和 工作負載。第一部分說明執行 Kubernetes Service 的價值，特別是 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 層級進行擴展 (水平 Pod 自動擴展)；如果需要新增更多節點來處理增加的容量，則可以在節點層級進行擴展 (Cluster Autoscaler 或 Karpenter)。由於不再需要容量，這些服務可以刪除不必要的 Pod 並關閉不需要的節點。

  • 可用：如果應用程式或節點運作狀態不佳或不可用，則 Kubernetes 可以將執行中的工作負載移動至另一個可用的節點。您只需刪除工作負載的執行中的執行個體或執行工作負載的節點，即可強制解決此問題。此時的底線是，如果工作負載無法再原地執行，則可以將它們移動到其他位置。

  • 宣告：Kubernetes 使用主動調解，以持續檢查您為叢集宣告的狀態是否與實際狀態相符。例如，透過將 Kubernetes 物件套用至叢集 (通常是藉助 YAML 格式的組態檔案)，您可以要求啟動要在叢集上執行的工作負載。您稍後即可變更組態以執行某些動作，例如使用較新版本的容器或配置更多記憶體。Kubernetes 會執行一些必要動作，以建立所需狀態。這可能包括啟動或關閉節點、停止和重新啟動工作負載，或是提取更新的容器。

  • 可組合：由於應用程式通常由多個元件組成，因此您希望能夠對這些元件進行統一管理 (通常由多個容器表示)。雖然 Docker Compose 提供了直接使用 Docker 執行此動作的方法，但 Kubernetes Kompose 命令可協助您使用 Kubernetes 執行此動作。如需如何執行此動作的範例，請參閱將 Docker Compose 檔案轉換為 Kubernetes 資源。

  • 可擴展：與專屬軟體不同，開放原始碼 Kubernetes 專案旨在讓您以任何您想要的方式擴展 Kubernetes，進而滿足您的需求。開啟 API 和組態檔案，以直接進行修改。建議第三方編寫自己的控制器，以擴展基礎結構和最終使用者 Kubernetes 功能。Webhook 可讓您設定叢集規則，以強制執行政策並適應不斷變化的條件。如需如何擴展 Kubernetes 叢集的更多想法，請參閱擴展 Kubernetes。

  • 可攜式：許多組織已在 Kubernetes 上將其操作標準化，因為它允許他們以相同的方式管理其所有應用程式需求。開發人員可以使用相同的管道來建置和儲存容器化應用程式。然後，這些應用程式可以部署到在內部部署、雲端、餐廳的銷售點終端機或分散在公司遠端網站的 IOT 裝置上執行的 Kubernetes 叢集。其開放原始碼性質讓相關人員能夠開發這些特殊的 Kubernetes 分佈，以及管理它們所需的工具。

管理 Kubernetes

Kubernetes 原始程式碼會免費提供，因此您可以使用自己的設備自行安裝和管理 Kubernetes。不過，自我管理 Kubernetes 需要深入的操作專業知識，而且進行維護亦需要耗費時間和精力。基於這些原因，大多數部署生產工作負載的人員都會選擇雲端提供者 (例如 Amazon EKS) 或內部部署提供者 (例如 Amazon EKS Anywhere)，而這些提供者皆擁有其自己經過測試的 Kubernetes 分佈和 Kubernetes 專家的支援。這可讓您卸載維護叢集所需的大部分無差別的繁重任務，包括：

  • 硬體：如果您沒有可用的硬體來根據您的需求執行 Kubernetes，那麼 AWS Amazon EKS 等雲端提供者可以為您節省預付成本。使用 Amazon EKS，這表示您可以使用 AWS 提供的最佳雲端資源，包括電腦執行個體 (Amazon Elastic Compute Cloud)、您自己的私有環境 (Amazon VPC)、集中身分識別和許可管理 (IAM) 及儲存 (Amazon EBS)。AWS 負責管理電腦、網路、資料中心以及執行 Kubernetes 所需的所有其他實體元件。同樣地，您不需要規劃資料中心，即可在需求最高的時日處理最大容量。對於 Amazon EKS Anywhere 或其他內部部署 Kubernetes 叢集，您需負責管理 Kubernetes 部署中使用的基礎結構，但您仍可依賴 AWS 來協助您確保 Kubernetes 保持在最新狀態。

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

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

  • 附加元件：建置數百個專案，以擴展和使用 Kubernetes，而您可以將這些專案新增至叢集的基礎結構，或使用這些專案來協助工作負載的執行。您無需自己建置和管理這些附加元件，因為 AWS 提供了可與叢集搭配使用的 Amazon EKS 附加元件。Amazon EKS Anywhere 提供精製套件，其中包含了眾多熱門的開放原始碼專案的建置版本。因此，您無需自行建置軟體或管理重要的安全修補程式、錯誤修正或升級。同樣地，如果預設符合您的需求，則通常只需要對這些附加元件進行極少的設定即可。如需使用附加元件擴展叢集的詳細資訊，請參閱 擴展叢集。

執行中的 Kubernetes

下圖顯示您身為 Kubernetes 管理員或應用程式開發人員要建立和使用 Kubernetes 叢集的關鍵活動。在此過程中，它會使用 AWS 雲端作為基礎雲端提供者的範例，以此說明 Kubernetes 元件會如何彼此互動。

執行中的 Kubernetes 叢集。

Kubernetes 管理員會使用要建置叢集的此類提供者的專用工具來建立 Kubernetes 叢集。此範例使用 AWS 雲端作為提供者，而其會提供稱為 Amazon EKS 的受管 Kubernetes Service。受管服務會自動配置建立叢集所需的資源，包括為叢集建立兩個新的虛擬私有雲端 (Amazon VPC)、設定聯網，以及將 Kubernetes 許可與新的 VPC 直接進行對應，進而執行雲端資產管理。受管服務也會看到控制平面服務具有執行和配置零或多個 Amazon EC2 執行個體作為執行工作負載的 Kubernetes 節點的位置。AWS 會自行管理控制平面的一個 Amazon VPC，而另一個 Amazon VPC 包含執行工作負載的客戶節點。

許多 Kubernetes 管理員的後續任務都需要使用 Kubernetes 工具來完成，例如 kubectl。該工具會直接向叢集的控制平面發出服務請求。然後，對叢集執行查詢和變更的方式與您在任何 Kubernetes 叢集上執行查詢和變更的方式非常類似。

想要將工作負載部署到此叢集的應用程式開發人員可以執行數個任務。開發人員需要將應用程式建置到一或多個容器映像中，然後將這些映像推送到可供 Kubernetes 叢集存取的容器登錄檔。為此，AWS 提供了 Amazon Elastic Container Registry (Amazon ECR)。

若要執行應用程式，開發人員可以建立 YAML 格式的組態檔案，告訴叢集如何執行應用程式，包括要從登錄檔提取哪些容器以及如何將這些容器包裝在 Pod 中。控制平面 (排程器) 會將容器排程至一或多個節點，而每個節點上的容器執行時期實際上會提取及執行所需的容器。開發人員也可以設定 Application Load Balancer，以平衡每個節點上執行的可用容器的流量並公開應用程式，以便這些應用程式可在公有網路上供外界使用。完成後，想要使用應用程式的人員可以連接到應用程式端點，以進行存取。

以下各節會從 Kubernetes 叢集和工作負載的角度詳細介紹這些功能。

叢集

如果您的任務是啟動和管理 Kubernetes 叢集，則您應該知道如何建立、增強、管理和刪除 Kubernetes 叢集。您還應該知道組成叢集的元件有哪些，以及您需要做些什麼來維護這些元件。

用於管理叢集的工具可處理 Kubernetes Service 和基礎硬體提供者之間的重疊。因此，Kubernetes 提供商 (例如 Amazon EKS 或 Amazon EKS Anywhere) 通常會使用提供商專用工具來自動執行這些任務。例如，若要啟動 Amazon EKS 叢集，您可以使用 eksctl create cluster，而對於 Amazon EKS Anywhere，則可以使用 eksctl anywhere create cluster。請注意，當這些命令建立 Kubernetes 叢集時，它們專屬於提供商，而不屬於 Kubernetes 專案本身。

叢集建立和管理工具

Kubernetes 專案可提供手動建立 Kubernetes 叢集的工具。因此，如果您想要在單一機器上安裝 Kubernetes，或在機器上執行控制平面並手動新增節點，您可以使用 Kubernetes 安裝工具下所列的 CLI 工具，例如 kind、minikube 或 kubeadm。為了簡化和自動化叢集建立和管理的完整生命週期，使用受既有 Kubernetes 提供商支援的工具 (例如 Amazon EKS 或 Amazon EKS Anywhere) 要容易得多。

在 AWS 雲端中，您可以使用 CLI 工具 (例如 eksctl) 或更多宣告式工具 (例如 Terraform) 來建立 Amazon EKS 叢集 (請參閱適用於 Terraform 的 Amazon EKS 藍圖)。您還可以從 AWS 管理主控台 建立叢集。如需使用 Amazon EKS 可取得的功能的清單，請參閱 Amazon EKS 功能。Amazon EKS 為您承擔的 Kubernetes 責任包括：

若要在您自己的內部部署電腦和網路上執行叢集，Amazon 提供了 Amazon EKS Anywhere。您無需選擇 AWS 雲端作為提工資，而是可以選擇使用自己的設備，在 VMWare vSphere、裸機 (Tinkerbell 提供者)、Snow、CloudStack 或 Nutanix 平台上執行 Amazon EKS Anywhere。

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

叢集元件

Kubernetes 叢集元件可分為兩個主要領域：控制平面和工作節點。控制平面元件負責管理叢集並提供其 API 的存取。工作節點 (有時又稱為節點) 則負載提供實際工作負載執行的位置。節點元件包含在每個節點上執行的服務，以與控制平面進行通訊並執行容器。叢集的工作節點集稱為資料平面。

控制平台

控制平面包含一組管理叢集的服務。這些服務可能會全都在單部電腦上執行，也可能分散在多部電腦上。在內部，我們將其稱為控制平面執行個體 (CPI)。執行 CPI 的方式取決於叢集的大小和高可用性的需求。隨著叢集的需求增加，控制平面服務可以擴展，以提供該服務的更多執行個體，並在執行個體之間對請求執行負載平衡。

Kubernetes 控制平面的元件執行的任務包括：

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

  • 儲存有關叢集的資料 (etcd 金鑰值存放區)：etcd 服務可提供追蹤叢集目前狀態的關鍵角色。如果 etcd 服務變得無法存取，您將無法更新或查詢叢集的狀態，但工作負載會繼續執行一段時間。因此，關鍵叢集通常會一次同時執行多個負載平衡的 etcd 服務的執行個體，並在資料遺失或損毀時定期備份 etcd 金鑰值存放區。請記住，在 Amazon EKS 中，預設會自動為您處理全部任務。Amazon EKS Anywhere 提供了有關 etcd 備份和還原 的說明。請參閱 etcd 資料模型，以了解 etcd 如何管理資料。

  • 排程 Pod 到節點 (排程器)：在 Kubernetes 中啟動或停止 Pod 的請求會導向至 Kubernetes 排程器 (kube-scheduler)。由於叢集可能有多個能夠執行 Pod 的節點，因此由排程器選擇 Pod 應執行的節點 (如有複本，則為多個節點)。如果沒有足夠的可用容量來在現有節點上執行請求的 Pod，除非您已執行其他佈建，否則請求將會失敗。這些佈建可能包括啟用受管節點群組 (透過受管節點群組來簡化節點生命週期) 或 Karpenter 等服務，其中這些服務可以自動啟動新節點，進而處理工作負載。

  • 將元件保持在所需狀態 (控制器管理員)：Kubernetes 控制器管理員會以常駐程式程序 (kube-controller-manager) 執行，以觀測叢集的狀態並變更叢集，進而重新建立預期狀態。特別是，有數個控制器觀測不同的 Kubernetes 物件，其中包括 statefulset-controller、endpoint-controller、cronjob-controller、node-controller，等等。

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

工作節點 (資料平面)

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

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

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

  • 在節點上執行容器 (容器執行時期)：每個節點上的容器執行時期會管理指派給節點的每個 Pod 所請求的容器。這表示它可以從適當的登錄檔提取容器映像、執行容器、停止容器，以及回應有關容器的查詢。預設容器執行時期是 containerd。從 Kubernetes 1.24 起，可用作容器執行時期的 Docker (dockershim) 的特殊整合功能已從 Kubernetes 中刪除。雖然您仍然可以使用 Docker 在本機系統上測試和執行容器，但若要將 Docker 與 Kubernetes 搭配使用，您現在必須在每個節點上安裝 Docker 引擎，以便與 Kubernetes 搭配使用。

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

擴展叢集

有些服務可以新增至 Kubernetes 以支援叢集，但這些服務無法在控制平面中執行。這些服務通常會直接在 kube-system 命名空間或其自有命名空間的節點上執行 (如同第三方服務提供商所做的那樣)。CoreDNS 服務就是其中一個常見範例，它可為叢集提供 DNS 服務。如需如何查看叢集上的 kube-system 中正在執行哪些叢集服務的資訊，請參閱探索內建服務。

您可以考慮將不同類型的附加元件新增至叢集。為了讓您的叢集保持運作狀態良好作，您可以新增可觀測性功能 (請參閱 監控叢集效能與檢視日誌)，以便能夠執行記錄、稽核和指標等動作。利用此資訊，您通常可以透過相同的可觀測性介面對發生的問題進行故障診斷。這些類型的服務範例包括 Amazon GuardDuty、CloudWatch (請參閱 使用 Amazon CloudWatch 監測叢集資料)、AWS Ditro for OpenTelemetry、Kubernetes 專用 Amazon VPC CNI 外掛程式 (請參閱 使用 Amazon VPC CNI 將 IP 指派給 Pod) 和 Grafana Kubernetes Monitoring。對於儲存 (請參閱 針對您的叢集使用應用程式資料儲存)，Amazon EKS 的附加元件包括 Amazon Elastic Block Store CSI 驅動程式 (請參閱 透過 Amazon EBS 使用 Kubernetes 磁碟區儲存)、Amazon Elastic File System CSI 驅動程式 (請參閱 透過 Amazon EFS 使用彈性檔案系統儲存)，以及數個第三方儲存附加元件，例如 Amazon FSx for NetApp ONTAP CSI 驅動程式 搭配 FSx for NetApp ONTAP 使用高效能應用程式儲存)。

如需可用的 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 位址，提供 Pod 的存取權，而且容器可以彼此通訊，就像在自己的 localhost 上執行一樣。

Pod 規格 (PodSpec) 會定義 Pod 的所需狀態。您可以使用工作負載資源來管理 Pod 範本，以部署個別 Pod 或多個 Pod。工作負載資源包括部署 (管理多個 Pod 複本)、StatefulSets (部署需要是唯一的 Pod，例如資料庫 Pod) 和 DaemonSets (其中 Pod 需要在每個節點上持續執行)。稍後會詳細說明這些內容。

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

建置容器

Pod 實際上只是一或多個容器周圍的結構，而每個容器本身都會保存檔案系統、可執行檔、組態檔案、程式庫和其他元件，以便實際執行應用程式。由於一家名為 Docker Inc. 的公司率先推廣普及了容器，因此有人將容器稱為 Docker 容器。不過，Open Container Initiative 此後已為業界定義了容器執行時期、映像和分發方法。除此之外，容器是基於許多現有的 Linux 功能建立的，因此其他人會將容器稱為 OCI 容器、Linux 容器或簡稱為容器。

當您建置容器時，通常會以 Dockerfile (原名) 開頭。在該 Dockerfile 中，您可以識別：

  • 基礎映像：基礎容器映像就是一種容器，且其建置基礎通常是作業系統的檔案系統的最低版本 (例如 Red Hat Enterprise Linux 或 Ubuntu) 或經過增強以執行特定類型的應用程式 (例如 nodejs 或 python 應用程式) 的軟體的最小系統。

  • 應用程式軟體：您可以將應用程式軟體新增至容器，其方式與將其新增至 Linux 系統的方式大致相同。例如，在 Dockerfile 中，您可以執行 npm 和 yarn 以安裝 Java 應用程式，也可以執行 yum 和 dnf 以安裝 RPM 套件。換言之，在 Dockerfile 中使用 RUN 命令，您可以執行基礎映像的檔案系統中可用的任何命令，進而在產生的容器映像內安裝軟體或設定軟體。

  • 指示：Dockerfile 參考說明您在設定 Dockerfile 時可新增至 Dockerfile 的指示。這些包括用於建置容器本身 (本機系統中的 ADD 或 COPY 檔案) 的指示、識別容器執行時要執行的命令 (CMD 或 ENTRYPOINT)，以及將容器連接到其執行所在的系統 (透過識別要執行的 USER、要掛載的本機 VOLUME 或要 EXPOSE 的連接埠)。

雖然 docker 命令和服務歷來皆用於建置容器 (docker build)，但可用於建置容器映像的其他工具包括 Podman 和 nerdctl。請參閱建置更好的容器映像或 Docker Build 的概觀，以了解建置容器的相關資訊。

儲存容器

建置容器映像後，您可以將其儲存在工作站的容器分佈登錄檔或公有容器登錄檔。在工作站上執行私有容器登錄檔可讓您將容器映像以本機方式儲存，以便您隨時可用。

若要以更公開的方式儲存容器映像，您可以將它們推送至公有容器登錄檔。公有容器登錄檔提供集中位置，可用於儲存和分發容器映像。公有容器登錄檔的範例包括 Amazon Elastic Container Registry、Red Hat Quay 登錄檔和 Docker Hub 登錄檔。

在 Amazon Elastic Kubernetes Service (Amazon EKS) 上執行容器化工作負載時，我們建議提取儲存在 Amazon Elastic Container Registry 中的 Docker 官方映像複本。自 2021 以來，Amazon ECR 一直儲存著這些映像。您可以在 Amazon ECR 公共映像庫中搜尋熱門容器映像，特別是 Docker Hub 映像；另外，您也可以搜尋 Amazon ECR Docker Gallery。

執行容器

由於容器是以標準格式建置的，因此容器可以在可執行容器執行時期 (例如 Docker) 且其內容符合本機電腦架構 (例如 x86_64 或 arm) 的任何機器上執行。若要測試容器或在本機桌面上執行容器，您可以使用 docker run 或 podman run 命令，以在 localhost 上啟動容器。不過，對於 Kubernetes，每個工作節點都有部署的容器執行時期，並且可以由 Kubernetes 請求節點執行容器。

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

Pod

容器準備就緒後，即可處理 Pod，包括設定、部署和讓 Pod 可存取。

設定 Pod

當您定義 Pod 時，您可為其指派一組屬性。這些屬性必須至少包含 Pod 名稱和要執行的容器映像。不過，您還需要使用 Pod 定義來設定許多其他項目 (有關哪些項目可以進入 Pod 的詳細資訊，請參閱 PodSpec 頁面)。其中包含：

  • 儲存：當停止和刪除執行中的容器時，除非您設定更永久的儲存，否則該容器中的資料儲存會消失。Kubernetes 支援許多不同的儲存類型，並在磁碟區保護下對其進行抽象化。儲存類型包括 CephFS、NFS、iSCSI 等。您甚至可以從本機電腦使用本機區塊型儲存設備。透過叢集提供的其中一種儲存類型，您可以將儲存磁碟區掛載到容器的檔案系統中選取的掛載點。持久性磁碟區是在刪除 Pod 後會繼續存在的磁碟區，而暫時性磁碟區則會在刪除 Pod 時被刪除。如果您的叢集管理員為叢集建立不同的儲存類別，您可以選擇使用的儲存體屬性，例如使用後是否刪除或回收磁碟區、需要更多空間時是否會擴展，甚至是否符合特定的效能需求。

  • 秘密：透過將秘密提供給 Pod 規格中的容器，您可以提供這些容器存取檔案系統、資料庫或其他受保護資產所需的許可。金鑰、密碼和字符是可儲存為秘密的項目之一。使用秘密，您即不必將此資訊儲存在容器映像中，而只需要讓秘密可供執行中的容器使用即可。類似於秘密是 ConfigMaps。ConfigMap 往往會保留較不重要的資訊，例如用於設定服務的鍵值對。

  • 容器資源：用於進一步設定容器的物件可以採用資源組態的形式。對於每個容器，您可以請求可使用的記憶體容量和 CPU 數量，以及容器可使用的那些資源總數的限制。如需範例，請參閱 Pod 和容器的資源管理。

  • 中斷：Pod 可能會非自願中斷 (節點故障) 或自願中斷 (需要升級)。透過設定 Pod 中斷預算，您可以對應用程式在中斷發生時保持的可用性施加一些控制。如需範例，請參閱為您的應用程式指定中斷預算。

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

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

用來收集和部署 Pod 資訊的物件可由下列其中一種部署方式進行界定。

部署 Pod

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

  • 無狀態應用程式：無狀態應用程式不會儲存用戶端的工作階段資料，因此另一個工作階段不需要參考先前工作階段發生的情況。如果 Pod 運作狀態不佳或四處移動而不儲存狀態，則您可更輕鬆地將 Pod 取代為新的 Pod。如果您執行的是無狀態應用程式 (例如 Web 伺服器)，您可以使用部署來部署 Pod 和 ReplicaSets。ReplicaSet 會定義您希望同時執行的 Pod 的執行個體數量。雖然您可以直接執行 ReplicaSet，但通常會直接在部署內執行複本，以定義一次應執行的 Pod 複本數量。

  • 具狀態應用程式：在具狀態應用程式中，Pod 的身分和 Pod 啟動的順序很重要。這些應用程式需要穩定的持久性儲存，並且需要以一致方式進行部署和擴展。若要在 Kubernetes 中部署具狀態的應用程式，您可以使用 StatefulSets。資料庫就是一個典型的以 StatefulSet 執行的應用程式範例。在 StatefulSet 中，您可以定義複本、Pod 及其容器、要掛載的儲存磁碟區，以及儲存資料所在容器中的位置。如需部署為 ReplicaSet 的資料庫範例，請參閱執行複寫狀態應用程式。

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

  • 應用程式執行到完成：您想為完成特定特務而執行的一些應用程式。這可能包括執行每月狀態報告或清除舊資料。任務物件可用來設定應用程式啟動並執行，然後在任務完成時結束。CronJob 物件可讓您使用 Linux crontab 格式定義的結構，將應用程式設定為在某個特定小時、分鐘、日期、月份或星期幾執行。

讓應用程式可從網路存取

由於應用程式通常會部署為一組移動到不同位置的微服務，Kubernetes 需要一種方法來讓這些微服務能夠互相尋找。此外，若要讓其他人存取 Kubernetes 叢集以外的應用程式，Kubernetes 需要一種方式，以在外部地址和連接埠上公開該應用程式。這些聯網相關功能分別由服務和輸入物件完成：

  • 服務：由於 Pod 可以移動到不同的節點和地址，另一個需要與第一個 Pod 通訊的 Pod 可能會發現很難找到相關位置所在。為了解決此問題，Kubernetes 可讓您將應用程式表示為服務。使用服務時，您可以識別具有特定名稱的一個 Pod 或一組 Pod，然後指出哪個連接埠會公開該應用程式的 Pod 服務，以及另一個應用程式可以使用哪些連接埠來聯絡該服務。叢集中的另一個 Pod 可以直接依名稱請求服務，而 Kubernetes 會將該請求導向執行該服務的 Pod 執行個體的適當連接埠。

  • 傳入：傳入可讓 Kubernetes Service 代表的應用程式可供叢集外部的用戶端使用。傳入的基本功能包括負載平衡器 (由傳入管理)、傳入控制器以及將請求從控制器路由到服務的規則。Kubernetes 中有數個傳入控制器可供您選擇。

後續步驟

了解 Kubernetes 的基本概念及其與 Amazon EKS 的關聯性，將協助您導覽 Amazon EKS 文件和 Kubernetes 文件，進而找到管理 Amazon EKS 叢集和將工作負載部署到這些叢集所需的資訊。若要開始使用 Amazon EKS，請選擇下列選項：