※本ページはAnnouncing VCN-native pod networking for Kubernetes in OCIの翻訳です

Oracle Container Engine for Kubernetes（OKE）では、現在、デフォルトのコンテナ・ネットワークインターフェイス（CNI）としてFlannelを使用してクラスタを作成できます。 Flannelは、IPアドレスをコンテナに接続し、仮想拡張LAN（VXLAN）を使用してネットワーク接続を容易にすることで、Kubernetesネットワークモデルの要件を満たすシンプルなオーバーレイ仮想ネットワークです。

本日、Kubernetes podを仮想クラウドネットワーク（VCN）の一部としてネイティブに使用できることをお知らせします。これにより、OKE CNIでVCN-native pod ネットワークが一般提供されます。 VCNは、カスタマイズ可能なSoftware defined networkであり、仮想テスト・アクセスポイント（VTAP）やフローログなどの豊富な機能セットを使用して、OCIでインフラストラクチャを管理および拡張できます。 Kubernetes podは、柔軟性、きめ細かいセキュリティ、一貫したパフォーマンスの恩恵を受けることができます。これは、現在提供しているFlannelオーバーレイ・ネットワーク・オプションを補完するものであり、顧客はpodネットワークを計画するためのより多くの選択肢を持つことができます。

OKE用のOCI VCNネイティブのCNIの導入

VCN ネットワーキングは、OKEによって管理されるKubernetesクラスタ用の新しいCNIプラグインを提供します。このCNIは、podにVCN CIDRからのIPアドレスを提供します。その結果、追加のオーバーレイを必要とせずに、仮想マシンと同じネットワーク・パフォーマンスが得られます。podは、VCN内、VCN間、およびFastConnectまたはIPSec VPNを介したオンプレミス・ネットワークでルーティング可能です。podのIPは、podに出入りするネットワーク・トラフィックを識別でき、VCNフローログを使用して、VCNを通過するpodのネットワーク・トラフィックを監査できます。

Kubernetesサービスを介してKubernetesクラスタ内のアプリケーションにアクセスすることをお勧めしますが、IPを使用してポッドにアクセスする機能により、さまざまなユースケースを実現できます。例えば、インターネットへのアウトバウンドアクセスを行うOracle Kubernetesクラスタでサービスが公開されている場合、管理者はpodレベルまでパケットをエンド・ツー・エンドで可視化する必要があります。これらのシナリオでは、Kubernetes用のVCN native podプラグインは、podのIPv4アドレスをpodが実行されているノードのIPv4アドレスに変換せずに、podのIPv4アドレスを保持し、podネットワーク・トラフィックの詳細をVCNフローログなどのアプリケーションに記録できます。

クラスタでVCN-native pod networkingを有効にすると、OKEはクラスタにVCN-native pod networking CNIを自動的に展開、構成、および維持します。 CNIは、スケジューリングの待ち時間を短縮するためにOKEノードにIPアドレスを事前に割り当てることにより、IPアドレスの「ウォームプール」を作成します。ワーカーノードにはすでにIPアドレスが割り当てられているため、Kubernetesはpodをスケジュールする前にIPアドレスが割り当てられるのを待つ必要はありません。

VCN-native pod networkingは、podに高スループット、低遅延、およびパフォーマンスの一貫性を提供します。パフォーマンステストでは、OCI VCN-native pod networkingが、異なるノード間のpod間通信でFlannelよりも25％低い遅延を提供することを示しています。ビデオ会議、Internet of Thingsベースのスマートホームアプリ、オンラインゲームなどのリアルタイム・アプリケーションには、pod間のネットワーク伝送時間が短く、一貫していることが不可欠です。 OCI VCN-native pod networkingを使用すると、podはオーバーヘッドなしでOCIネットワーキングの速度で通信します。

VCN-native pod networkingを使用すると、すべてのクラスタ・コンポーネント（APIサーバ、ワーカーノード、ロードバランサ、および現在はpod）に対して単一のサブネットを構成できます。ただし、ベストプラクティスでは、すべてのコンポーネントを異なるサブネットに保持します。 VCN-native pod networkingによってより安全になるもう1つの一般的な方法は、本番クラスタや非本番クラスタなどの複数のKubernetesクラスタ間で同じネットワーク（VCN、またはサブネット）を共有することです。

ネットワーク・セキュリティ・グループ（NSG）の一部としてのきめ細かいセキュリティルールにより、podのフリートは、オンプレミス・ネットワーク上のVCNまたはピア化されたVCN内の他のリソースにアクセスできます。これらのシナリオでは、本番クラスタと非本番クラスタの両方にVCNの同じサブネットを使用できますが、それらのクラスタで実行されているCloud Nativeアプリケーションのセキュリティをきめ細かく制御できます。

