Multus ワーカーノードとポッド向け自動 IP アドレス管理

テレコム 5G および IMS コンテナベースのワークロードは、Multus CNI を利用してトラフィックとルーティングの分離とパケットアクセラレーションを実現します。Multus コンテナネットワークインターフェイスプラグインを使用すると、Kubernetes ポッドを複数のインターフェイスとネットワークに接続できるようになります。Multus CNIは「メタプラグイン」であり、VPC CNI (Amazon Elastic Kubernetes Service (Amazon EKS) のデフォルト CNI)、IPVLAN CNI などの他のCNIを呼び出すことでこれを実現します。VPC CNI は Kubernetes ポッドのプライマリインターフェイスを管理しますが、IPVLAN CNI では、ワーカーノードの Elastic Network Interface (ENI) 上の同じ MAC アドレスを使用することで、ポッドがワーカーノードのセカンダリインターフェイスを使用できるようになります。Multus CNI は、host-local、static、および whereabouts などの IPAM CNI も呼び出します。

「Amazon EKS now supports Multus CNI」の記事は、Amazon EKS で Multus ワークロードをデプロイし始めるのに役立ちます。Amazon EKS に Multus ベースのワークロードをプロダクション向けにデプロイするには、次の 2 つのトピックの管理を計画する必要があります。

Multus ワーカーノードグループ: ワーカーノードサブネット、およびワーカーノードの IP アドレス管理。各ワーカーノード ENI にはサブネットの IP アドレスが必要
Multus ポッドネットワーク: ワーカーノードサブネットからの Multus ポッドの IP 管理、および Amazon Virtual Private Cloud (Amazon VPC) でのポッド通信。

この記事では、標準の Multus ノードグループのデプロイ方法と、Amazon VPC 内の Multus ワークロードで ipvlan CNI を使用する際の上記のトピックを管理するための課題とアプローチについて説明します。

標準的な Multus ノードグループ導入アプローチ

上の図は、IPVLAN CNIを使用した Multus ワークロードのデプロイ例を示しており、この記事で説明していきます。この例では、Amazon EKS クラスターと 2 つのワーカーノードを持つノードグループがあります。両方のワーカーノードは、次のように 2 つのサブネットに接続されます。

eth0 ネットワーク:10.10.12.0/24 (VPC CNI、即ちポッドのプライマリインターフェイスに使用)
eth1 ネットワーク:10.10.1.0/24 (Multus ipvlan cni、即ちポッドのセカンダリインターフェイスに使用)

上のサンプルデプロイ方法では、デプロイは Amazon EKS クラスターデプロイから始まり、その後に Amazon EKS ノードグループのデプロイが続きます。ノードグループがデプロイされたら、Multus CNI と関連するプラグインをデプロイしてワークロードをサポートできます。プラグインがデプロイされたら、ワークロードをデプロイできます。

次のセクションでは、Multus ワーカーノードグループと IP 管理のデプロイ戦略について説明します。

Multus ワーカーノードグループのデプロイと IP 管理

Multus ワーカーノードデプロイ

自己管理型の Multus ノードグループは、オートスケーリンググループを使用して復元力（最小限のワーカー数を維持）とスケーラビリティを提供します。オートスケーリンググループは、起動テンプレートを使用して Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードを構成します。オートスケーリンググループは、起動テンプレートと組み合わせて、同じサブネットに属する単一または複数のインターフェースを持つワーカーノードを作成できます。カスタムデプロイメント戦略では、カスタム AWS Lambda を使用して、異なるサブネットからの複数のネットワークインターフェイスアタッチを実現します。これにより、Amazon EC2 オートスケーリングライフサイクルフックに Multus インターフェイスが追加されます。

次の図に示すように、デプロイメントはオートスケーリンググループが起動テンプレートを使用して単一インターフェイス (eth0) のワーカーノードを作成するところから始まります。ワーカーが起動すると、カスタム Lambda が単一のインターフェイスノードを終了します。このスケールインにより、「autoscaling: EC2_INSTANCE_TERMINATING」イベントが発生し、カスタム Lambda がトリガーされてからノードをドレインします、もしくは何も行われません。

このイベントが完了すると、オートスケーリンググループは必要な容量を満たすためにスケールアウトし、「autoscaling: EC2_INSTANCE_LAUNCHING」イベントが発生します。このイベントはカスタム Lambda 関数をトリガーし、タグ (key: node.k8s.amazonaws.com/no_manage 値: true) を使用して Multus サブネットからセカンダリインターフェイスを追加します。

EKS Multus ノードグループの作成フロー

ワーカーノードの IP 管理に関する課題

オートスケーリンググループは、Amazon EKS ワーカーノードグループに弾力性と復元力を提供し、すべてのインターフェイスに DHCP IP 割り当てを使用して同じようにサポートします。一方、Multus ポッドの場合、非 VPC IPAM CNI（host-local、whereabouts 等）は、静的アドレス範囲/プールを使用してセカンダリインターフェイスでの IP 割り当てを管理します。ポッドの出力/入力は対応するワーカー ENI を介して行われるため、ポッド IP とワーカー ENI IP アドレスはサブネットから取得する必要があります。アプリケーション計画者は、Multus network-attachment-definition の構成とアノテーションによって、Multus ポッドの静的 IP 範囲を割り当てます。

