コンテナネットワークの基礎知識【第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
-
製品資料
[o9ソリューションズ・ジャパン株式会社] 「改正物流効率化法対策」徹底解説 総物流費を抑制するサプライチェーン戦略 -
製品資料
[o9ソリューションズ・ジャパン株式会社] 「サプライチェーン最適化」実践ガイド:効果的な意思決定を実現する秘訣とは? -
製品資料
[株式会社リンプレス] 非デジタル/IT人材を「自走するDX推進者」に変えるための育成ロードマップ -
市場調査・トレンド
[ワンアイルコンサルティング株式会社] AI時代の組織設計:「判断と責任」を人に残すための2つの原則とは? -
技術文書・技術解説
[ワンアイルコンサルティング株式会社] システムの保守がモダン化を阻む? 「変えない判断」から脱却する方法とは
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
1200万円のSaaS導入を回避 スギ薬局「運用費10万円」のAIエージェント構築術
-
2
「完璧な設計」なのに3000万円溶けた AWSの失敗事例から学ぶ3つの教訓
-
3
クラウド資格コレクターは評価されない? 年収1000万を分ける“OSの理解度”
-
4
100億円の「Linux更新」を回避 みずほ銀行が選んだ“おきて破り”のRHEL延命策
-
5
「AIバブル」は崩壊するのか? 熱狂の後に来る“尻拭い”と4つの防衛策
-
6
高額な「AI PC」を一般従業員も使えたら? 費用のハードルを一気に下げる方法
-
7
LLMの「過学習」、正しく説明している文章はどれ?
-
8
「コピペ運用の限界」に直面するAI活用 7割超が“別画面”のまま使う理由は?
-
9
IT調達担当者が知るべき「IT機器 大インフレ時代の前向きな選択肢」
-
10
「RAGの利用」に関するアンケート
ホワイトペーパーランキング PR
-
1
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
2
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
3
Windows PCとMacの選択制で生産性向上 LINEヤフーが実践する運用管理方法とは
-
4
DX/AI投資の壁を突破、現代の最高財務責任者が直面する課題と克服のヒント
-
5
「Google Workspace」活用事例34選、先進の生成AIによる組織変革の全貌
-
6
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
7
「人員を増やす」という選択肢はない 情シスが負の連鎖から抜け出すには?
-
8
「問題が深刻化しやすいプロジェクト管理」から脱却する方法とは?
-
9
Linuxのスキルを証明する“激推し”の認定資格はこれだ
-
10
NTTドコモが実践したクラウド統合監視 業務量2倍でも残業削減を実現できた理由
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー