Oracle Kubernetes VCN CNI 2.0.0の紹介 (2023/04/27)

https://blogs.oracle.com/cloud-infrastructure/post/introducing-oracle-kubernetes-vcn-cni-200

投稿者：Ajay Chhabria | Principal Solutions Architect

Oracle Container Engine for Kubernetes (OKE) は、独自の Kubernetes コントロールプレーンまたはノードをインストール、操作、およびメンテナンスする必要なく、Oracle Cloud Infrastructure (OCI) 上で Kubernetes を実行するマネージドサービスです。OKE は、最初のリリースでネイティブの仮想クラウドネットワーク (VCN) をサポートします。このコンテナ・ネットワーク・インターフェース (CNI) プラグインは、VCN から各ポッドにプライベート IPv4 アドレスを割り当てます。VCN CNI により、Kubernetes ポッドはOCI ネットワークパフォーマンスと他の OCI サービスとの統合を利用できます。

本日、Oracle Kubernetes Engine のネットワーク実装のメジャーアップデートである OCI VCN CNI 2.0.0 を紹介できることを嬉しく思います。OCI VCN CNI によって実装されたネットワーキングが大幅に強化されました。この機能強化により、次の利点が得られます。

• OCI Service Mesh、Istio、Linkerd などのサービスメッシュ製品は、ポッドネットワーキングに OCI VCN ネイティブ ポッドネットワーキング CNI プラグインを使用する場合にサポートされます。
• ネットワークパフォーマンスの向上

OCI VCN CNI の新しいネットワーク拡張機能は、Kubernetes バージョン 1.26 以降で使用できます。VCN 2.0.0の利点を得るには、Kubernetesコントロールプレーンとワーカーノードの両方が1.26以上である必要があります。詳細については、OCI VCN CNI 2.0.0リリース ノートを参照してください。

このブログでは、ポッドが同じワーカーノードにデプロイされているか、クラスター内の複数のワーカーノードにデプロイされているか、Calico、サービスメッシュなどのネットワークポリシープラグインを使用してデプロイされているかに関係なく、OCI VCN CNI 2.0.0 が VCN IP アドレスを使用してポッド間通信を可能にする方法を説明します。

CNI フローを理解

ポッドの観点からは、同じノード上の他のネットワーク名前空間と通信する必要がある独自のネットワーク名前空間に存在します。Linux仮想イーサネット デバイスまたは veth ペアを使用して名前空間を接続できます。これは、複数の名前空間に分散できる 2 つの仮想インターフェイスで構成されます。新しい CNI は、一方の端がポッドの名前空間にあり、もう一方がホストの名前空間にある veth ペア デバイスのみを作成します。すべての通信 (Pod からホストへ、Pod から Pod へ、Pod から外部サービスへ) トラフィックは、この veth デバイスを介してホスト名前空間に流れ、そこで宛先に向けて適切にルーティングされます。各 veth ペアはパッチ ケーブルのように機能し、2 つの側を接続してトラフィックがそれらの間を流れるようにします。

同じワーカーノードのポッド間

各ポッドを独自のネットワークスタックに分離するネットワーク名前空間、各名前空間をホスト名前空間に接続する仮想イーサネット デバイス、および名前空間を相互に接続するホスト名前空間のルーティングルールがあれば、ポッドは同じワーカーノード内で相互にトラフィックを送信できます。すべてのポッドには、仮想イーサネット デバイスまたは veth ペアと、それに関連付けられたルート ルールがあります。VCN は、このフロー中にトラフィックを確認しませんでした。

別のワーカーノードのポッド間

クラスター内のすべてのワーカーノードには、ユーザーが選択したポッドサブネットからランダムなセカンダリ IP アドレスが割り当てられます。これらのセカンダリ IP アドレスは、そのノードで実行されているポッドで使用できます。IP アドレス宛てのトラフィックがノードに到達すると、ノードはトラフィックを正しい Pod に転送します。宛先ポッド (10.20.50.154) は、ソースポッド (10.20.50.60) とは異なるノードにあります。パケットは、ホスト名前空間の仮想イーサネット デバイスとペアになっているポッド 1 の仮想イーサネット デバイスを介して送信されることから始まります。最終的に、パケットはホスト名前空間のルーティング テーブルに到達します。ワーカーノードのローカルルーティングは、パケットをセカンダリー仮想ネットワーク・インターフェース・カード (VNIC) である ens5 に転送します。

これで、ルートはソースワーカーノードを離れ、VCN に入ります。VCN は、ワーカーノードに割り当てられたセカンダリ IP アドレスに基づいて、パケットを正しいワーカーノードにルーティングします。パケットは宛先ワーカーノードのホスト名前空間に入り、そこでルートルールを介してルーティングされ、正しい仮想イーサネットデバイス (veth-host-4) が決定されます。最後に、ポッド 4 の名前空間内に存在する仮想イーサネット デバイスのペアを通過することで、ルートが完了します。各ワーカーノードは、その中で実行されているポッドにパケットを配信する方法を認識しています。パケットが送信先のワーカー ノードに到達すると、同じノード上のポッド間でトラフィックをルーティングする場合と同じ方法でパケットが流れます。

ポッドからサービスへのネットワーキング

新しい Kubernetes サービスを作成すると、クラスター IP とも呼ばれる新しい仮想 IP が作成されます。クラスター内のどこでも、仮想 IP 宛てのトラフィックは、サービスに関連付けられた一連のバッキングポッドに負荷分散されます。実際、Kubernetes は、サービスに関連付けられた正常なポッドにトラフィックを分散する分散クラスター内ロードバランサーを自動的に作成および維持します。