同じサブネット上の 2 つの異なる別々の IP 割り当て方法 (DHCP と静的) は、ワークロードのデプロイにおいて興味深い課題となります。DHCP によるワーカーノードの IP 割り当てはランダムであり、他の静的割り当てを認識しないため、ポッドに対して計画された静的 IP 範囲から任意の IP アドレスを取得できます。Multus IPAM CNI (host-local、whereabouts 等) は、この割り当てを認識しません。この IP アドレスがワーカーインターフェイスによって取得されると、アプリケーションポッドで IP 競合が発生し、IP 割り当てが失敗し、予期しないアプリケーションのデプロイが発生してしまいます。

ソリューション

以下のセクションでは、ワーカーノードと Multus ワークロードの IP アドレスを競合しない方法でより適切に管理するための 2 つの方法を紹介します。

アプローチ 1: カスタム Lambda を使用してワーカー IP を静的に割り当てる

このソリューションアプローチは、ワーカーとポッド間の論理サブネット共有モデルで機能します。このアプローチでは、ワーカーノードはサブネットの最初から未割り当ての IP を取得し、Multusポッドはサブネットの終わりから未割り当ての IP を取得します。この割り当て戦略では、IP アドレスはワーカーノードインターフェイスにランダムに割り当てられるのではなく、IP 割り当てはサブネットで最初に空いている空き IP から静的に行われます。

詳細な説明、サンプル AWS CloudFormation テンプレート、サポートされている Lambda 関数については、GitHub リポジトリ「Allocate Worker IPs statically via a custom lambda-based solution」を参照してください。

アプローチ 2: ポッドの IP アドレスに VPC サブネット CIDR 予約 (静的) を使用する

このアプローチでは、VPC サブネット CIDR 予約戦略を使用して、ワーカーノードと Multus ポッドの IP アドレス割り当てを分離します。このアプローチでは、Multus ポッドの IP CIDR 範囲を静的として明示的に予約でき、Amazon EC2 ワーカーノードの DHCP がこのブロックからワーカーノードに IP アドレスを割り当てないようにすることができます。

これを実現する為に、明示的 (静的) 割り当てのみを目的として、ポッド IP アドレスの塊に対して 1 つ以上のサブネット CIDR 予約を作成できます。サブネット CIDR の予約されていない塊は、オートスケーリンググループの背後にあるワーカーノードへの DHCP（デフォルト）割り当てに使用できます。

詳細な説明、サンプルの CloudFormation テンプレート、およびサポートされている Lambda 関数については、GitHub リポジトリ「Use VPC subnet cidr reservation (static) for pods IP addresses」を参照してください。

自動 Multus ポッドネットワーキング

Amazon EKS クラスターと Multus ノードグループが前述のアプローチのいずれかでデプロイされたので、Multus を使用して Amazon EKS にワークロードをデプロイできます。次のステップとして、git リポジトリに記載されているように Multus CNI をデプロイし、whereabouts IPAM CNI をインストールします。この記事では、whereabouts IPAM CNI を使用してクラスターの一意の Multus IP アドレスを管理しています。

ここで、VPC での IP 通信の仕組み、ルーティングを有効にする方法、および自動化された方法で Multus ポッドに IP を割り当てる方法を理解しましょう。

Multus ポッドのIP 管理とルーティングの課題

次の例では、Multus ポッドをデプロイすると、セキュリティグループルール/NACL がトラフィックをブロックしていない場合でも、異なるワーカー上のポッド間通信が機能しないことに留意してください。ただし、同じワーカーノード上のポッド間の相互通信は正常に機能します。

ここでは、この動作について詳しく説明します。Amazon VPC クラウドは、ワークロードにレイヤー 3 ネットワーキングを提供します。ENI は、1 つ以上の IP アドレスと対応する MAC アドレスを含む論理ネットワークエンティティです。Amazon VPC は、ENI に割り当てられた IP アドレスに基づいて、トラフィックを正しい宛先にルーティングします。Amazon EC2 ワーカーノードに接続されている各 ENI には、適格な IP アドレスが割り当てられている必要があります。

ポッドのプライマリインターフェイスでは、Amazon VPC CNI は DHCP を使用してプライマリポッド IP アドレス (上の図では 10.10.12.x) をポッド eth0 (VPC CNI マネージドインターフェイス) に割り当て、これらの IP をワーカーノード ENI のセカンダリ IP として割り当てます。非 VPC IPAM CNI (whereabouts、host-local、static 等) は、IP アドレスを Multus ポッドに割り当てます。したがって、Amazon VPC はこの IP アドレスの割り当てを認識しません。さらに、これらの IP アドレスは、それぞれのワーカーノード ENI (上の図では eth1) のセカンダリ IP として割り当てられません。

