選擇網路模式- Amazon ECS

當您 host 網路模式時，容器會使用基礎主機Amazon EC2 執行個體的IP 位址在連接埠3000 上接收流量。

我們不建議使用此模式。

使用此網路模式有顯著的缺點。

您不能在每台主機 ... 選擇網路模式-AmazonElasticContainerServiceAWS文件AmazonECS最佳實務指南主機模式橋接模式AWVPC模式本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

選擇網路模式先前提到的架構輸入和輸出網路連線的方法，可套用至AWS，即使它們不在容器內。

執行容器時，在AWS，您需要考慮另一層級的網絡。

使用容器的主要優點之一是您可以將多個容器封裝到單一主機上。

執行這項操作時，您需要選擇要如何將相同主機上執行的容器進行網路連線。

以下是可供選擇的選項。

主題主機模式橋接模式AWVPC模式 主機模式 所以此host網路模式是AmazonECS支援的最基本網路模式。

使用主機模式，容器的網絡直接綁定到正在運行容器的基礎主機。

假設您正在執行Node.js容器與快速應用程式偵聽連接埠3000類似於前面的圖表所示。

當您host網路模式時，容器會使用基礎主機AmazonEC2執行個體的IP位址在連接埠3000上接收流量。

我們不建議使用此模式。

使用此網路模式有顯著的缺點。

您不能在每台主機上執行任務的多個實例化。

這是因為只有第一個任務可以綁定到AmazonEC2執行個體上的所需端口。

當容器端口使用host網路模式。

例如，如果應用程式需要偵聽特定的連接埠號碼，則無法直接重新對應連接埠號碼。

相反地，您必須透過變更應用程式組態來管理任何連接埠衝突。

在使用host網路模式。

此模式允許容器模擬主機，並允許容器連線到主機上的私人迴路網路服務。

所以此host網路模式僅支援在AmazonEC2執行個體上託管的AmazonECS任務。

在Fargate上使用亞馬遜ECS時不受支援。

橋接模式 搭配bridge模式中，您正在使用虛擬網絡橋接器在主機和容器的網絡之間創建一個層。

如此一來，您就可以建立連接埠對應，將主機連接埠重新對應至容器連接埠。

對映可以是靜態或動態。

使用靜態連接埠對應，您可以明確定義要對應至容器連接埠的主機連接埠。

使用上述範例，連接埠80正在映射到端口3000(位於容器)。

若要與容器化應用程式進行通訊，您可以將流量傳送至連接埠80到AmazonEC2執行個體的IP地址。

從容器化應用程序的角度來看，它可以看到端口3000。

如果您只想變更流量連接埠，則適合靜態連接埠對應。

但是，這仍然具有與使用host網路模式。

您不能在每台主機上執行任務的多個實例化。

這是因為靜態連接埠對應只允許單一容器對應至連接埠80。

若要解決此問題，請考慮使用bridge網路模式與動態連接埠對應，如下圖所示。

藉由不在連接埠對應中指定主機連接埠，您可以讓Docker從暫時連接埠範圍中選擇一個隨機、未使用的連接埠，並將其指派為容器的公用主機連接埠。

例如，Node.js應用程式偵聽連接埠3000可能會被分配一個隨機的高數字端口，例如47760(位於AmazonEC2主機)。

這樣做意味著您可以在主機上運行該容器的多個副本。

此外，每個容器都可以在主機上分配自己的端口。

容器的每個副本都會在連接埠上接收流量3000。

不過，傳送流量至這些容器的用戶端會使用隨機指派的主機連接埠。

AmazonECS可協助您持續追蹤每個任務的隨機指派連接埠。

它會自動更新負載平衡器目標群組並AWSCloudMap服務探索，以取得工作IP位址和連接埠的清單。

這可讓您更輕鬆使用使用bridge模式與動態連接埠。

但是，使用bridge網路模式是很難將服務鎖定至服務通訊。

由於服務可能會指派給任何隨機、未使用的連接埠，因此必須在主機之間開啟廣泛的連接埠範圍。

不過，建立特定規則並不容易，讓特定服務只能與其他特定服務通訊。

服務沒有特定的連接埠可用於安全性群組網路規則。

所以此bridge網路模式僅支援在AmazonEC2執行個體上託管的AmazonECS任務。

在Fargate上使用亞馬遜ECS時不支援此功能。

AWVPC模式 使用awsvpc網路模式時，AmazonECS會為每個任務建立和管理彈性網路界面(ENI)，並且每個任務會在VPC內接收自己的私有IP地址。

此ENI是從底層主機ENI分開。

如果AmazonEC2執行個體正在執行多個任務，則每個任務的ENI也是獨立的。

在上述範例中，AmazonEC2執行個體會指派給ENI。

ENI代表用於主機層級網路通訊之EC2執行個體的IP地址。

每個任務也有一個對應的ENI和一個私人IP地址。

因為每個ENI都是獨立的，所以每個容器都可以綁定到端口80在任務ENI。

因此，您不必跟蹤端口號碼。

相反，您可以將流量發送到端口80在任務ENI的IP地址。

