選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

聯網的最佳實務 - Amazon EKS

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

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

聯網的最佳實務

了解 Kubernetes 聯網至關重要,以便有效率地操作叢集和應用程式。Pod 聯網也稱為叢集聯網,是 Kubernetes 聯網的中心。Kubernetes 支援叢集聯網的容器網路界面 (CNI) 外掛程式。

Amazon EKS 正式支援 Amazon Virtual Private Cloud (VPC) CNI 外掛程式,以實作 Kubernetes Pod 網路。VPC CNI 提供與 AWS VPC 的原生整合,並在底層模式下運作。在底層模式中,Pod 和主機位於相同的網路層,並共用網路命名空間。從叢集和 VPC 的觀點來看,Pod 的 IP 地址是一致的。

本指南介紹 Kubernetes 叢集聯網內容中的 Amazon VPC 容器網路界面 (VPC CNI)。VPC CNI 是 EKS 支援的預設聯網外掛程式,因此是指南的重點。VPC CNI 可高度設定,以支援不同的使用案例。本指南進一步包含不同 VPC CNI 使用案例、操作模式、子元件的專用區段,後面接著建議。

Amazon EKS 會執行上游 Kubernetes,並通過 Kubernetes 認證。雖然您可以使用替代 CNI 外掛程式,但本指南不提供管理替代 CNIs的建議。請查看 EKS 替代 CNI 文件以取得合作夥伴和資源清單,以有效管理替代 CNIs。

Kubernetes 網路模型

Kubernetes 會在叢集聯網上設定下列需求:

  • 在同一節點上排程的 Pod 必須能夠與其他 Pod 通訊,而無需使用 NAT (網路位址轉譯)。

  • 在特定節點上執行的所有系統協助程式 (後端程序,例如 kubelet) 都可以與在相同節點上執行的 Pod 通訊。

  • 使用主機網路的 Pod 必須能夠聯絡所有其他節點上的所有其他 Pod,而無需使用 NAT。

請參閱 Kubernetes 網路模型,了解 Kubernetes 對相容聯網實作的期望。下圖說明 Pod 網路命名空間與主機網路命名空間之間的關係。

主機網路和 2 個 Pod 網路命名空間的圖例

容器聯網界面 (CNI)

Kubernetes 支援 CNI 規格和外掛程式,以實作 Kubernetes 網路模型。CNI 包含規格 (目前版本 1.0.0) 和程式庫,用於撰寫外掛程式以在容器中設定網路介面,以及許多支援的外掛程式。CNI 只擔心容器的網路連線,並在刪除容器時移除配置的資源。

透過傳遞 kubelet --network-plugin=cni命令列選項來啟用 CNI 外掛程式。Kubelet 會從 讀取檔案 --cni-conf-dir(預設 /etc/cni/net.d),並使用該檔案中的 CNI 組態來設定每個 Pod 的網路。CNI 組態檔案必須符合 CNI 規格 (最低 v0.4.0),且組態參考的任何必要 CNI 外掛程式都必須存在於 --cni-bin-dir目錄 (預設 /opt/cni/bin)。如果目錄中有多個 CNI 組態檔案,則 kubelet 會使用依名稱以詞典順序排列的組態檔案。

Amazon Virtual Private Cloud (VPC) CNI

AWS 提供的 VPC CNI 是 EKS 叢集的預設聯網附加元件。佈建 EKS 叢集時,預設會安裝 VPC CNI 附加元件。VPC CNI 會在 Kubernetes 工作者節點上執行。VPC CNI 附加元件包含 CNI 二進位檔和 IP 地址管理 (ipamd) 外掛程式。CNI 會將 IP 地址從 VPC 網路指派給 Pod。ipamd 會管理每個 Kubernetes 節點的 AWS Elastic Networking Interfaces (ENIs),並維護 IPs的暖集區。VPC CNI 提供預先配置 ENIs和 IP 地址的組態選項,以加快 Pod 啟動時間。如需建議的外掛程式管理最佳實務,請參閱 Amazon VPC CNI

