コンテナと仮想マシン間の通信はなぜ必要？　「OpenShift」「ACI」「NSX」のCNIとは：コンテナネットワークの基礎知識【第11回】

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

コンテナの基礎知識

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

Cisco ACI CNI Plug-in

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

コンテナと仮想マシン間の通信はなぜ必要？　「OpenShift」「ACI」「NSX」のCNIとは：コンテナネットワークの基礎知識【第11回】

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種類のモードを用意しています。各モードの特徴は次の通りです。

マルチテナントモード

サブネットモード

なお「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は今後も目が離せない技術領域です。

執筆者紹介

奈良昌紀（なら・まさのり）ネットワンシステムズビジネス開発本部第1応用技術部

通信事業者のデータセンターにおいてネットワークやサーバの運用を経験後、ネットワンシステムズに入社。帯域制御やWAN高速化製品、仮想化関連製品を担当後、主にクラウドや仮想インフラの管理、自動化、ネットワーク仮想化の分野に注力している。

細谷典弘（ほそや・のりひろ）ネットワンシステムズビジネス開発本部第3応用技術部

データセンターネットワークの他、マルチクラウド向けのハードウェアやソフトウェアの最先端技術に関する調査・検証、技術支援などを担当。注目分野は「Kubernetes」。放送システムのIP化に向けた技術調査・検証も担当している。

千葉豪（ちば・ごう）ネットワンシステムズビジネス開発本部第1応用技術部

IaaS（Infrastructure as a Service）をはじめとしたクラウド基盤技術および管理製品を担当。コンテナ技術を中心とした開発・解析基盤の構築から運用、コンテナに関連した自動化技術や監視製品の技術検証などに注力している。

タグ vmwareやMACでのカメラの使い方