パケットはまず、ポッドのネットワーク名前空間に接続された veth インターフェイスを介してポッドを離れます。次に、ホストの仮想イーサネットデバイスを通過します。ここで、何か違うことが起こります。ルートルールで受け入れられる前に、パケットは iptables でフィルタリングされます。パケットを受信した後、iptables は、サービスまたはポッド イベントに応答して kube-proxy によってノードにインストールされたルールを使用して、パケットの宛先をサービス IP から特定のポッド IP に書き換えます。iptables は、Linux カーネルの conntrack ユーティリティを使用してポッドの選択を記憶し、将来のトラフィックが同じポッドにルーティングされるようにします。次に、パケットはホストルートテーブルに移動します。この例では、パケットはサービスの仮想 IP ではなく、ポッド 2 に到達するようになっています。その後、トラフィックは、前のセクションで既に説明したポッド間ルーティングを使用してポッドに流れます。宛先ポッドがローカルワーカーノードの外部に存在する場合、ポッドからポッドへのセクションで説明されているように、ワーカー ノード間でトラフィックをリダイレクトします。

ネットワーク ポリシーの適用

Calicoのようなネットワークポリシープラグインは、Pod を保護するための統一された構文を備えた豊富なネットワークポリシーのセットを提供します。Calico はポリシーに iptables を使用し、特定のポッドの仮想イーサネットインターフェイス上の各ポッドに適用されるポリシーを適用します。iptables ルールは、ワーカーノードのファイアウォールとして機能し、ネットワークトラフィックが宛先ポッドに転送されるために満たす必要がある特性を定義します。

この例では、同じ色のポッドのみが相互に通信できるネットワークポリシーを使用しています。Calico を実行する Kubernetes ワーカーノードでは、veth がワークロード (Pod) にマップされます。すべてのワークロードに対して、Calico は iptables を使用して、ネットワーク処理パス内のさまざまなチェーンにフックを作成します。Calico は、その特定のポッドの仮想イーサネットインターフェイス上の各ポッドにそれを適用し、それらを監視します。トラフィックは仮想インターフェイス経由で到着するため、iptables を通過します。パケットがネットワークインターフェイスを介して着信すると、標準の iptables チェーンを通過します。ルーティングの決定が行われ、それに基づいて、パケットはホストプロセスに送信されるか、ポッドまたはネットワーク内の別のノードに送信されます。ポリシーが適用されていない場合、宛先ワーカー ノードに入るパケットは、妨げられることなくワークロードに配信され、同じ方法で返されます。

ここで、Pod 4 がクラスター外のノードからアクセスされないように保護するポリシーが追加されたとします。これには、クラスター内の任意のワーカーノードからポッド 4 へのアクセスをブロックする必要があります。これらのポリシーは、パケットのドロップと拒否を担当する iptables 内のフィルター テーブルによって適用されます。ポリシーが適用されたトラフィック フロー全体を調べると、iptables とルーティングの決定をトラバースしているときに、フィルターチェーンで適用される Calico ポリシーによってトラフィックがドロップされます。さまざまなポリシーが適用された場合のトラフィックフローの詳細については、「Calico でのポリシー適用オプションについて」を参照してください。

サービスメッシュ

最も一般的なサービスメッシュの実装は、サイドカーモデルを使用する Kubernetes コンテナオーケストレーション プラットフォームを使用するものです。サービスメッシュは、ネットワーク機能をレイヤー 4 サイドカー プロキシに実装し、このサイドカープロキシにリダイレクトされるサービスとの間のトラフィックに依存します。アプリケーションコンテナは、同じポッド内のプロキシサイドカーコンテナの隣にあります。これらは同じポッド内にあるため、同じネットワーク名前空間と IP アドレスを共有し、コンテナーが localhost を介して通信できるようにします。

サービスメッシュと Istio モデルでは、各ポッドに独自のファイアウォールルール (iptables) とネットワークデバイス (veth ペアとサイドカー コンテナー) があります。このシナリオでは、ポッド 1 がポッド 2 と通信する必要があり、両方のポッドが同じワーカーノード上にあります。Pod 1 は、デフォルトのイーサネット デバイスである veth-pod にパケットを送信します。ポッド 1 のネットワーク名前空間の iptables ルールは、パケットをサイドカーにリダイレクトします。パケットの処理後、サイドカーは元の宛先 IP アドレスとポートを回復し、パケットを veth-pod に転送します。ポッド 1 の場合、veth-pod は veth-host-1 を使用してホスト ネットワーク名前空間に接続します。ルート ルールは、veth-host-1 をノード上の他のすべての仮想デバイスに接続します。パケットがルート ルールに到達すると、ポッド 2 に到達するための正しいネクスト ホップが veth-host-2 であることが決定されます。パケットが仮想デバイス veth-host-2 に到達すると、ポッド 2 のネットワーク名前空間の veth-pod に転送されます。最終的に、パケットはサイドカーに転送され、最後にアプリケーションに転送されます。

次のステップ

このブログでは、東から西へ向かう VCN CNI トラフィックフローについて詳しく説明しました。ロードバランサーを使用してトラフィックが北から南へ流れる方法を理解するには、「Kubernetes サービスにネットワーク ロード バランサーを使用」を参照してください。OCI VCN CNI でのポッド ネットワークの詳細については、OCI VCN CNI のドキュメント を参照してください。

Oracle Cloud Infrastructure サポート ポータルで問題を作成し、このプラグインの改善にご協力ください。