CiliumでeBPFベースのネットワークポリシーを段階導入する計画

eBPFベースのネットワーク制御が現場で求められる背景

Kubernetesクラスターが大規模化するにつれ、従来のiptablesベースCNIが抱える性能問題が顕在化してきました。数千のPodが稼働する環境では、iptablesのルールチェーンが線形的に増加し、接続確立のレイテンシが増大したり、ルール更新時にカーネルロックの競合が発生するケースが報告されています。

eBPF（extended Berkeley Packet Filter）はLinuxカーネル内でサンドボックス化されたプログラムを実行できる機構であり、ネットワークパケットをカーネルスペースで直接処理できます。CiliumはこのeBPFを全面的に活用したCNIプラグインで、IPアドレスではなくKubernetesラベルに基づく「アイデンティティベース」のポリシー判定をeBPFマップ上で高速に実行します。さらに、HTTP/gRPCといったアプリケーション層（L7）でのアクセス制御や、HubbleによるリアルタイムのPod間フロー可視化という機能も標準で備えています。

一方で、既存クラスターへの導入は一度に切り替えるのではなく、段階的に進めるのが現実的です。本記事では「監査モードで既存トラフィックをマッピング → ポリシーを作成して試験的に適用 → Enforcement（強制）に昇格 → 切り戻し手順の整備」という流れを、実際の運用シナリオとして解説します。

段階導入の全体像と前提条件の確認

段階導入は大きく3フェーズに分けると整理しやすくなります。

• フェーズ1（Audit）：Ciliumを監査モードで稼働させ、Hubbleを使って既存のPod間通信をすべて可視化する。この段階でポリシー違反になりそうなフローを事前に把握します。
• フェーズ2（Draft Policy）：観測したフロー情報をもとにCiliumNetworkPolicyを作成し、特定のNamespaceのみを対象に試験適用します。
• フェーズ3（Enforcement）：問題がないことを確認してから強制モードへ昇格し、Namespaceを順次拡大していきます。

前提として、CiliumのインストールにはLinuxカーネル4.19以上（推奨5.10以上）が必要です。2026年時点でUbuntu 22.04以降・RHEL 9系を使用しているならカーネル要件はほぼ満たされています。Helmを使ったインストールが一般的であり、helm repo add cilium https://helm.cilium.io/でリポジトリを追加した後、Valuesファイルで監査モードを設定します。既存CNI（Flannel・Calico等）からの移行の場合は、ノード単位の順次置き換えか、一時的なダウンタイムを許容するかによって手順が変わります。事前にNode Drain計画を立てておくことが推奨されます。

監査モードで既存トラフィックを可視化する

Ciliumを監査モードで起動するには、Helmのvalues.yamlに以下の設定を加えます。

policyEnforcementMode: "audit"
hubble:
  enabled: true
  relay:
    enabled: true
  ui:
    enabled: true

policyEnforcementMode: "audit"を指定すると、NetworkPolicyやCiliumNetworkPolicyにマッチしないフローが実際には遮断されず、「audit」ログとして記録されるだけになります。この状態で数日〜1週間程度クラスターを運転し、Hubble CLIでフローを観察します。

# Hubble CLIのインストール後（バイナリをPATHへ配置）
hubble observe --namespace production --type drop,audit --follow

出力されるフローには送信元Pod・宛先Pod・ポート・プロトコル・ポリシー判定が含まれます。「audit」判定のフローは、将来的にポリシーを強制適用した際に遮断される候補です。多くの運用現場では、この段階で想定外のサービス間依存関係が見つかることがあります。たとえば、ログ収集エージェントが意図せず別Namespaceのメトリクスエンドポイントにアクセスしていたケースが典型例として挙げられます。このような隠れた依存を洗い出せることが、Enforcement昇格前の監査フェーズを設ける最大の価値です。

CiliumNetworkPolicyの作成と段階的な強制適用

