1. サブネットは計算できるのに、なぜPodは繋がらないのか
サブネットマスクの計算も、VLANの設計も、BGPのピアリングも問題なくこなせる。それなのに、Kubernetesクラスタを触り始めた途端、Pod同士がなぜ繋がらないのか分からなくなる——これは決して珍しい話ではありません。
Kubernetesネットワーキングは、従来のネットワーク設計とは異なる抽象化レイヤーの上に成り立っています。Podは頻繁に作られては消え、IPアドレスは固定されず、ルーティングテーブルを手作業で編集する余地はほとんどありません。Kubernetes公式ドキュメントが説明する通り、KubernetesのServiceリソースは「動的に変化するPodのIPアドレスから切り離された、安定したネットワークエンドポイント」を提供する仕組みであり、これは伝統的なネットワーク設計における「固定IP + 静的ルーティング」という前提そのものを覆します。
つまり、Kubernetesネットワーキングを理解するとは、ネットワークエンジニアが持つ「アドレス設計」の知識を、Kubernetesの「宣言的・動的」な世界にどう翻訳するかを学ぶことに他なりません。本記事では、CNI・Service Mesh・NetworkPolicyという3つの主要コンポーネントを、従来のネットワーク概念と対比しながら整理していきます。
とはいえ、この翻訳作業を毎回ゼロから自社でやり切る必要があるかというと、必ずしもそうではありません。KuboのようなマネージドKubernetesサービスでは、CNIの選定やNetworkPolicyの基本構成がすでに標準化された状態から始められます。まずはKubernetesネットワーキングの基礎を押さえておきましょう。
2. Kubernetesネットワーキングの3層構造 — CNI・Service・Ingress
Kubernetesネットワーキングは、大きく3つの層に分けて理解すると全体像がつかみやすくなります。
CNI(Container Network Interface) — Pod間通信の土台
CNIは、Podにネットワークインターフェースを割り当て、Pod間の実際のパケット転送を担うレイヤーです。CNIの仕様自体はプラグイン形式になっており、クラスタ構築時にどのCNIプラグインを採用するかによって、Pod間通信の実装方式(オーバーレイネットワークかBGPによるルーティングか等)が大きく変わります。
伝統的なネットワークで言えば、CNIは「スイッチとルーターの組み合わせ」に近い役割です。ただし、物理的なポート設定ではなく、Kubernetesのマニフェストによる宣言的な設定が基本になる点が最大の違いです。
Service — Pod群を隠す安定したエンドポイント
Podは頻繁にスケールアップ・ダウンし、IPアドレスも変わります。この不安定さを吸収するのがServiceリソースです。Kubernetes公式ドキュメントによれば、Serviceが作成されると固定のClusterIPが割り当てられ、コントローラが常にセレクタに一致するPodをスキャンして、対応するEndpointSliceを自動更新します。クライアント側はPodの個別IPを意識する必要がなく、ロードバランサ配下に複数のサーバーが隠れているのと同じ発想です。
Ingress — クラスタ外部との接点
クラスタ外部からのHTTP/HTTPSトラフィックをルーティングする役割を担うのがIngressです。従来のリバースプロキシ・ロードバランサの設定に近い概念ですが、Kubernetesではこれもマニフェストとして宣言的に管理される点が特徴です。
3. CNI選定の実際 — Cilium・Calico・Flannelの設計思想の違い
CNIプラグインの選定は、ネットワークエンジニアの既存知識が最も活きる、あるいは最も発想の転換を迫られる領域です。代表的な3つのプラグインを見てみましょう。
Cilium — eBPFで実現する可観測性とセキュリティ
Ciliumは、Linuxカーネルの機能であるeBPFを基盤にしたCNIプラグインです。CNCF公式の発表によれば、Ciliumは2021年10月にCNCF Incubatingプロジェクトとして採択された後、2023年10月にGraduated(卒業)レベルへ昇格しました。同発表では、100社以上での導入実績と800名以上の個別コントリビューターが参加していることが報告されており、CNCFの中でもKubernetes本体に次いで活発なプロジェクトの一つとされています。CNCFのプロジェクトページでも、CiliumはeBPFベースのネットワーキング・セキュリティ・可観測性ソリューションとして位置づけられています。
伝統的なネットワークエンジニアにとって、Ciliumの強みは「パケットの流れを可視化できる」という点にあります。従来のtcpdumpやNetFlowに近い感覚で、Pod間通信をリアルタイムに観測できるのは大きな利点です。
Calico — BGPネイティブという「馴染みのある」選択肢
Calicoは、BGP(Border Gateway Protocol)をベースにしたルーティングを採用できる点が特徴です。Calico公式ドキュメントでは、Calicoはコンテナ・仮想マシン・ベアメタルホストに対応するネットワーキング・セキュリティソリューションと説明されており、Kubernetesだけでなく OpenStack やベアメタル環境まで幅広くサポートしています。
BGPによるルーティングは、データセンターネットワークで培った知識がそのまま活きる数少ない領域であり、ネットワークエンジニアにとって最も「馴染みのある」CNIと言えるでしょう。
Flannel — シンプルな接続性に特化
Flannelは、公式リポジトリの説明にある通り「Kubernetes向けに設計されたシンプルなレイヤー3ネットワークファブリック」です。各ノード上でflanneldエージェントが動作し、あらかじめ設定されたアドレス空間からサブネットを割り当てる仕組みになっています。ポリシーエンジンを持たず、純粋な接続性提供に特化している点がCiliumやCalicoとの大きな違いです。K3sでは、このFlannelがデフォルトのCNIプラグインとして採用されており、バックエンドにはvxlanがデフォルト設定されています。
K3sベースのKubo Cloudも、この軽量なネットワーク構成を土台にしつつ、NetworkPolicy対応やモニタリングを標準搭載しているため、Flannel単体では手薄になりがちなポリシー制御・可観測性の部分を運用時に別途組み上げる手間を減らせます。
4. NetworkPolicyとService Meshは何が違うのか
Kubernetesネットワーキングを学ぶ上で、多くのエンジニアが混同しがちなのがNetworkPolicyとService Meshの役割の違いです。
NetworkPolicy — L3/L4のアクセス制御
Kubernetes公式ドキュメントによれば、NetworkPolicyは「IPアドレスやポートレベル(OSI層3/4)でのトラフィック制御」を実現するリソースであり、TCP・UDP・SCTPといったプロトコルをサポートします。重要な注意点として、公式ドキュメントは「NetworkPolicyはネットワークプラグインによって実装される」と明記しており、NetworkPolicy自体をサポートしないCNIプラグイン(前述のFlannelがその代表例です)を使っている場合、NetworkPolicyリソースを作成しても何の効果も発揮しません。
これは、伝統的なファイアウォールルールの設定に近い発想です。「どのPod(送信元)から、どのPod(宛先)への、どのポートへの通信を許可するか」を宣言的に定義する仕組みだと理解すると分かりやすいでしょう。
Service Mesh — L7の暗号化・可観測性・トラフィック制御
一方でService Meshは、L7(アプリケーション層)の機能を担います。代表的な実装であるIstioの場合、公式ドキュメントは「Istioはアプリケーションコードの変更なしに、相互TLS(mTLS)をトランスポート認証のフルスタックソリューションとして提供する」と説明しています。クライアント側とサーバー側それぞれのEnvoyプロキシがハンドシェイクを行い、身元を相互に検証した上でトラフィックを暗号化するという流れです。
つまり、NetworkPolicyが「通信していいか/悪いか」を判定するファイアウォールだとすれば、Service Meshは「通信そのものを暗号化し、誰が誰と話しているかを可視化する」レイヤーだという整理ができます。両者は競合する技術ではなく、組み合わせて使うことで初めて、L3/L4とL7の両方をカバーする防御が実現します。
5. まとめ — サブネット思考は土台になるが、発想の転換が必要
Kubernetesネットワーキングは、決して伝統的なネットワーク設計の知識を無駄にする技術ではありません。BGPの理解はCalicoの運用にそのまま活き、ファイアウォールルール設計の発想はNetworkPolicyの設計に直結します。一方で、「Podは動的に生成・消滅する」「IPは固定されない」「設定はマニフェストによる宣言的管理が基本」という前提の転換は避けて通れません。
CNIの選定、NetworkPolicyとService Meshの役割分担——これらを一つひとつ設計・検証していく作業は、決して小さな学習コストではありません。EKSやAKSでゼロからCNIを選定し、NetworkPolicyの対応状況を確認し、監視体制まで構築するには、相応の運用工数がかかります。
KuboはK3sをベースにしたマネージドKubernetesサービスで、CNIやネットワークポリシーの基本構成があらかじめ標準化されているため、ネットワーク設計の複雑さをゼロから検討する必要がありません。4vCPU/8GB/40GB×3ノード構成の場合、料金プランにある通り月額48,000円からフルスペックのKubernetes環境を運用開始でき、これはAWS EKSの月額82,700円と比較して大幅なコスト効率を実現します。
もちろん、Kuboは標準的なKubernetes APIをそのまま使えるため、Calico・Cilium由来の知識やBGPの経験がそのまま活かせる設計です。ネットワーク設計の土台を学びながら、実際の運用はマネージドサービスに任せるという選択肢も十分に現実的です。ネットワーク設計の詳細を自社で検討する余裕がない場合は、お問い合わせから現在の構成を相談してみるのも一つの手です。
Kubernetesネットワーキングという領域は、伝統的なネットワークエンジニアにとって「知らない言語」ではなく、「文法が変わった、馴染みのある言語」なのです。