Calicoの使用など、podレベルでのきめ細かいネットワークポリシーの適用は、アプリケーションのワークロードの保護にも役立ち、今日の絶えず進化する脅威の状況に対する階層型の防御を提供します。

OKEのCNIの比較

まず、VCN-native pod networkingを構成する前に詳細を調べて、VCN-native pod networkingがFlannelを使用したOCI podネットワークとどのように異なるかを理解しましょう。

Native pod networking

VCN-native pod networkingでは、OCIは、複数の仮想ネットワーク・インターフェイス・カード（vNIC）を仮想マシン（VM）に接続し、複数のセカンダリIPアドレスを各vNICに関連付ける機能を使用します。 CNI DaemonSetは、ノードを更新して正しいCNIバイナリと構成を設定し、構成とバイナリを使用してpodをスケジュールします。

次に、各podは空きのセカンダリIPアドレスを選択し、それをpodに割り当てて、そのインターフェイスを介してインバウンド／アウトバウンドと通信できるようにします。 このようにして、各podはvNICに接続され、VCNに直接接続されます。 podには、podサブネットからプライベートIPが割り当てられます。 pod間の通信は、VCNをネイティブに（カプセル化せずに）通過します。 Kubernetesサービス（クラスタIP）は、クラスタ用に定義されたCIDRブロックからIPを取得します。

OKEで基本的なネットワーク要件を実現するための、単純なパターンがあります。これは基本的に、podが内部の仮想ネットワークに接続されているVCN内の仮想ネットワークです。このモデルでは、Kubernetesワーカーノードは、クラスタに固有のプライベート・オーバーレイ・ネットワークから独自のIPアドレスを取得するいくつかのpodを実行します。オーバーレイ・ネットワークのこの追加レイヤーは、レイヤー3でネットワークを提供するFlannel CNIプラグインを使用して構築されます。Flannel VXLANはUDPパケットです。 VXLANは、トラフィックをUDPパケットにカプセル化するためのプロトコルです。 FlannelはVXLANを使用して、2つの異なるホストでpod通信を行うためにトラフィックをUDPパケットにカプセル化します。

前の図は、異なるホストの2つのポッド間でパケットがどのように流れるかを示しています。アプリケーション環境でVCNのIPアドレスやワーカーノードごとの高密度ポッドを使用しない必要がある場合は、FlannelCNIを使用することをお勧めします。ノードあたりの密度に関連するもう1つの使用例は、VCNIPの枯渇です。 VCN IPの枯渇が考慮される場合、オーバーレイはCIDRブロック内のかなりのIPを解放します。

Getting started

VCN-native pod networkingを使用してKubernetesクラスタを設定する方法を見てみましょう。

次の手順で、VCN-native pod networkingを構成できます。

  1. Oracle Cloud ConsoleのDeveloper Servicesグループで、Containers and Artifactsに移動し、Kubernetes Clusters（OKE）をクリックします。 List Scopeで、作業を許可されているコンパートメントを選択し、Create clusterをクリックします。
  2. ネットワーク設定セクションで、クラスタの作成中にnative pod networkingを使用するように指定します。
  3. 有効になっている場合は、ロードバランサとAPIエンドポイントのVCNとサブネットを選択します。
  4. ノードプールを作成すると、pod用の追加のサブネット・オプションが表示されます。 native pod networkingでは、podは、そのノードと同じサブネットまたはVCNに接続する必要はありません。 ワーカーノードは、ノードとpodのサブセットに接続されています。 Kubelet、kube-proxy、およびnetworking daemonの通信の場合、ノードサブネットは、Kubernetesコントロールプレーンと、各ワーカーノードで実行されているKubeletまたはkube-proxyとの間の通信をサポートします。 ワーカーノードを公開する方法に応じて、パブリックまたはプライベートにすることができます。

5.全体的な構成を確認します。 すべてが正しい場合は、クラスター作成します。

6.クラスタが稼働しているとき、IPアドレスはVCN podサブネットCIDRブロックからpodに割り当てられます。 選択したpodサブネットがワーカーサブネットと同じである場合、pod IPはワーカーノードと厳密に一致します。

次のステップ

VCN-native pod networkingは、Kubernetes podをVCNに接続するため、VCNのセキュリティ機能とパフォーマンスを活用できます。 詳細については、VCN-native pod networkingのドキュメントを参照してください。 この新機能とOracle Cloud Infrastructureが提供するすべてのエンタープライズ・グレードの機能を試すには、$300の無料クレジットを使用してAlways Freeアカウントを今すぐ作成してください。