Kubernetes を従来インフラから理解する – オンプレミスとの対応関係と NFV でのネットワーク拡張

Kubernetes は、初めて触れる人にとって理解しにくい技術です。難しい理由は、単に機能が多いからではありません。従来のサーバー、仮想化基盤、ネットワーク装置を扱ってきた人が持つ管理単位と、Kubernetes が前提にする管理単位が違うからです。

オンプレミスの運用では、どのサーバーに SSH するのか、どの設定ファイルを書き換えるのか、どの VM にサービスが存在するのか、障害時にはどの装置を確認するのか、という発想から入りがちです。しかし Kubernetes では、この考え方をそのまま持ち込むと構造が見えにくくなります。

本稿では、Kubernetes の基本概念を従来インフラとの対応関係から整理します。その上で、CRI、CNI、CSI、通常の Kubernetes ネットワーク、さらに NFV で必要になる Multus、SR-IOV、DPDK のようなネットワーク拡張を、標準モデルからの延長として捉えます。

Kubernetes は望ましい状態を維持する

Kubernetes は、よくコンテナオーケストレーション基盤と説明されます。この説明は間違いではありませんが、それだけでは本質が見えません。Kubernetes の重要な特徴は、個々のサーバーやプロセスを直接操作するのではなく、システムとして望ましい状態を宣言し、その状態を維持させることにあります。

たとえば、Web サーバーを 3 個動かしたい、特定のコンテナイメージを使用したい、外部から特定の名前や IP アドレスでアクセスできるようにしたい、永続データを保存できるようにしたい、といった状態を定義します。Kubernetes は現在の状態と望ましい状態を比較し、差があれば修正します。Pod が 1 個停止して 2 個になれば、新しい Pod を起動して 3 個へ戻します。

従来の発想	Kubernetes の発想
対象サーバーへログインして操作する	望ましい状態を API へ定義する
設定変更手順を実行する	宣言された状態へ制御ループが収束させる
プロセス単位で起動や停止を確認する	Deployment や Pod の状態として確認する
サービスが存在するサーバーを固定的に考える	Pod は再作成される前提で、Service で到達性を安定させる

この違いを理解すると、Kubernetes の多くの機能が見えやすくなります。管理対象はサーバーそのものから、システムの望ましい状態へ移っています。

Node、Pod、Deployment、Service を対応関係で見る

Kubernetes には独自の用語が多くありますが、すべてを未知のものとして覚える必要はありません。従来インフラとの対応関係を置くと理解しやすくなります。ただし、完全に一対一で対応するわけではありません。近い概念を手がかりにしながら、どこが違うのかを見ることが重要です。

Kubernetes の要素	従来インフラで近いもの	重要な違い
Node	物理サーバー、VM	アプリケーションを特定 Node へ固定することを基本思想にはしない
Pod	プロセス、サービス実行単位、小さな VM 的実行単位	恒久的な存在ではなく、削除と再作成を前提にする
Deployment	複数サーバー上のアプリケーション配置設計	Pod の数やイメージを継続的に維持する制御対象になる
Service	VIP、ロードバランサー、サービス用 IP アドレス	変化する Pod 群に対して安定した到達点を提供する
ConfigMap	設定ファイル	アプリケーション本体と設定値を分離して管理する
Secret	パスワード、証明書、秘密情報ファイル	機密情報を Kubernetes リソースとして扱う
PersistentVolume / PersistentVolumeClaim	SAN、NAS、仮想ディスク、共有ストレージ	Pod の寿命とデータの寿命を分離する

特に重要なのは、Pod は恒久的なサーバーではないという点です。Pod は削除され、別の Pod として再作成されることを前提とします。そのため、Pod の IP アドレスへ直接依存する設計ではなく、Service や永続ボリュームなどを使って、到達性やデータの寿命を分離します。

Kubernetes は一枚岩ではない

Kubernetes を理解する上で重要なのは、Kubernetes 本体がコンテナ、ネットワーク、ストレージのすべてを自前で実装しているわけではないという点です。Kubernetes は、それぞれの領域について外部実装と連携するための標準的なインターフェースを持っています。代表的なものが CRI、CNI、CSI です。

インターフェース	担当領域	代表的な実装や接続先
CRI	コンテナ実行	containerd、CRI-O
CNI	Pod ネットワーク	Calico、Cilium、Multus など
CSI	永続ストレージ	Ceph CSI、各種ストレージベンダー CSI