Hubbleで観察したフローをもとに、まず1つのNamespaceに絞ってポリシーを作成します。CiliumNetworkPolicyはKubernetesの標準NetworkPolicyを拡張したCRDで、L7条件やアイデンティティセレクターを記述できます。以下はapp: frontendラベルを持つPodがapp: backendへの8080番ポートのみ通信できるように許可するシンプルな例です。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

このYAMLをkubectl applyで適用しても、クラスターがauditモードのままであれば通信は遮断されません。まずaudit状態でポリシーをデプロイし、Hubbleのフローログでマッチ状況を確認してから次のステップへ進みます。

Namespace単位でEnforcementへ昇格させるには、Namespaceラベルによるオーバーライドが便利です。CiliumはNamespaceラベルを参照してポリシー適用モードをNamespaceごとに上書きできます。

kubectl label namespace production policy.cilium.io/enforcement=always

このラベルを付与することで、クラスター全体のauditモードを維持したままproduction Namespaceだけを強制適用モードに移行できます。Namespaceを1つずつ切り替えることで、影響範囲を最小化しながら段階的に本番適用を進めることが可能です。

動作検証と切り戻し手順

Enforcement昇格後は、Hubbleで実際にフローがDROPされていないかを確認します。

hubble observe --namespace production --type drop --follow

DROPフローが出力された場合、どのPodからどのPodへの通信が遮断されているかをラベルセレクターを手がかりに特定し、CiliumNetworkPolicyに許可ルールを追加します。アプリケーション側のダウンタイムを最小化するため、「許可ルールを追加してから動作確認」というサイクルを繰り返すのが基本方針です。

緊急の切り戻しが必要な場合は、Namespaceラベルを削除してauditモードに戻すのが最速の手段です。

kubectl label namespace production policy.cilium.io/enforcement-

これによりNamespaceはクラスターのグローバル設定（audit）にフォールバックし、即座にポリシー遮断が解除されます。CiliumNetworkPolicy自体は残るため、原因究明・ポリシー修正の後に再度ラベルを付与して昇格できます。クラスター全体をauditに戻す場合はHelmでのupgradeが必要でDaemonSetの再起動を伴うため、数秒のパケットロスが発生しうる点は把握しておく必要があります。Namespace単位の切り戻しはDaemonSet再起動を伴わないため、影響範囲が格段に小さくなります。

2026年時点のCilium最新環境との差分

本記事の手順はCilium 1.16系・Kubernetes 1.30系以降を想定しています。この前後でいくつかの変更点が運用に影響します。

• CiliumNetworkPolicy v2 の整理：Cilium 1.15以降でCRDの構造が整理されました。旧来のcilium.io/v2alpha1で記述していた一部リソースはv2に統合されており、古いYAMLがそのまま動作しないことがあります。公式が提供するcilium-cliのマイグレーション機能を活用することが推奨されます。
• Gateway API のファーストクラスサポート：Cilium 1.14以降でKubernetes Gateway API（networking.k8s.io/v1）が正式サポートされました。Ingressの代替として採用する現場が増えており、NetworkPolicyとGateway Policyを組み合わせる構成が標準的なパターンになりつつあります。
• AdminNetworkPolicy（alpha）との関係：Kubernetes本体でもNetwork Policy APIの拡張が進んでおり、クラスター管理者がテナントより優先されるポリシーを設定できるAdminNetworkPolicyが一部環境でalphaとして利用可能になっています。Ciliumはこれをサポートしていますが、仕様が安定化の途中であるため本番適用は慎重な評価が必要です。
• Hubble UIの依存グラフ強化：Hubble UI 0.13以降でNamespace間の依存関係グラフが強化され、どのマイクロサービスがどのエンドポイントに依存しているかを視覚的に把握しやすくなっています。監査フェーズでのトラフィックマッピング作業の効率が上がるため、積極的に活用する価値があります。

段階導入の計画を立てる際は、使用するCiliumのバージョンとKubernetesのバージョン組み合わせの互換性マトリクスを事前に確認することが重要です。Cilium公式ドキュメントの「Kubernetes Compatibility」ページが継続的に更新されているため、導入前の確認を習慣づけることが現場のトラブル予防につながります。