コンテナネットワークの基礎知識【第11回】
コンテナと仮想マシン間の通信はなぜ必要? 「OpenShift」「ACI」「NSX」のCNIとは
Kubernetesクラスタ内ではCNIプラグインを使ってコンテナ間の通信が実現します。「Cisco ACI」「NSX-T」「OpenShift」といったSDN製品による、オンプレミスインフラ向けのCNIプラグインを紹介します。
コンテナオーケストレーター「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クラスタ)内に隠匿され、既存ネットワークの管理とは分断します。
ワークロード(アプリケーション)のコンテナ化は進んでいますが、全てのワークロードをコンテナ化することは困難です。今後も仮想マシンは必要とされ、コンテナと仮想マシンが連携するシステムが増えると考えられます。仮想マシンだけではなく、データベースサービスなどのクラウドサービスをコンテナと組み合わせて利用することで、アプリケーションの運用を効率化することも期待できます。
コンテナの活用が進むにつれて、既存ワークロードとの連携はより重要なものとなり、コンテナがネットワーク内で特殊な存在ではなく、一般的な存在として扱われることが求められています。このような背景の下、本連載で紹介したCNIプラグインは、Podが利用するコンテナネットワークと仮想マシンが利用するネットワークの統合を実現するものです。仮想マシンが利用する既存ネットワークとPodがシームレスに接続する仕組みを使うことで、Podが既存の仮想マシンや既存のサービスと直接通信したり、既存ネットワークが提供するロードバランサーやファイアウォールなどの機能を活用したりすることが可能になります(図2)。
この連載では、コンテナネットワークの基礎知識として主にネットワークに焦点を当てて説明しましたが、連載で触れたのは注目点の一部です。例えばサービスメッシュ(マイクロサービス間の通信を制御する仕組み)などの新しい技術が積極的に活用されています。Kubernetesはコンテナのオーケストレーションにとどまらず、仮想マシンやパブリッククラウドのリソースにまで管理を広げつつあります。こうしたさまざまな動きがあり、コンテナやKubernetesは今後も目が離せない技術領域です。
執筆者紹介
奈良昌紀(なら・まさのり) ネットワンシステムズ ビジネス開発本部第1応用技術部
通信事業者のデータセンターにおいてネットワークやサーバの運用を経験後、ネットワンシステムズに入社。帯域制御やWAN高速化製品、仮想化関連製品を担当後、主にクラウドや仮想インフラの管理、自動化、ネットワーク仮想化の分野に注力している。
細谷典弘(ほそや・のりひろ) ネットワンシステムズ ビジネス開発本部第3応用技術部
データセンターネットワークの他、マルチクラウド向けのハードウェアやソフトウェアの最先端技術に関する調査・検証、技術支援などを担当。注目分野は「Kubernetes」。放送システムのIP化に向けた技術調査・検証も担当している。
千葉 豪(ちば・ごう) ネットワンシステムズ ビジネス開発本部第1応用技術部
IaaS(Infrastructure as a Service)をはじめとしたクラウド基盤技術および管理製品を担当。コンテナ技術を中心とした開発・解析基盤の構築から運用、コンテナに関連した自動化技術や監視製品の技術検証などに注力している。
Copyright © ITmedia, Inc. All Rights Reserved.
コンテナネットワークの基礎知識
この記事の著者
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣 -
製品資料
[サイボウズ株式会社] AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
2
情シスの約8割が転職や退職を意識 調査で分かった“辞めたくなる最大の理由”
-
3
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
4
AIの導入効果はどう測る? DMM.comのエンジニア組織に学ぶ効果検証のノウハウ
-
5
【漫画付き】ひとり情シス協会が明かす、RAG導入でしくじる企業「2つの共通点」
-
6
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
7
情報漏えいはなぜ繰り返されるのか 今すぐ見直すべき「境界」
-
8
「Wi-Fi 7」経由でWindowsが乗っ取られる? 最高権限奪取の恐怖
-
9
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
10
「中堅・中小企業のネットワーク・セキュリティ運用実態」に関するアンケート
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
4
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
5
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
6
「オンプレミス回帰」せざるを得ない“合理的な理由”
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
生成AIを開発に導入しても効果が見えない? 実証実験で分かった成果と課題
-
9
経産省DX指針から読み解く、受発注業務デジタル化ロードマップ
-
10
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー