コンテナと仮想マシン間の通信はなぜ必要？　「OpenShift」「ACI」「NSX」のCNIとは

Kubernetesクラスタ内ではCNIプラグインを使ってコンテナ間の通信が実現します。「Cisco ACI」「NSX-T」「OpenShift」といったSDN製品による、オンプレミスインフラ向けのCNIプラグインを紹介します。

公開 2021年12月22日 05時00分

著者

奈良昌紀

細谷典弘

千葉豪

[ネットワンシステムズ]

印刷する連載新着通知を受け取る

　コンテナオーケストレーター「Kubernetes」のクラスタ（Kubernetesクラスタ）内の通信には、一般的にCNI（Container Networking Interface）プラグインを使用します。CNIプラグインは、コンテナ間の通信を定義するCNI（コンテナネットワークインタフェース）を実装したものです。クラウドサービスにおけるコンテナ通信を紹介した第10回「『EKS』『AKS』『GKE』のコンテナ理解に役立つVPCやVNetの通信とは？」に続いて、本稿はSDN（ソフトウェア定義ネットワーク）製品によるCNIプラグインを使った方法を取り上げます。

併せて読みたいお薦め記事

コンテナの基礎知識

オンプレミスインフラ向けのCNIプラグイン

Cisco ACI CNI Plug-in

　Cisco Systemsの「Cisco ACI」は、物理ネットワークと仮想ネットワークの一元管理や運用自動化を提供するSDN製品です。Cisco ACIはネットワークをポリシーで管理します。ポリシーの構成要素は「EPG」（End Point Group）と「Contract」です。

　EPGは仮想マシンや物理サーバなどのエンドポイントを含むさまざまな対象をグループ化した、論理的なエンティティ（実体）です。Contractは2つのEPG間の通信ルールを定義します。例えばクライアントを集めたグループを「EPG-Client」、Webサーバを集めたグループを「EPG-Webserver」として作成し、「Contract-Web」でTCPのポート80番と443番を許可する「EPG-Client ― Contract-Web ― EPG-Webserver」というポリシーを作成したとします。このポリシーでは、EPG内のクライアントとWebサーバ間でHTTPとHTTPS通信のみを許可することが可能です。

　Cisco ACIのCNIプラグインである「Cisco ACI CNI Plug-in」をKubernetesで使用すると、「Cluster」（Kubernetesクラスタ）や「Namespace」（名前空間：Kubernetesクラスタを分離した単位）、「Deployment」（Podのデプロイ管理をするオブジェクト）をCisco ACIがEPGとして認識し、ポリシーを利用してこれらのリソースの通信を制御することが可能になります。Cisco ACI CNI Plug-inは通信制御を担うL4（レイヤー4）のロードバランサー機能も提供しています。外部のロードバランサーと連携することも可能ですが、ロードバランサーを別で用意することなくKubernetesクラスタ外部にコンテナを公開できます。こうしたCisco ACI CNI Plug-inの機能や仕組みは全て物理スイッチが処理するので、サーバのネットワーク処理を物理スイッチへオフロードすることが可能です。

　先に述べたようにEPGには仮想マシンや物理サーバを登録することができるため、仮想マシンや物理サーバを含むEPGと、KubernetesのNamespace向けのEPGをContractで結ぶポリシーを作成することで、仮想マシンや物理サーバとコンテナ間のアクセス制御も可能です。

NSX Container Plug-in（NCP）

　「VMware NSX-T Data Center」（以下、NSX-T）はVMwareのハイパーバイザーと連携して機能するSDN製品です。KubernetesクラスタをVMwareのハイパーバイザーで構成する場合に、NSX-Tと、同製品のCNIプラグイン「NSX Container Plug-in」（NCP）を利用することで、「ノード」（コンテナの実行ホスト）内の仮想スイッチであるOpen vSwitch（OVS）と、NSX-Tが実現する論理スイッチ、論理ルーター、ファイアウォール、ロードバランサーなどの機能をKubernetesのリソースとして利用することが可能になります。