Amazon EKS 建議您在建立叢集時,在至少兩個可用區域中指定子網路。Amazon VPC CNI 會從節點子網路將 IP 地址配置給 Pod。我們強烈建議檢查子網路是否有可用的 IP 地址。部署 EKS 叢集之前,請考慮 VPC 和子網路建議。

Amazon VPC CNI 會從連接至節點主要 ENIs 的子網路配置 ENI 和次要 IP 地址的暖集區。此 VPC CNI 模式稱為次要 IP 模式。IP 地址數量和因此 Pod 數量 (Pod 密度) 是由執行個體類型定義的 ENIs 數量和每個 ENI 的 IP 地址 (限制) 所定義。次要模式是預設值,適用於執行個體類型較小的小型叢集。如果您遇到 Pod 密度挑戰,請考慮使用字首模式。您也可以透過將字首指派給 ENIs 來增加 Pod 節點上的可用 IP 地址。

Amazon VPC CNI 原生與 AWS VPC 整合,並允許使用者套用現有的 AWS VPC 網路和安全性最佳實務,以建置 Kubernetes 叢集。這包括使用 VPC 流量日誌、VPC 路由政策和安全群組進行網路流量隔離的功能。根據預設,Amazon VPC CNI 會將與節點上主要 ENI 相關聯的安全群組套用至 Pod。當您想要為 Pod 指派不同的網路規則時,請考慮啟用 Pod 的安全群組

根據預設,VPC CNI 會將 IP 地址從指派給節點主要 ENI 的子網路指派給 Pod。執行具有數千個工作負載的大型叢集時,通常會遇到 IPv4 地址不足的情況。AWS VPC 可讓您透過指派次要 CIDRs IPs,以解決 IPv4 CIDR 區塊耗盡的問題。AWS VPC CNI 可讓您為 Pod 使用不同的子網路 CIDR 範圍。VPC CNI 的此功能稱為自訂聯網。您可以考慮使用自訂聯網搭配 EKS 使用 100.64.0.0/10198.19.0.0/16 CIDR (CG-NAT)。 CIDRs 這實際上可讓您建立 Pod 不再從您的 VPC 使用任何 RFC1918 IP 地址的環境。

自訂聯網是解決 IPv4 地址耗盡問題的一種選項,但需要營運開銷。我們建議透過自訂聯網使用 IPv6 叢集來解決此問題。具體而言,如果您已完全耗盡 VPC 的所有可用 IPv4 地址空間,建議您遷移至 IPv6 叢集。評估您組織的計劃以支援 IPv6,並考慮投資 IPv6 是否有更長期的價值。

EKS 對 IPv6 的支援專注於解決有限 IPv4 地址空間引起的 IP 耗盡問題。為了回應 IPv4 耗盡的客戶問題,EKS 已將IPv6-only 的 Pod 優先於雙堆疊 Pod。也就是說,Pod 可以存取 IPv4 資源,但不會從 VPC CIDR 範圍指派 IPv4 地址。VPC CNI 會從 AWS 受管 VPC IPv6 CIDR 區塊將 IPv6 地址指派給 Pod。

子網路計算器

此專案包含子網路計算器 Excel 文件。此計算器文件會模擬不同 ENI 組態選項下指定工作負載的 IP 地址使用量,例如 WARM_IP_TARGETWARM_ENI_TARGET。文件包含兩張工作表,一張用於暖 ENI 模式,另一張用於暖 IP 模式。如需這些模式的詳細資訊,請參閱 VPC CNI 指引

輸入:

  • 子網路 CIDR 大小

  • 暖 ENI 目標暖 IP 目標

  • 執行個體清單

    • 每個執行個體排程的工作負載 Pod 類型、數量和數量

輸出:

  • 託管的 Pod 總數

  • 使用的子網路 IPs 數量

  • 剩餘的子網路 IPs 數量

  • 執行個體層級詳細資訊

    • 每個執行個體IPs/ENIs數量

    • 每個執行個體IPs/ENIs數量

隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。