Kubernetes は、どのコンテナランタイムを使うか、どのネットワーク方式を使うか、どのストレージ装置を使うかを完全に固定していません。標準インターフェースを介して、それぞれの実装を組み合わせます。これにより、クラウド、オンプレミス、NFV のように前提が異なる環境でも、Kubernetes の制御モデルを維持しながら実装を差し替えられます。

CRI はコンテナを実際に動かす接続点である

CRI は Container Runtime Interface の略です。Kubernetes は Pod を作成するとき、Node 上の kubelet を通じてコンテナランタイムへコンテナの作成や停止を依頼します。代表的なランタイムには containerd や CRI-O があります。

つまり Kubernetes 自身が直接コンテナを起動しているわけではありません。Kubernetes は、望ましい状態を管理し、CRI を介してランタイムへ処理を依頼します。従来の仮想化環境で例えるなら、管理システムがハイパーバイザーへ VM の作成や停止を依頼する構造に近い部分があります。

この分離を理解しておくと、Kubernetes の障害調査でも見方が変わります。Pod が起動しない場合、それが Kubernetes API の問題なのか、kubelet の問題なのか、CRI 経由のランタイムの問題なのか、イメージ取得やコンテナ作成の問題なのかを分けて考えられます。

CNI は Pod ネットワークを実現する

CNI は Container Network Interface の略です。Pod を作成すると、その Pod へネットワークインターフェースを作成し、IP アドレスを割り当て、他の Pod や外部ネットワークと通信できる状態にする必要があります。この処理を担うのが CNI です。

Kubernetes のネットワークモデルは共通でも、その実現方式は CNI によって異なります。Pod への IP アドレス割り当て、Pod 間ルーティング、Overlay ネットワーク、BGP、NetworkPolicy などの扱いは、Calico、Cilium などの実装によって変わります。

CNI で変わるもの	設計上の意味
Pod IP の割り当て	クラスタ内部のアドレス設計に影響する
Pod 間通信の実現方式	Overlay、ルーティング、eBPF などの実装差が出る
外部ネットワークとの統合	BGP やロードバランサー設計と関係する
NetworkPolicy	Pod 間通信の制御方法と実装能力に影響する
運用時の可視性	障害調査で見るべきログ、経路、メトリクスが変わる

オンプレミス環境で Kubernetes ネットワークと物理ネットワークを統合する場合、CNI の選定は単なるプラグイン選択ではありません。既存ルーター、BGP、Service 公開、Pod CIDR、NetworkPolicy、運用監視まで含むネットワーク設計の一部になります。

CSI は Pod の寿命とデータの寿命を分ける

CSI は Container Storage Interface の略です。Pod は再作成されることを前提とするため、Pod 内だけにデータを保存すると、Pod の削除や再作成によってデータが失われます。永続データを扱うには、Pod の寿命とデータの寿命を分離する必要があります。

Kubernetes では、PersistentVolumeClaim を通じてストレージを要求し、CSI Driver を介して外部ストレージを準備します。接続先は SAN、NAS、Ceph、クラウドブロックストレージなどさまざまです。Kubernetes 側から見れば、ストレージ製品ごとの細かい実装を直接意識せず、標準化された仕組みでボリュームを扱えます。

ただし、CSI を使えばストレージ設計が不要になるわけではありません。性能、可用性、バックアップ、スナップショット、障害ドメイン、Pod の再配置時の接続性などは、従来のストレージ設計と同じように考える必要があります。Kubernetes はストレージを抽象化しますが、物理的な制約を消すわけではありません。

Kubernetes では変更するのではなく定義する

Kubernetes の重要な特徴の一つが宣言的管理です。従来の運用では、サーバーへログインし、設定を書き換え、コマンドを実行し、プロセスを再起動するという命令的な操作が中心でした。Kubernetes では、最終的にどうなっていてほしいかを Manifest や API で定義します。

たとえば Deployment で replicas を 3 と定義することは、Pod を 3 個作成せよという一回限りの命令ではありません。Pod が 3 個存在する状態を維持せよという意味になります。1 個停止すれば、Kubernetes が新しい Pod を作成して望ましい状態へ戻します。

この性質から、Kubernetes は IaC や GitOps と相性が良くなります。ただし、YAML を書くこと自体が IaC なのではありません。重要なのは、インフラやアプリケーションの状態を機械可読な形で定義し、誰が、いつ、何を、なぜ変更したのかを追跡でき、同じ定義から同じ状態を再現できることです。

クラウドとオンプレミスでは外部公開の見え方が違う

Kubernetes では Pod 間通信のためのネットワークモデルが定義され、実際の Pod ネットワークは CNI によって実現されます。ここで重要なのは、Pod 同士をどのようにつなぐかという問題と、Service をクラスタ外部からどのように到達可能にするかという問題は別であることです。

クラウド環境では、Service に LoadBalancer を指定すると、Cloud Controller Manager などを介してクラウド側のロードバランサーが作成されます。利用者から見ると、Service を定義しただけで外部から利用できるように見えます。しかし実際には、クラウド側のロードバランサー、ルーティング、IP アドレス管理などと連携しているだけです。

オンプレミスには、Kubernetes が当然のように利用できるクラウドロードバランサーは存在しません。そのため、外部公開の方法を自分たちで設計する必要があります。既存ロードバランサーを使うのか、MetalLB のような仕組みを使うのか、BGP で Service 用 IP アドレスへの経路を広告するのかを決める必要があります。

外部公開の方法	考えるべき点
既存ロードバランサー	Kubernetes API との連携、運用手順、ヘルスチェック
MetalLB など	アドレスプール、L2 / BGP モード、既存ネットワークとの整合
CNI や周辺機能による BGP 連携	外部ルーター、経路制御、障害時の収束
Ingress Controller	L7 ルーティング、TLS、公開ドメイン、外部 LB との役割分担

クラウドでは外部公開の仕組みの多くをクラウド基盤が隠蔽しますが、オンプレミスではこの部分がネットワーク設計として前面に出ます。Kubernetes をオンプレミスで使う難しさは、Kubernetes の機能不足ではなく、Kubernetes と既存ネットワークの境界を自分たちで設計しなければならない点にあります。

NFV では Pod がネットワーク装置に近づく

通常の Kubernetes では、アプリケーションは Pod ネットワークの中に存在し、外部からの到達性は Service、LoadBalancer、Ingress、BGP による Service IP 広告などで実現します。この場合、Pod そのものを物理ネットワークへ直接接続する必要はありません。

NFV では事情が変わります。仮想ルーター、仮想ファイアウォール、BGP Route Reflector、DPI、CGN、ロードバランサーのような Network Function を Kubernetes 上で動かす場合、それらは単なる Web アプリケーションではなく、ネットワーク装置そのものとして振る舞う必要があります。

• 複数のネットワークインターフェースを持たせたい
• 特定 VLAN へ直接接続したい
• 外部ルーターと BGP を確立したい
• NIC を Pod へ直接割り当てたい
• 高速なパケット処理を行いたい

標準的な Pod ネットワークだけでは、これらの要件を満たせない場合があります。そこで Multus、SR-IOV、DPDK などを、必要に応じて追加します。重要なのは、最初から Kubernetes を NFV 向けの特殊基盤として別物扱いするのではなく、標準モデルのどこが足りないのかを確認して拡張することです。

Multus は複数ネットワーク接続を可能にする

通常の Pod は、基本的に 1 つの Pod ネットワークへ接続されます。しかし NFV では、管理用ネットワーク、内部ネットワーク、外部ネットワークのように、複数のネットワークへ接続したい場合があります。このような場合に Multus を利用できます。

Multus は、通常の Kubernetes ネットワークに加えて、Pod へ追加のネットワークインターフェースを割り当てるための仕組みです。たとえば、eth0 は通常の Pod ネットワークに接続し、net1 は VLAN 100、net2 は VLAN 200 に接続する、といった構成を作れます。これにより、Kubernetes 上の Pod でありながら、従来のネットワーク装置に近いインターフェース構成を持たせられます。

Pod 内のインターフェース	役割の例
eth0	通常の Pod ネットワーク。Kubernetes Service やクラスタ内通信に使う
net1	管理ネットワーク、制御プレーン、監視用通信などに使う
net2	データプレーン、外部 VLAN、NF 間通信などに使う

ただし、複数 NIC を持たせればよいという話ではありません。どのネットワークを Kubernetes の管理下に置き、どのネットワークを外部設計として扱うのか、IPAM、ルーティング、セキュリティポリシー、障害時の切り分けを含めて設計する必要があります。

SR-IOV と DPDK は性能要件から追加する

さらに高いパケット処理性能が必要な場合には、SR-IOV や DPDK を検討します。SR-IOV では、物理 NIC が持つ Virtual Function を Pod へ直接割り当てます。通常の仮想ネットワークを経由する処理を減らし、高速なパケット転送を実現しやすくなります。

DPDK は、通常の Linux カーネルネットワークスタックを迂回し、ユーザー空間で高速にパケットを処理するための技術です。通信キャリア向けの NFV や高性能なデータプレーンでは、このような技術が必要になる場合があります。

技術	主な目的	注意点
Multus	Pod に複数ネットワークを接続する	複数 NIC の意味、IPAM、経路、運用責任を設計する必要がある
SR-IOV	NIC の Virtual Function を Pod に直接割り当てる	ノード依存性、スケジューリング、障害時の再配置に制約が出る
DPDK	ユーザー空間で高速にパケット処理する	CPU、メモリー、HugePages、運用監視、アプリケーション実装への影響が大きい

これらは Kubernetes の基本機能ではありません。通常の Pod ネットワークと Service のモデルを理解した上で、それでは足りない性能や接続要件がある場合に追加するものです。特殊技術から入ると、Kubernetes の標準モデルと NFV の拡張部分の境界が分からなくなります。

Kubernetes を新しい仮想化基盤だけで捉えない

Kubernetes を初めて見ると、VM の代わりにコンテナを動かす新しい仮想化基盤のように見えることがあります。しかし、この理解だけでは Kubernetes の本質を捉えきれません。Kubernetes が大きく変えたのは、コンテナを使うこと以上に、システムを管理する単位と方法です。

Kubernetes は、複数のインフラ機能を共通の宣言モデルから制御する基盤として捉えた方が理解しやすくなります。コンテナ実行は CRI、ネットワークは CNI、ストレージは CSI に委譲し、Kubernetes 本体は望ましい状態と制御ループを中心に全体を扱います。

従来インフラを知っている人ほど、Kubernetes を理解する手がかりは多く持っています。ただし、その手がかりをサーバー単位の操作へ固定してしまうと、Kubernetes の考え方と衝突します。対応関係を使いながら、管理単位がサーバーから宣言された状態へ移っていることを理解する必要があります。

NFV でも標準モデルから拡張する

NFV で Kubernetes を使う場合にも、最初から特殊なネットワーク技術だけを見るべきではありません。まず Pod、Deployment、Service、CRI、CNI、CSI、宣言的管理という標準モデルを理解する必要があります。その上で、この Network Function では標準モデルのどこが足りないのかを確認します。

要件	まず見るべき構成
通常のアプリケーションとして動けばよい	標準 Pod ネットワークと Service
外部から Service へ安定して到達させたい	LoadBalancer、Ingress、BGP、既存 LB 連携
複数ネットワークへ接続したい	Multus と追加 CNI
NIC を直接割り当てたい	SR-IOV
高性能なユーザー空間パケット処理が必要	DPDK

この順序で考えると、Kubernetes と NFV を無理に分離せずに済みます。標準的な Kubernetes を基礎として、その不足部分をネットワーク機能の要件に合わせて拡張する。この捉え方の方が、設計上の境界も、運用上の責任分界も明確になります。

まとめ

Kubernetes は、従来のオンプレミス環境とは異なる概念体系を持っています。しかし、一つずつ対応関係を整理すれば、まったく未知の技術ではありません。重要なのは、管理の中心が個々のサーバーから、望ましいシステム状態へ移っていることです。

また、Kubernetes はすべてを自前で実装する一枚岩のシステムではありません。CRI によってコンテナランタイムと接続し、CNI によってネットワークを実現し、CSI によってストレージと接続します。クラウドでは外部公開の多くをクラウド基盤が隠蔽しますが、オンプレミスでは CNI、BGP、ロードバランサーなどを組み合わせて自分たちで設計する必要があります。

さらに NFV では、Pod そのものをネットワーク装置に近い形で外部ネットワークへ接続する要件が出ます。その場合に Multus、SR-IOV、DPDK などを追加します。ただし、これらは標準モデルを置き換えるものではありません。Kubernetes を理解する順序は、標準モデルを理解し、その実装を支える CRI、CNI、CSI を理解し、必要に応じて NFV 向けに拡張する、という順序であるべきです。

参考書籍

参考資料

• Kubernetes Documentation: Overview
• Kubernetes Documentation: Service
• Kubernetes Documentation: CRI
• Container Networking Interface
• Container Storage Interface Specification
• Multus CNI
• SR-IOV Network Device Plugin
• DPDK

関連する記事