使用awsvpc網路模式的重要原因是每個工作都有個別的安全性群組來允許或拒絕流量。

這表示您有更大的彈性，以更精細的層級控制工作與服務之間的通訊。

您也可以將工作設定為拒絕來自同一主機上其他工作的傳入流量。

所以此awsvpc網路模式支援在AmazonEC2和Fargate上託管的AmazonECS任務。

請注意，在使用Fargate時，awsvpc網路模式是必要的。

當您使用awsvpc網路模式中，您應該注意幾個挑戰。

使用ENI中繼增加任務密度 最大的缺點是使用awsvpc網路模式與AmazonEC2執行個體上託管的任務是EC2執行個體對可以連接到它們的ENI數量有限。

這會限制您可以在每個執行個體上放置多少工作。

AmazonECS提供ENI中繼功能，可增加可用ENI的數量，以達到更高的任務密度。

使用ENI主幹時，預設會使用兩個ENI附件。

第一個是執行個體的主要ENI，用於任何主機層級處理程序。

第二個是主幹ENI，亞馬遜ECS創建。

只有特定AmazonEC2執行個體類型才支援此功能。

考慮這個範例。

如果沒有ENI主幹，c5.large執行個vCPUs只能裝載兩個工作。

但是，使用ENI中繼，c5.large執行個體最多可以裝載十個工作。

每個工作都有不同的IP位址和安全性群組。

如需可用執行個體類型及其密度的詳細資訊，請參閱支援的AmazonEC2執行個體類型中的AmazonElasticContainerServiceContainerService。

ENI中繼在延遲或頻寬方面對運行時性能沒有影響。

不過，它會增加工作啟動時間。

您應該確保如果使用ENI主幹，則依賴於任務啟動時間的自動調整規則和其他工作負載仍然如預期般運作。

如需詳細資訊，請參閱「」彈性網路界面中繼中的AmazonElasticContainerServiceContainerService。

防止IP地址耗盡 透過為每項工作指派不同的IP位址，您可以簡化整體基礎結構，並維護提供絕佳安全性層級的安全性群組。

不過，此組態可能會導致IP耗盡。

您AWS帳戶已預先佈建子網路，該子網路具有/20CIDR範圍。

這表示每個子網路都有4,091個可用的IP位址。

請注意，數個IP位址/20範圍已留給AWS特定用途。

考慮這個範例。

您可以將您的應用程式分佈到三個可用區域中的三個子網路以提供高可用性。

在這種情況下，您可以在三個子網路中使用大約12,000個IP位址。

使用ENI中繼，您啟動的每個AmazonEC2執行個體都需要兩個IP地址。

一個IP位址用於主要ENI，而另一個IP位址用於主幹ENI。

執行個體上的每個AmazonECS任務都需要一個IP地址。

如果您正在啟動極大的工作負載，可能會用盡可用的IP位址。

這可能會導致AmazonEC2啟動失敗或任務啟動失敗。

發生這些錯誤是因為如果沒有可用的IP位址，ENIS無法在VPC內新增IP位址。

當您使用awsvpc網路模式，您應該評估您的IP位址需求，並確保您的子網路CIDR範圍符合您的需求。

如果您已經開始使用具有小子網路的VPC，且位址空間不足，則可以新增次要子網路。

透過使用ENI主幹，AmazonVPCCNI可以配置為在與主機不同的IP位址空間中使用ENI。

通過這樣做，您可以為AmazonEC2主機和任務提供不重疊的不同IP地址範圍。

在範例圖中，EC2主機IP位址位於具有172.31.16.0/20IP範圍。

不過，在主機上執行的工作會在100.64.0.0/19範圍。

透過使用兩個獨立的IP範圍，您不必擔心工作耗用太多IP位址，也不會為執行個體留下足夠的IP位址。

使用IPv6雙堆疊模式 所以此awsvpc網路模式與設定為IPv6雙堆疊模式的VPC相容。

使用雙堆疊模式的VPC可透過IPv4、IPv6或兩者進行通訊。

VPC中的每個子網路可以同時具有IPv4CIDR範圍和IPv6CIDR範圍。

如需詳細資訊，請參閱「」您VPC中的IP定址中的AmazonVPC使用者指南。

您無法停用VPC和子網路的IPv4支援來解決IPv4耗盡問題。

不過，有了IPv6支援，您可以使用某些新功能，尤其是僅限輸出網際網路閘道。

僅限輸出網際網路閘道允許任務使用其公有路由至網際網路的輸出連線。

但僅輸出網際網路閘道不允許從網際網路連線。

如需詳細資訊，請參閱「」輸出限定網際網路閘道中的AmazonVPC使用者指南。

文件慣用形式從網際網路接收傳入的連線連接到AWS服務此頁面是否有幫助？-是感謝您，讓我們知道我們做得很好！若您有空，歡迎您告知我們值得讚許的地方，這樣才能保持良好服務。

此頁面是否有幫助？-否感謝讓我們知道此頁面仍須改善。

很抱歉，讓您失望。

若您有空，歡迎您提供改善文件的方式。