Container Service for Kubernetes (ACK) は、ENI ベースのハイパフォーマンスネットワーキング向けに Terway を、よりシンプルな VPC ルーティングクラスター向けに Flannel を提供します。
Alibaba Cloud が開発した Terway は、Pod ネットワーキングに ENI を使用し、eBPF ベースのネットワークアクセラレーション、NetworkPolicy、Pod レベルの vSwitch とセキュリティグループなどの機能を提供します。ハイパフォーマンスコンピューティング (HPC)、ゲーム、マイクロサービスなど、大規模なノードスケール、高いネットワークパフォーマンス、堅牢なセキュリティを必要とするシナリオに適しています。
Flannel は、オープンソースの CNI プラグインです。ACK では、Alibaba Cloud の VPC ネットワークモードを使用し、VPC ルートテーブルを介してパケットを直接転送します。コンテナネットワークのきめ細かな制御を必要とせず、簡素化されたネットワーキングを必要とする小規模クラスターに適しています。
クラスターの作成時に CNI プラグインをインストールします。後でプラグインを変更することはできません。
Flannel を使用する場合、ALB Ingress は NodePort および LoadBalancer Service にのみリクエストを転送できます。ClusterIP Service はサポートされていません。
項目 | Terway | Flannel |
ネットワークパフォーマンス | 
説明 DataPath V2 モードでは、コンテナの conntrack データは eBPF マップに保存されます。Linux の conntrack と同様に、LRU アルゴリズムを使用し、いっぱいになると最も古いレコードを削除します。接続制限を超えないように、conntrack の設定を最適化してください。 | |
ノードクォータ | Terway クラスターの最大ノード数は、クラスターの容量制限によって決まります。
| Flannel クラスターの最大ノード数は、VPC ルートテーブルのエントリ数とクラスターの容量制限によって決まります。 VPC ルートテーブルは、デフォルトで 200 エントリ、クォータの引き上げ後は最大 1,000 エントリをサポートします。各ノードが 1 つのエントリを使用するため、Flannel クラスターは最大 1,000 ノードをサポートします。
|
ノードあたりの Pod 数 | Pod はノードの ENI を使用します。ノードあたりの最大 Pod 数は、インスタンスタイプと、ENI や [ENI あたりのプライベート IPv4 アドレス数] などのメトリックによって決まります。
たとえば、コンピューティング最適化 c7 インスタンス (ecs.c7.4xlarge、16 vCPU、32 GiB) の場合：
コンピューティング最適化 c6 と コンピューティング最適化 c7 インスタンスは ENI 数が同じですが、コンピューティング最適化 c6 インスタンスは [ENI あたりのプライベート IPv4 アドレス数] が少ないため、共有 ENI モードで実行できる Pod は最大 140 個です。詳細については、「ノードごとの Pod クォータの計算」をご参照ください。 | ノードあたりの最大 Pod 数は、ノードのポッド数 パラメーターと コンテナー CIDR ブロック のサブネットマスクによって決まります。
たとえば、ACK Pro クラスターの Pod CIDR ブロックが 172.16.0.0/20 の場合、各ノードは最大 256 個の Pod を実行でき、クラスターは最大 16 ノードをサポートします。 重要 Flannel クラスターの最大ノード数は、作成後に変更することはできません。 |
Pod CIDR ブロック |
|
|
ネットワークセキュリティ |
|
|
IPv4/IPv6 デュアルスタック | デュアルスタックネットワーキングをサポートします。 | デュアルスタックネットワーキングをサポートしていません。 説明 ACK は改変版の Flannel プラグインを使用しており、必ずしもオープンソースコミュニティと同期しているわけではありません。詳細については、「Flannel リリースノート」をご参照ください。 |
静的 Pod IP | Pod の静的 IP アドレスをサポートします。 | Pod の静的 IP アドレスをサポートしていません。 |
セッション維持 | 負荷分散バックエンドは Pod に直接接続するため、セッション維持により、バックエンドの Pod が変更された場合でもサービスの可用性が確保されます。 | 負荷分散バックエンドは、NodePort を使用して Pod に接続します。バックエンドの Pod が置き換えられるとトラフィックが中断され、サービスのリトライが発生する可能性があります。 |
マルチクラスター通信 | 必要なポートがセキュリティグループで開かれていれば、異なるクラスター内の Pod が通信できます。 | サポートされていません。 |
Pod 送信元 IP の保持 | Pod が他の VPC エンドポイントにアクセスすると、元の IP が送信元 IP として保持されるため、監査が簡素化されます。 | Pod が他の VPC エンドポイントにアクセスすると、その送信元 IP はノード IP に置き換えられます。 |
次のステップ
Pod、Service、およびノードの CIDR ブロックは、クラスター作成後に変更することはできません。これらのサイズによってリソースの上限が決まり、デプロイ可能な容量に影響します。CIDR ブロックを分離することで、ネットワークレベルでのリソース分離が可能になり、アクセス制御やカスタムルーティングに利用できます。クラスターを作成する前に、「ACK マネージドクラスターのネットワークを計画する」をご参照ください。
ネットワーク計画後：
Terway を使用するには、クラスター作成時にTerway CNI プラグインをインストールします。
Flannel を使用するには、クラスター作成時にFlannel CNI プラグインをインストールします。
関連ドキュメント
クラスターのノード制限とクォータの引き上げについては、「クォータと制限」をご参照ください。
「コンテナネットワークに関するよくある質問」をご参照ください。