　ハイパーバイザーとNSX-Tが実現するネットワーク仮想化機能は、KubernetesのNamespaceごとに論理スイッチを構成し、Pod（コンテナの集合体）はノード内のOVSのブリッジ機能（OVS Bridge）を介してこの論理スイッチに接続します。論理スイッチは「Geneve」というカプセル化（プロトコル用のヘッダ情報の付与）プロトコルによりカプセル化され、このGeneveと論理ルーターによってノードをまたぐPod間通信が可能になります。NSX-Tのロードバランサー機能がServiceやIngressなどのリソースを提供し、NSX-Tの分散ファイアウォール機能がNetwork Policy（Pod間通信を制御するKubernetesの機能）を提供します。

OpenShift SDN

　「OpenShift SDN」は、Red Hatのコンテナ管理製品群「Red Hat OpenShift」が提供するCNIプラグインです。各ノードのOVS同士を仮想ネットワーク用のプロトコル「VXLAN」（Virtual eXtensible Local Area Network）でトンネリング（通信経路の確立）し、オーバーレイネットワーク（論理的に制御可能なネットワーク）を構成することでPod間の通信を可能にします。

　OpenShift SDNは「ネットワークポリシーモード」「マルチテナントモード」「サブネットモード」という3種類のモードを用意しています。各モードの特徴は次の通りです。

ネットワークポリシーモード
- KubernetesのNetwork Policyを利用してアプリケーションごとに通信制御することが可能です。通信制御はOVSが担います。
マルチテナントモード
- Namespace間の通信を制御します。
サブネットモード
- Podが他の全てのPodやService（Podグループへのアクセスを制御するリソース）と通信することが可能ですが、Namespace間の通信制御はできません。

　なお「Red Hat OpenShift 4.6」からは「OVN」（Open Virtual Network）というOVSの設定を管理するコントローラーを利用したCNI「OVN-Kubernetes」が利用可能になっています。OVN-Kubernetesはカプセル化プロトコルとしてGeneveを利用し、「iptables」（Linuxのパケットフィルタリング機能）への依存を少なくすることでデータ転送パフォーマンスの向上が期待できます。

仮想マシンとコンテナの混在ネットワーク

　第9回「『Kubernetes』を使うなら、まず知っておきたい『Flannel』と『Calico』の通信」で紹介した「Flannel」などのCNIプラグインは、ノード間の通信にオーバーレイネットワークを利用することで、既存ネットワークに干渉することなくPod間通信を実現します。そのためコンテナが接続するネットワークはホスト（Kubernetesクラスタ）内に隠匿され、既存ネットワークの管理とは分断します。

図1　分断化されたコンテナネットワーク《クリックで拡大》

　ワークロード（アプリケーション）のコンテナ化は進んでいますが、全てのワークロードをコンテナ化することは困難です。今後も仮想マシンは必要とされ、コンテナと仮想マシンが連携するシステムが増えると考えられます。仮想マシンだけではなく、データベースサービスなどのクラウドサービスをコンテナと組み合わせて利用することで、アプリケーションの運用を効率化することも期待できます。

　コンテナの活用が進むにつれて、既存ワークロードとの連携はより重要なものとなり、コンテナがネットワーク内で特殊な存在ではなく、一般的な存在として扱われることが求められています。このような背景の下、本連載で紹介したCNIプラグインは、Podが利用するコンテナネットワークと仮想マシンが利用するネットワークの統合を実現するものです。仮想マシンが利用する既存ネットワークとPodがシームレスに接続する仕組みを使うことで、Podが既存の仮想マシンや既存のサービスと直接通信したり、既存ネットワークが提供するロードバランサーやファイアウォールなどの機能を活用したりすることが可能になります（図2）。

図2　コンテナと仮想マシンの混在ネットワーク《クリックで拡大》

　この連載では、コンテナネットワークの基礎知識として主にネットワークに焦点を当てて説明しましたが、連載で触れたのは注目点の一部です。例えばサービスメッシュ（マイクロサービス間の通信を制御する仕組み）などの新しい技術が積極的に活用されています。Kubernetesはコンテナのオーケストレーションにとどまらず、仮想マシンやパブリッククラウドのリソースにまで管理を広げつつあります。こうしたさまざまな動きがあり、コンテナやKubernetesは今後も目が離せない技術領域です。