Amazon EC2 コンソールでワーカーノードの ENI を調べることで同じことを確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。

この問題は、ポッドが想定する IP アドレスがそれぞれのワーカー ENI に割り当てられると解決されます。これらの IP がそれぞれの ENI (例: eth1) に割り当てられると、Amazon VPC は割り当てられた IP のマッピングを ENI へ更新し、指定された Multus IP アドレスにトラフィックをルーティングします。

次の例では、Multus ポッド IP アドレス 10.10.1.80 および 10.10.1.82 が、最初のワーカーノードの eth1 ENI 上のセカンダリ IP アドレスとして割り当てられます。同様に、10.10.1.81 セカンダリ IP が 2 番目のワーカーノード eth1 ENI に割り当てられます。

自動化ソリューション

Amazon EC2 の IP アドレスの割り当て/IP アドレスの割り当て解除 API 呼び出しにより、ワーカーノード ENI での IP 割り当てを自動化できます。git リポジトリにあるサンプル Python コードとスクリプトでも同じ結果が得られます。

以下で説明する自動化アプローチでは、アプリケーションイメージやソースコードを変更する必要はありません。これらのポッドでカスタムの「IP 管理」コンテナを利用して、アプリケーションコンテナやそのアーキテクチャに影響を与えることなく、それぞれのワーカーノード ENI で IP 割り当ての自動化を実行できます。この追加のコンテナを使用して、ワークロードの pod/deployment/statefulset の仕様を強化できます。

この機能を提供し、次のいずれかのソリューションオプションで使用できる Docker コンテナイメージをビルドするには、「How to build」を参照してください。

アプローチ1: InitContainer ベースのIP 管理ソリューション

このソリューションは、フローティング IP (次のアプローチで説明) などの特別な処理やカスタム処理を行わなくても、ほとんどの ipvlan CNI ポッドで機能します。このアプローチでは、ワーカーに追加の CPU/メモリ要件の制約が追加されません。

この「IP 管理」コンテナは、ポッドが init 状態のときに最初のコンテナとして実行されます。このコンテナは、ポッドが初期 (init) 状態にあるときに、ポッドの IP アドレスを確認し、その IP アドレスを ENI に割り当てます。Multus IP アドレスがワーカーノード ENI に正常に割り当てられると、この initContainer は終了し、ポッドは初期状態から抜け出します。

このソリューションを使用するには、InitContainer IP management ドキュメントとデプロイ手順を参照してください。 Amazon EC2 コンソールでワーカーノードの ENI を調べることで、同じことを確認できます。Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。

アプローチ 2: サイドカー IP 管理ソリューション

このアプローチでは、「IP管理」コンテナはサイドカーコンテナとして動作します。さらに、initContainer とは異なり、Multus インターフェイス上のポッド IP アドレスを常に監視して、新規または変更された IP アドレスがないかどうかを確認します。これは、アクティブ/スタンバイポッドに対するカスタムの「フローティング IP」処理を持つポッドにとって役立ち、内部ロジックに基づいて、トラフィックを中断することなく「フローティング IP」がスタンバイポッドにフェイルオーバーします。この場合、サイドカーは IP アドレスの変更についてポッドを常に監視するため、Multus ベースのポッドごとにこのコンテナ用の CPU/メモリ (最小限) が追加で使用されます。

このソリューションを使用するには、Sidecar IP management Solution のドキュメントと手順を参照してください。 Amazon EC2 コンソールで確認できます: Amazon EC2 コンソール → インスタンス → インスタンスの選択 (ワーカー) → アクション → ネットワーキング → IP アドレスの管理。

クリーンアップ

この記事でデプロイされたサンプル Multus ワークロードをクリーンアップするには、GitHub リポジトリの「Cleanup」を参照してください。さらに、今後の料金の発生を避けるために、CloudFormation コンソールから Multus Worker ノードグループを削除してください。Amazon EKS クラスターは Amazon EKS コンソールから削除できます。

まとめ

この記事では、Amazon VPC クラウド内のワーカーノードと Multus ポッドの IP アドレスの IP 割り当て、管理、分離の際にお客様が直面する課題について説明しました。さらに、Multus ポッドがどのように Amazon EKS および Amazon VPC スコープで動作し、VPC内でトラフィックをルーティングするかについても説明しました。

加えてこの記事では、ソフトウェア/イメージを変更することなく、Amazon EKS ノードグループと Multus ポッドの IP 管理自動化の、自動化サンプルメソッドも提供しております。

分かり易くするために、この記事の上の例では IPv4 の処理のみを説明しました。但し、git リポジトリのサンプルコードは IPv6 もサポートしています。様々なアプリケーションアーキテクチャやユースケースに応じて、git リポジトリ内のサンプルソースコードをさらに調整して頂けます。

この記事はアマゾンウェブサービスジャパンの黒田由民が翻訳を担当しました。 (原文はこちら)

Amazon Web Services ブログ