※ 本記事は、Ajay Chhabriaによる”Introducing Oracle Kubernetes VCN CNI 2.0.0“を翻訳したものです。

2023年5月9日

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のリリース・ノートを参照してください。

このブログでは、OCI VCN CNI 2.0.0で、VCN IPアドレス、ポッドが同じワーカー・ノードにデプロイされているかどうか、クラスタ内のワーカー・ノード間、またはCalicoやサービス・メッシュなどのネットワーク・ポリシー・プラグインを使用したポッド間通信がどのように可能になっているかについて学習します。

CNIフローの理解

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

ポッド間、同じワーカー・ノード

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

A graphic depicting the architecture for a pod-to-pod, same worker node setup.

ワーカー・ノード全体でのポッド間

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

A graphic depicting the architecture for a pod to pod across worker nodes setup.

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

ポッドからサービスまでのネットワーク

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

A graphic depicting the architecture for a pod to service setup.

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

ネットワーク・ポリシーの強制

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

A graphic depicting the architecture for network policy setup.

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

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

サービス・メッシュ

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

A graphic depicting the architecture for a service mesh setup.

サービス・メッシュおよびIstioモデルでは、各ポッドに独自のファイアウォール・ルール(iptables)とネットワーク・デバイス(vethペアおよびサイドカー・コンテナ)があります。このシナリオでは、ポッド1はポッド2と通信し、両方のポッドは同じワーカー・ノード上にあります。ポッド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に転送されます。最終的に、パケットはサイドカーに転送され、最後にアプリケーションに転送されます。

次のステップ

このブログでは、eastからwestへのVCN CNIトラフィック・フローの詳細について説明しました。ロード・バランサを使用してトラフィックがnorthからsouthへどのように流れるかを理解するには、Kubernetesサービス用のネットワーク・ロード・バランサの使用を参照してください。OCI VCN CNIのポッド・ネットワーキングの詳細は、OCI VCN CNIのドキュメントを参照してください。

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