eBPFが変えるクラウドネイティブインフラ——Cilium・Tetragon・Hubbleで開くゼロトラスト・オブザーバビリティの新世代

はじめに

「Kubernetesクラスターの規模が大きくなるにつれて、iptablesルールの更新に数秒かかるようになった」——これは、クラウドネイティブインフラを運用する多くのエンジニアが直面する現実です。

マイクロサービスアーキテクチャが普及し、Kubernetesクラスター上で動くサービス数が200、500、ときには1,000を超える規模になると、従来のネットワーキング基盤が限界を迎えます。kube-proxyが依存するiptablesは、サービス数の増加に対して線形（O(n)）にパフォーマンスが劣化します。200サービスを超えたあたりで、ルールの更新に数秒かかるようになり、新しいPodの起動からトラフィックが流れるまでのレイテンシが無視できなくなります。

さらに、サービスメッシュの導入による負担も深刻です。Istioなどのサイドカーモデルを採用した場合、各PodにEnvoyプロキシが注入され、Podあたり50〜150MBのメモリを消費します。1,000 Pod規模のクラスターでは、プロキシだけで数百GB〜1TB以上のメモリリソースが圧迫されます。CPUオーバーヘッドも無視できず、p99レイテンシに0.6〜1.5msの追加遅延が発生します。

そして、トラブルシューティングの課題もあります。「Frontend PodからBackend Podへの通信が失敗している」——この原因がネットワークポリシーなのか、DNS解決の失敗なのか、それともアプリケーション側のバグなのか、可視性がないがために切り分けに何時間も費やすことになります。

本記事が約束するのは、これらの課題をeBPF（extended Berkeley Packet Filter）という技術がどう解決するかを、具体的な導入手順と実測値とともに解説することです。

eBPFは、Linuxカーネルのコードを変更・再コンパイルすることなく、カーネル空間で安全にプログラムを実行できる技術です。2026年現在、この技術を活用したCilium・Tetragon・Hubbleという3つのオープンソースプロジェクトが、クラウドネイティブインフラのネットワーキング、セキュリティ、オブザーバビリティを根本から見直しつつあります。

AWS EKS、Google GKE、Microsoft AKSの3大マネージドKubernetesがこぞってCiliumを採用し、CNCFではCiliumがGraduatedプロジェクトとして卒業しました。eBPFはもはや実験的な技術ではなく、クラウドネイティブインフラの事実上の標準となっています。

本記事の構成は以下の通りです：

1. eBPFの基礎——カーネルを安全にプログラムする「小さな仮想マシン」の仕組み
2. Cilium——eBPFで作るKubernetesネットワーキングの新標準
3. Tetragon——eBPFによるリアルタイム・ランタイムセキュリティ
4. Hubble——eBPFが可能にする「透過的な」ネットワーク可視化
5. 徹底比較——Sidecar vs Ambient vs eBPFサービスメッシュ
6. 実践ガイド——Cilium + Hubble + Tetragonを始める5ステップ
7. ケーススタディ——実際の導入事例と教訓

それでは、eBPFの基礎から始めましょう。

第1章：eBPFとは？——カーネルを安全にプログラムする「小さな仮想マシン」

1.1 eBPFの歴史と進化（3分でわかる）

eBPFの歴史は、思いのほか古く、1992年に遡ります。

1992年：cBPFの誕生

Linus TorvaldsがLinuxを作ったのと同じ年、Lawrence Berkeley LaboratoryのSteven McCanneとVan Jacobsonは、パケットキャプチャを効率化するためにBPF（Berkeley Packet Filter）を発明しました。その命令セットアーキテクチャ（ISA）はわずか14行でしたが、この「カーネル内で安全に小さなプログラムを実行する」という発想が、30年後のクラウドネイティブインフラを支える基盤技術へと進化します。

2014年：eBPFへの進化

GoogleのAlexei StarovoitovがeBPF（extended BPF）の最初のパッチをLinuxカーネルに投稿しました。cBPFの14行のISAを大幅に拡張し、64ビットレジスタ、マップ（データ構造）、より複雑なプログラムの実行を可能にしました。これが現在のeBPFの原型です。

2026年現在：クラウドネイティブインフラの中核技術へ

eBPFはパケットフィルタという起源を遥かに超え、ネットワーキング（Cilium）、セキュリティ監視（Tetragon）、オブザーバビリティ（Hubble、Pixie）、パフォーマンス分析（bpftrace、BCC）など、多様な分野で活用されています。eBPF FoundationはLinux Foundation配下の独立財団として活動し、Google、AWS、Microsoft、Meta、Netflix、Isovalent（現Cisco）などが共同でエコシステムを推進しています。

1.2 eBPFの仕組み

eBPFの最大の特徴は、ユーザー空間で書かれたプログラムを、カーネル空間で安全に実行できることです。しかし、カーネル空間で任意のコードが実行されてはシステムが危険に晒されます。eBPFは、厳格な安全性検証とネイティブコードコンパイルを組み合わせることで、この課題を解決しています。

以下のMermaid図は、eBPFプログラムがロードから実行に至るまでの流れを可視化したものです。

graph LR
    A[ユーザー空間<br/>BPFプログラム] -->|ロード| B[Verifier<br/>安全性検証]
    B -->|検証通過| C[JITコンパイラ<br/>ネイティブコード変換]
    C --> D[カーネル空間<br/>フックポイントで実行]
    D <-->|BPF Maps| E[ユーザー空間<br/>データ共有]
    
    style B fill:#f9f,stroke:#333,stroke-width:2px
    style C fill:#bbf,stroke:#333,stroke-width:2px
    style D fill:#bfb,stroke:#333,stroke-width:2px

処理の流れ：

1. プログラムのロード: ユーザー空間のアプリケーションが、C言語等で書かれたeBPFプログラム（バイトコード）をカーネルにロードします
2. Verifierによる安全性検証: カーネル内の検証器がプログラムを解析し、安全性を保証します
3. JITコンパイル: 検証を通過したバイトコードが、実行環境のCPUアーキテクチャ（x86_64、arm64、riscv64等）のネイティブマシンコードに変換されます
4. カーネル内で実行: ネイティブコードとしてカーネル空間の所定のフックポイント（XDP、TC、kprobe、tracepoint等）で実行されます
5. BPF Mapsによるデータ共有: eBPFプログラムとユーザー空間の間で、ハッシュマップやリングバッファを通じてデータをやり取りします

1.3 Verifier（検証器）の役割

VerifierはeBPFの安全性を支える最重要コンポーネントです。eBPFプログラムはカーネルモードでネイティブマシンコードとして実行されるため、もしバグがあればカーネルクラッシュや機密情報の漏洩につながります。Verifierはこれを未然に防ぎます。

Verifierが保証すること：

• プログラムが必ず終了すること: 無限ループや無限再帰を禁止します。Linux 5.3以降ではbounded loops（上限付きループ）が許可されましたが、それでも反復回数は静的に検証可能である必要があります
• メモリ安全性: 不正なメモリアクセス（未初期化ポインタの参照、範囲外アクセス等）を防止します
• カーネルの安全性: メモリ破壊、機密情報の漏洩、カーネルクラッシュを引き起こす操作をブロックします
• セキュリティモデルの維持: セキュリティポリシーに違反する操作を防止します

2段階の検証プロセス：

Verifierの検証は以下の2段階で実行されます。

また、プログラムの複雑度にも制限があります。Linux 5.2以降、eBPFプログラムは最大100万命令まで許可されています（それ以前は4K命令・128K複雑度）。これにより、十分に複雑な処理を記述しつつも、検証時間を現実的な範囲に収めています。

1.4 JITコンパイラとCO-RE

JITコンパイラ——ランタイムオーバーヘッドゼロの秘密

Verifierの検証を通過したeBPFバイトコードは、JIT（Just-In-Time）コンパイラによって、実行時のCPUアーキテクチャに最適化されたネイティブマシンコードに変換されます。

これが重要なのは、eBPFプログラムが「インタプリタで解釈実行される」のではなく、「ネイティブコードとして直接CPUで実行される」からです。つまり、カーネルにビルトインされた機能と同等のパフォーマンスで動作します。x86_64、arm64、riscv64など、主要なアーキテクチャすべてでJITコンパイラがサポートされています。

CO-RE——Compile Once, Run Everywhere

eBPFプログラムがカーネルの内部構造（構造体のフィールド配置など）に依存する場合、異なるカーネルバージョン間でプログラムが動かなくなる問題がありました。これを解決するのがCO-RE（Compile Once - Run Everywhere）です。

CO-REはBTF（BPF Type Format）というカーネルの型情報を活用し、コンパイル時に1つ作成したeBPFプログラムを、異なるカーネルバージョンで実行できるようにします。これにより、eBPFプログラムの配布と実行が劇的にシンプルになりました。今日では、CiliumやTetragonなどの主要なeBPFプロジェクトはすべてCO-REに対応しています。

BPF Maps——カーネルとユーザー空間の橋渡し

eBPFプログラムとユーザー空間の間でデータを共有するために、BPF Mapsと呼ばれるデータ構造が提供されています。ハッシュマップ、配列、リングバッファ、LRU（Least Recently Used）など、用途に応じた複数のタイプが存在します。CiliumはこのBPF Mapsを活用して、エンドポイント情報、ポリシールール、コネクション追跡状態などを管理しています。

1.5 eBPFが選ばれる3つの理由

eBPFがクラウドネイティブインフラの中核技術として急速に普及している理由は、以下の3点に集約されます。

1. 圧倒的なパフォーマンス

eBPFプログラムはカーネル空間で実行されるため、ユーザー空間へのコンテキストスイッチが発生しません。パケットがカーネルに入った瞬間に処理を開始でき、XDP（eXpress Data Path）フックを使えば、NIC（ネットワークインターフェースカード）のドライバレベルでパケットを処理することも可能です。JITコンパイルによりネイティブコードで実行されるため、カーネル組み込みの機能と同等のパフォーマンスを実現します。

2. 厳格な安全性

Verifierによる事前検証により、eBPFプログラムがカーネルをクラッシュさせたり、機密情報を漏洩させたりすることは原理的に防がれています。これは、カーネルモジュール（カーネル拡張の従来手法）がカーネルクラッシュのリスクを常に伴うのと対照的です。eBPFは「カーネルを拡張するが、カーネルを壊さない」という安全性を保証しています。

3. 柔軟性とポータビリティ

カーネルの再コンパイルや再起動なしで、実行時に機能を追加・変更できます。CO-REにより、異なるカーネルバージョン間でもポータブルなプログラムの配布が可能です。これにより、新しいネットワーキングロジックやセキュリティポリシーを、システムダウンタイムなしでデプロイできます。

第2章：Cilium——eBPFで作るKubernetesネットワーキングの新標準

2.1 Ciliumとは何か（30秒で理解）

Ciliumは、eBPFを活用したKubernetesのCNI（Container Network Interface）プラグインであり、ネットワーキング、セキュリティ、オブザーバビリティを統合的に提供するオープンソースプロジェクトです。

以下の事実が、Ciliumが現在のKubernetesネットワーキングにおける事実上の標準であることを物語っています：

• CNCF Graduatedプロジェクト（2023年卒業）——CNCFの最も成熟したプロジェクトの1つであることを示す
• 3大クラウドでのデフォルト採用——AWS EKS、Google GKE、Microsoft AKSのすべてがCiliumをデフォルトCNIとして採用（2025年末〜2026年）
• 主要採用企業——Google、AWS、Microsoft、Bell Canada、Datadog、Trip.com、Adobe、Capital Oneなどが本番環境で稼働
• Isovalent社（現Cisco）が主導——商用サポートとエンタープライズ機能を提供

Ciliumが従来のCNI（Calico、Flannel、Weave等）と根本的に異なるのは、データプレーンにeBPFを使用している点です。これにより、iptablesに依存せず、カーネルレベルでパケットのルーティング、ポリシー適用、ロードバランシングを実行します。

2.2 Ciliumのアーキテクチャ

Ciliumのアーキテクチャは、カーネル空間のeBPFデータプレーンと、ユーザー空間の管理コンポーネント、そしてKubernetes APIとの連携層で構成されます。

graph TB
    subgraph カーネル空間
        XDP[XDPフック<br/>最速パケット処理]
        TC_IN[TC ingress<br/>パケット分類]
        CT[Conntrack<br/>コネクション追跡]
        POLICY[Policy Engine<br/>ポリシー適用]
        TC_OUT[TC egress<br/>送信処理]
    end
    
    subgraph ユーザー空間
        AGENT[Cilium Agent<br/>DaemonSet]
        CLI[cilium-cli<br/>管理・監視]
        API[Cilium Operator<br/>クラスタ管理]
    end
    
    subgraph Kubernetes
        CRD[CiliumNetworkPolicy<br/>CiliumEnvoyConfig等]
        K8S[kube-apiserver]
    end
    
    XDP --> TC_IN --> CT --> POLICY --> TC_OUT
    AGENT -.->|eBPFプログラム<br/>ロード/更新| XDP
    AGENT -.-> TC_IN
    AGENT -.-> POLICY
    AGENT <--> CRD
    CRD <--> K8S
    CLI --> AGENT
    
    style XDP fill:#ff9,stroke:#333,stroke-width:2px
    style POLICY fill:#f9f,stroke:#333,stroke-width:2px

カーネル空間のコンポーネント：

• XDPフック: NICドライバーレベルでパケットを処理する最速のポイント。DDoS緩和や高速なパケットフィルタリングに使用
• TC（Traffic Control）ingress/egress: パケットの分類、ルーティング、ポリシー適用を実行
• Conntrack（コネクション追跡）: TCP/UDP接続の状態を追跡し、ステートフルなポリシー評価を可能に
• Policy Engine: ネットワークポリシーを評価し、パケットの許可・ドロップを決定

ユーザー空間のコンポーネント：

• Cilium Agent: 各ノードでDaemonSetとして稼働し、eBPFプログラムのロード・更新、エンドポイント管理、ポリシーの同期を行う
• Cilium Operator: クラスタ全体の管理タスク（IPAM、クラスタメッシュの管理など）を担当
• cilium-cli: コマンドラインツール。ステータス確認、トラブルシューティング、機能の有効化/無効化に使用

Kubernetesとの連携：

CiliumはCiliumNetworkPolicyやCiliumEnvoyConfigなどのCRD（Custom Resource Definition）を通じて、Kubernetesの宣言的APIモデルに統合されています。標準のKubernetes NetworkPolicyよりも高度なL7レベルのポリシーを表現できます。

2.3 kube-proxy代替——なぜiptablesを置き換えるのか

Ciliumの最も重要な機能の1つが、kube-proxyの完全代替です。これがなぜ重要なのか、技術的な理由を説明します。

iptablesのO(n)ルックアップ問題

従来のkube-proxyは、iptablesを使用してKubernetes Serviceの仮想IP（ClusterIP）をバックエンドのPodにルーティングします。iptablesのルールはリスト（チェーン）として構成されており、パケットのマッチングは先頭から順番に線形探索（O(n)）で行われます。

サービス数が増えるにつれてiptablesのチェーンは長くなり、パケットあたりの処理時間が線形に増加します。さらに悪いことに、エンドポイント（Pod）の追加・削除のたびにiptablesルール全体の再計算が発生します。200サービスを超えたあたりで、この更新処理に数秒かかるようになります。新しいPodが起動しても、トラフィックが流れるまでに遅延が生じるのです。

eBPFのO(1)ルックアップ

Ciliumは、iptablesの代わりにeBPFマップ（ハッシュマップ）を使用してサービスルーティングを実装します。マップのルックアップはO(1)の定数時間で完了するため、サービス数が増えてもパフォーマンスは劣化しません。さらに、エンドポイントの変更はマップのエントリを更新するだけで済み、ルール変更のオーバーヘッドはほぼゼロです。

実測値での比較

ベンチマークテストでも、この違いは明確に現れています。Ciliumの公式ベンチマークでは、従来のsidecar Istioと比較してp99レイテンシが30〜50%低減（高RPS時）することが報告されています。独立した検証でも、15〜25%のレイテンシ改善が確認されています。

2.4 アイデンティティベースのネットワークポリシー

Ciliumのもう一つの革新は、アイデンティティベースのセキュリティモデルです。

従来のIPベースポリシーの限界

標準のKubernetes NetworkPolicyは、IPアドレス（IPBlock）やCIDR範囲を指定してアクセス制御を行います。しかし、Kubernetes環境ではPodのIPアドレスは動的に変化します。Podが再起動されるたびに新しいIPが割り当てられ、スケールアウト/スケールインでIPは次々と変わります。IPアドレスに基づくポリシーは、この動的な環境で保守が困難になります。

Ciliumのアイデンティティモデル

Ciliumは、各Podのラベルからセキュリティアイデンティティ（Security Identity）を生成します。このアイデンティティは数値IDとしてエンコードされ、eBPFプログラム内でパケットの送信元・宛先のアイデンティティを検証するために使用されます。

つまり、「app=frontendというラベルを持つPodだけが、app=backendというラベルを持つPodのポート8080にアクセスできる」といった、意図を直接表現するポリシーが可能になります。PodのIPが変わっても、ラベルベースのアイデンティティは変わらないため、ポリシーの修正は不要です。

L3/L4/L7の階層的ポリシー適用

CiliumNetworkPolicy CRDを使用することで、レイヤーをまたぐ階層的なポリシーを宣言的に定義できます。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-zero-trust
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: /api/.*

この例では、以下の3層のポリシーを1つのリソースで表現しています：

1. L3: app=frontendのPodからの通信のみ許可
2. L4: TCPポート8080のみ許可
3. L7: HTTP GETメソッド、/api/パスのみ許可

標準のKubernetes NetworkPolicyではL3/L4までしか制御できません。CiliumはL7（HTTP、gRPC、Kafka等）のポリシー表現を可能にすることで、真のゼロトラストモデルを実現します。

2.5 サービスメッシュとしてのCilium

Ciliumは、単なるCNIプラグインの枠を超えて、サイドカーレスなサービスメッシュとしても機能します。これは、IstioやLinkerd2のような従来のサービスメッシュが各Podにプロキシを注入するアプローチとは対照的です。

サイドカーレス・アーキテクチャ

Ciliumのサービスメッシュ機能では、L7処理（HTTPルーティング、ロードバランシング、レートリミット等）をノード単位のEnvoy DaemonSetとして配置します。各Podにプロキシを注入するのではなく、ノードごとに1つのEnvoyインスタンスがL7トラフィックを処理します。

これにより、以下のメリットが得られます：

• Podあたりのメモリ消費ゼロ: Envoyはノード単位で稼働するため、Podにサイドカーが不要
• スケール時のリソース増大を抑制: Pod数が増えてもEnvoyのインスタンス数はノード数で一定
• 起動時間の短縮: サイドカーの注入・起動を待つ必要がない

mTLS——透明な暗号化

Ciliumは、WireGuardまたはIPsecを使用して、ノード間のトラフィックを透明に暗号化します。これはカーネルレベルで行われるため、アプリケーションは暗号化を意識する必要がありません。NIS2、SOC2、DPDPなどのコンプライアンス要件で求められる「全トラフィックの暗号化」を、パフォーマンスを犠牲にすることなく実現できます。

Gateway APIサポート

Cilium 1.16以降、Kubernetes Gateway APIをサポートしています。これにより、イングレストラフィックの管理、ルーティング、TLS終端を、Ciliumのデータプレーンを通じて統合的に行えます。Gateway APIはKubernetesの標準APIであるため、ベンダーロックインなしにイングレス管理が可能です。

従来のサービスメッシュとのパフォーマンス比較

大規模クラスター（数百〜数千Pod）になればなるほど、この差は決定的になります。1,000 Pod規模のクラスターでは、サイドカーEnvoyだけで数百GB〜1TB以上のメモリを消費しますが、Ciliumのノード単位アプローチなら、ノード数×100〜250MBで済みます。

次章では、Ciliumエコシステムのもう一つの重要コンポーネントであるTetragon——eBPFによるリアルタイム・ランタイムセキュリティについて解説します。

第3章：Tetragon — eBPFによるリアルタイム・ランタイムセキュリティ

3.1 Tetragonが解決する問題

コンテナランタイムセキュリティにおいて、従来のツールは「ユーザー空間エージェントがカーネルからイベントを受信し、ルールエンジンで評価して通知する」というアーキテクチャを採用していました。この方式には致命的な遅延があります。カーネルでイベントが発生してからユーザー空間のエージェントが処理し、判定を下すまでに数ミリ秒〜数十ミリ秒のラグが生じるのです。そのわずかな隙に、攻撃者はデータを外部送信し、プロセスを乗っ取ることができます。

Tetragonはこの問題を根本から解き直しました。ポリシーの評価と強制をカーネル内で完結させるのです。eBPFプログラムとしてカーネルにロードされたポリシーは、イベント発生と同時に判定を行い、必要に応じて即座にプロセスを強制終了させます。ユーザー空間との往復は発生しません。結果として、検出から応答までのレイテンシはミリ秒以下に短縮されます。

TetragonはCiliumエコシステムのセキュリティコンポーネントとして位置づけられ、Kubernetesのコンテキスト（Namespace、Pod、ラベル）とカーネルのイベントを統合的に扱うことができます。CNCF SandboxプロジェクトからIncubatingへの移行も進んでおり、コミュニティの信頼も深まっています。

3.2 Tetragonのアーキテクチャ

Tetragonの最大の特徴は、データプレーン（イベント検出・フィルタリング・強制）がすべてカーネル空間で完結する点です。以下のアーキテクチャ図にその全体像を示します。

graph TB
    subgraph カーネル空間
        HOOK[eBPFフック<br/>exec / syscall / network / file]
        FILTER[カーネル内フィルタ<br/>ポリシー評価]
        ENFORCE[リアルタイム強制<br/>kill / block / signal]
    end
    
    subgraph ユーザー空間
        TETRAGON[Tetragon Agent<br/>DaemonSet]
        POLICY_MGR[TracingPolicy CRD<br/>ポリシー管理]
        EVENTS[イベントログ<br/>JSON出力]
    end
    
    subgraph Kubernetes
        K8S_API[kube-apiserver]
    end
    
    HOOK --> FILTER
    FILTER -->|一致| ENFORCE
    FILTER -->|イベント送信| TETRAGON
    TETRAGON --> EVENTS
    TETRAGON <--> POLICY_MGR
    POLICY_MGR <--> K8S_API
    
    style FILTER fill:#f99,stroke:#333,stroke-width:2px
    style ENFORCE fill:#fcc,stroke:#333,stroke-width:2px

アーキテクチャの重要なポイントは以下の通りです。

• eBPFフック: プロセス実行（execve）、システムコール、ネットワーク接続、ファイルアクセスなど、セキュリティ上重要なカーネルイベントにフックします
• カーネル内フィルタ: TracingPolicy CRDで定義されたルールがeBPFプログラムとしてコンパイルされ、カーネル内で評価されます。ユーザー空間へのイベント転送は、ポリシーに一致した場合のみ発生します
• リアルタイム強制: ポリシー違反を検出した際、カーネル内から直接 SIGKILL シグナルを送るなどして、悪意のあるアクションを即座にブロックします
• ユーザー空間Agent: イベントログの収集、Kubernetes APIとの連携、ポリシーの動的ロード・アンロードを担いますが、セキュリティ判定の中核はカーネル内にあります

3.3 検出・ブロック可能なイベント

Tetragonは以下のカテゴリで、セキュリティ上重要なイベントを検出し、リアルタイムにブロックできます。

プロセス実行の監視・制御

コンテナ内で意図しないシェル（/bin/bash、/bin/sh）の起動を検出・ブロックします。攻撃者がRCE（リモートコード実行）の脆弱性を突いてコンテナに侵入した際、最初の足がかりとなるシェルの起動をミリ秒以下で阻止できます。

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-shell-in-container
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string"
      matchArgs:
        - index: 0
          operator: "Equal"
          values:
            - "/bin/bash"
            - "/bin/sh"
      matchActions:
        - action: Sigkill

このポリシーは execve システムコールをフックし、引数が /bin/bash または /bin/sh の場合、即座にプロセスを SIGKILL で終了させます。

権限昇格の検出

setuid、setgid、capset などのシステムコールを監視し、コンテナが権限を昇格させようとする試行を検出します。攻撃者がコンテナエスケープを狙って権限を奪う典型的なパターンをブロックできます。

ファイルアクセスの監視

機密ファイル（/etc/shadow、/etc/passwd、/proc/self/exe 等）への不正な読み書きを検出します。シークレットの窃取や、/proc 経由のホスト情報漏洩を防ぎます。

ネットワーク接続の監視・ブロック

不正な外部通信（C2サーバーへの接続、データ exfiltration）を検出・ブロックします。許可されたエンドポイント以外へのTCP接続をSIGKILLで遮断できます。DNSクエリの監視により、不審なドメインへの名前解決も追跡可能です。

3.4 Tetragon vs 従来のランタイムセキュリティツール

TetragonはFalcoやTraceeといった優れたツールと比較して、「検出」ではなく「強制（Enforcement）」に重点を置いている点が決定的に異なります。

重要な補足をしておきます。Falcoは優れたツールであり、CNCF Graduatedプロジェクトとして成熟したエコシステムを持ちます。「検出してアラートを出す」という用途では十分な価値があります。Tetragonの優位性が際立つのは、「ブロックが必要なシナリオ」、つまりゼロトラスト・ランタイム保護を本格的に実装する場合です。

実際の運用では、Tetragon（強制）とFalco（監視・アラート）を組み合わせる構成も有効です。Tetragonで致命的なアクションを即座にブロックしつつ、Falcoでより広範な疑わしい挙動をログに記録し、セキュリティチームに通知する、といった多層防御が可能です。

第4章：Hubble — eBPFが可能にする「透過的な」ネットワーク可視化

4.1 Hubbleとは何か

「マイクロサービス間の通信が見えない」——これはKubernetes運用者が最も頻繁に直面する課題の一つです。サービス間でタイムアウトが発生しているが、どのPod間の通信が失敗しているのか分からない。ネットワークポリシーを設定したが、意図した通りにトラフィックが制御されているのか確認しようがない。DNS解決が時々失敗するが、再現性がない。

Hubbleは、これらの問題を透過的に解決します。「透過的」とは、アプリケーションコードの変更が不要で、サイドカーの注入も不要で、パケットキャプチャのオーバーヘッドもないという意味です。CiliumのeBPFデータプレーンが処理するすべてのパケットから、自動的にフロー情報が抽出されます。

Hubbleは以下のレイヤーのフロー情報を取得できます。

• L3/L4: TCP/UDP接続、IPアドレス、ポート番号
• L7: HTTPリクエスト（メソッド、パス、ステータスコード）、DNSクエリ（ドメイン名、レスポンスコード）、Kafka通信

この情報はリアルタイムに観察できるだけでなく、Prometheusメトリクスとして時系列データとして蓄積し、Grafanaでダッシュボード化することも可能です。

4.2 Hubbleが見える世界

Hubbleを有効にすると、Kubernetesクラスター内のすべてのネットワークフローが可視化されます。以下の図は、Hubbleが観察する世界を概念的に示したものです。

graph LR
    subgraph Kubernetes Cluster
        A[Frontend Pod] -->|HTTP :8080| B[Backend Pod]
        B -->|TCP :5432| C[Database Pod]
        A -->|DNS query| D[CoreDNS Pod]
        B -.->|DROPPED by policy| E[External API]
    end
    
    HUBBLE[Hubble] -.->|observe all flows| A
    HUBBLE -.-> B
    HUBBLE -.-> C
    HUBBLE -.-> D
    HUBBLE -.->|DROPPED verdict| E
    
    UI[Hubble UI] -->|service map| HUBBLE
    PROM[Prometheus] -->|metrics| HUBBLE
    
    style HUBBLE fill:#9ff,stroke:#333,stroke-width:2px
    style E fill:#fcc,stroke:#f00

Hubbleの強力な点は、単にフローを観察できるだけでなく、ポリシーによってドロップされたパケット（DROPPED verdict）も記録することです。これにより、「なぜこのPodは通信できないのか？」というKubernetes運用のFAQを、コマンド一つで解決できます。

4.3 実際のフロー観察コマンド例

HubbleのCLI (hubble observe) は、フロー観察のための強力なフィルタリング機能を提供します。以下に実践的なコマンド例を示します。

# リアルタイムで全フローを観察
hubble observe

# ドロップされたパケットだけを表示（トラブルシューティングの最初の一歩）
hubble observe --verdict DROPPED

# 特定Pod間の通信をトレース
hubble observe --from-pod default/frontend --to-pod default/backend

# HTTP リクエストの監視（L7可視性）
hubble observe --protocol http

# DNSエラーの特定（rcode != 0 はエラーを意味する）
hubble observe --protocol dns -o json | \
  jq 'select(.flow.l7.dns.rcode != 0)'

# 特定ネームスペースのフローだけを表示
hubble observe --namespace production

# フローをJSON形式で出力（パイプライン処理用）
hubble observe -o json | jq '.flow'

--verdict DROPPED は特によく使います。ネットワークポリシーによって遮断された通信を即座に特定できるため、「デプロイしたPodにアクセスできない」という問い合わせの原因究定が数秒で終わります。

Hubble UIを使えば、これらのフロー情報がインタラクティブなサービス依存関係マップとして可視化されます。どのPodがどのPodと通信し、どの通信がポリシーでドロップされているかが、直感的なグラフィックで確認できます。

4.4 トラブルシューティングのワークフロー

Hubbleを使った典型的なトラブルシューティングの流れをまとめます。

ステップ1: Hubble UIでサービストポロジーを確認

まず全体像を把握します。Hubble UIのサービスマップを見て、意図した通りの通信パスが構築されているか、異常な孤立Podがないかを確認します。

ステップ2: hubble observe --verdict DROPPED でドロップを発見

hubble observe --verdict DROPPED --from-pod default/api-server

これで、APIサーバーPodからの通信でドロップされているパケットがないかを確認します。出力には、ドロップの原因（ポリシー名、ファイアウォールルール等）も含まれます。

ステップ3: どのネットワークポリシーが原因か特定

ドロップされたフローの情報から、該当するCiliumNetworkPolicyを特定します。Hubbleの出力にはポリシーの評価結果が含まれているため、「どのルールがこの通信を拒否したのか」が分かります。

ステップ4: ポリシーを修正 → 再確認

ポリシーを修正し、再度 hubble observe でフローが FORWARDED verdict に変わったことを確認します。このサイクルは秒単位で完了します。eBPFベースのため、ポリシー変更の反映も即座です。

4.5 Prometheus統合

Hubbleは以下のメトリクスをPrometheusにエクスポートし、時系列での監視とアラートを可能にします。

CiliumのHelmインストール時に --set hubble.metrics.enabled="{dns,drop,tcp,flow,icmp,httpV2}" を指定することで、これらのメトリクスが自動的に有効化されます。

Grafanaのダッシュボードでは、以下のような可視化が一般的です。

• フロー数の推移: 時間経過に伴うトラフィック量の変化
• ドロップ率: 全フローに対するドロップの割合（急増時はアラート）
• DNSエラー率: rcode別のDNS失敗状況
• HTTPステータス分布: 4xx/5xxエラーの割合
• サービス依存関係トポロジー: リアルタイムのサービスマップ

これらのダッシュボードにより、「何かがおかしい」から「どこで、何が、なぜ起きているのか」までを数クリックで追跡できるようになります。

第5章：徹底比較 — Sidecar vs Ambient vs eBPFサービスメッシュ

サービスメッシュのアーキテクチャは、2026年現在3つの選択肢に集約されています。従来のSidecarモデル、Istio Ambient Mesh、そしてeBPFベースのCilium Service Meshです。それぞれの特徴を徹底的に比較します。

5.1 比較表

以下の表は、4つの主要なサービスメッシュ実装を9つの基準で比較したものです。

この表から読み取れる重要なインサイトを補足します。

Sidecar Istioの strengthsとweakness：Envoyプロキシが提供するL7ポリシー表現力（JWT認証、OAuth2、レートリミット、ヘッダー操作等）は最も高いです。しかし、その代償として各Podに50-150MBのメモリオーバーヘッドが発生します。200のマイクロサービスを稼働させるクラスターでは、サイドカーだけで合計10-30GBのメモリを消費することになります。

Ambient Meshの バランス：L4（mTLS、アイデンティティベース認証）をノード単位のztunnel（Rust実装）で処理し、L7が必要な場合のみWaypoint Proxy（Envoy）をオプトインで配置します。約70-85%のトラフィックはL4で十分という前提に基づく設計で、無駄のない構成を実現しています。

Cilium eBPFの最大優位性：レイテンシとCPUオーバーヘッドの最小化です。eBPFプログラムはカーネル空間で実行されるため、プロキシを経由するホップが追加されません。iptablesへの依存もなく、ルールの動的更新もほぼゼロコストで行えます。

5.2 パフォーマンスベンチマーク実測値

具体的な数字で比較してみましょう。

レイテンシ比較（p99、高RPS時）

Ciliumの公式ベンチマークによれば、Cilium eBPFサービスメッシュは従来のSidecar Istioと比較してp99レイテンシを30-50%削減しています。独立した検証（CNCF / 学術ベンチマーク）でも、15-25%のレイテンシ改善が確認されており、公式値が過大評価ではないことが裏付けられています。

iptablesスケール問題の実態

これは「遅い」というレベルではなく、運用上の重大な問題です。サービス数が200を超えると、iptablesチェーンの更新に数秒かかるようになります。新しいServiceリソースを作成してからトラフィックが到達し始めるまでに遅延が生じ、ローリングアップデート中のトラフィックの損失につながります。

Cilium（kube-proxy代替モード）では、eBPFマップベースのO(1)ルックアップにより、ルール変更時のオーバーヘッドがほぼゼロです。サービス数が1,000を超えても、ルールの更新はミリ秒単位で完了します。

メモリ消費の具体例

200のマイクロサービスを実行するクラスターでの比較：

※数値は環境により変動しますが、オーダーの違いは明確です。Sidecarモデルのメモリ消費がPod数に比例するのに対し、AmbientとeBPFはノード数に比例します。

5.3 どのアーキテクチャを選ぶべきか（意思決定フロー）

「どれがベストか」という正解はありません。要件によって最適な選択は異なります。以下の意思決定フローで、あなたの状況に合ったアーキテクチャを特定してください。

flowchart TD
    A[サービスメッシュ選択] --> B{L7ポリシーは必要?}
    B -->|いいえ| C{最大レイテンシ削減が最優先?}
    B -->|はい| D{Envoyのフル機能が必要?}
    C -->|はい| E[Cilium eBPF Mesh<br/>最高のパフォーマンス]
    C -->|いいえ| F[Ambient ztunnelのみ<br/>シンプルなmTLS]
    D -->|はい| G{マルチクラスタ要件は?}
    D -->|いいえ| H[Ambient + Waypoint<br/>L7は必要な部分だけ]
    G -->|高度| I[Sidecar Istio<br/>成熟したマルチクラスタ]
    G -->|標準的| H
    
    style E fill:#bfb,stroke:#333,stroke-width:2px
    style F fill:#bbf,stroke:#333,stroke-width:2px
    style H fill:#bbf,stroke:#333,stroke-width:2px
    style I fill:#fbb,stroke:#333,stroke-width:2px

このフローの実践的な解釈を補足します。

Cilium eBPF Meshを選ぶべきケース：

• レイテンシへの感応度が極めて高い（金融取引、ゲーム、リアルタイムAPI）
• iptablesルールのスケール問題に直面している（200サービス超）
• 既にCiliumをCNIとして使用しており、追加のサイドカーなしでmTLSを実現したい
• L3/L4レベルのアイデンティティベースポリシーで十分

Ambient Meshを選ぶべきケース：

• Istioの豊富なエコ機能（トラフィックシフト、カナリアリリース、回路遮断等）を利用したい
• L7ポリシーは一部のトラフィックでのみ必要
• 段階的なSidecarからの移行を計画している
• mTLSを全トラフィックに適用しつつ、リソースを節約したい

Sidecar Istioを選ぶべきケース：

• 高度なマルチクラスタメッシュ（複数クラスタ間の統合トラフィック管理）が必須
• Envoyのフル機能（Luaスクリプト、WASMフィルター、複雑なトラフィックシフト）を多用している
• 既にIstioエコシステムに深く投資しており、移行コストが見合わない
• L7での極めて複雑なポリシー表現（JWT、OAuth2、ヘッダーベースルーティングの組み合わせ等）が必要

ハイブリッド構成という選択肢：2026年では、Cilium（ネットワーキング + L3/L4ポリシー + mTLS）とIstio Ambient（L7ポリシーが必要なサービスのみWaypointを配置）を組み合わせる構成も一般的になっています。両者は排他ではなく、補完的なのです。Ciliumでネットワークの土台を築き、その上で必要な部分だけIstioを重ねる——これが「ベストな全て取り」の実践的なアプローチです。

第6章：実践ガイド — Cilium + Hubble + Tetragonを始める5ステップ

ここまでeBPFの基礎からCilium・Tetragon・Hubbleのアーキテクチャ、そしてサービスメッシュ比較までを見てきました。本章では、実際に手を動かしてCilium + Hubble + Tetragonの三位一体を構築する手順を5つのステップで解説します。

ステップ1：前提条件の確認

導入を始める前に、環境が以下の要件を満たしていることを確認してください。

カーネルバージョンは以下のコマンドで確認できます。

# ノードのカーネルバージョン確認
kubectl get nodes -o wide | awk '{print $1, $3}'

# BTFの有効化確認（ファイルが存在すれば有効）
ls -la /sys/kernel/btf/vmlinux

⚠️ 注意: カーネルバージョンの確認を省略すると、一部機能が動作しないトラブルに直面します。特にTetragonの高度なポリシー機能には5.10以上が必要です。第7章の失敗パターンでも詳しく扱います。

ステップ2：Ciliumのインストール（Helm）

前提条件を確認したら、Helmを使ってCiliumをインストールします。以下の設定では、kube-proxy代替・Hubble有効化・メトリクス出力をすべて有効にしています。

# CiliumのHelmリポジトリを追加
helm repo add cilium https://helm.cilium.io/
helm repo update

# Cilium + Hubble をインストール
helm install cilium cilium/cilium --version 1.19.4 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=API_SERVER_IP \
  --set k8sServicePort=6443 \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.metrics.enabled="{dns,drop,tcp,flow,icmp,httpV2}"

各パラメーターの意味:

既存のkube-proxyが稼働している環境では、kubeProxyReplacement=trueを設定すると、Ciliumが段階的にkube-proxyのルールを引き継ぎます。本番環境では、まずfalseで導入し、検証後にtrueに切り替える段階的アプローチも推奨されます。

ステップ3：インストールの検証

インストールが完了したら、CiliumとHubbleが正しく動作していることを確認します。

# Ciliumのステータス確認（全PodがRunning、全ノードがOKであることを確認）
cilium status

# Hubbleの接続確認
hubble status

# ノード一覧と接続状態の確認
cilium node list

# Ciliumの動作ヘルスチェック（接続性・ポリシー・DNS等を総合検証）
cilium connectivity test

cilium statusで以下のように表示されれば正常です。

    /¯¯\
 /¯¯\__/¯¯\    Cilium:             3 errors, 0 warnings
 \__/¯¯\__/    Operator:           1 errors, 0 warnings
 /¯¯\__/¯¯\    Hubble Relay:       1 errors, 0 warnings
 \__/¯¯\__/    ClusterMesh:        disabled
    \__/

DaemonSet         cilium             Desired: 3, Ready: 3/3, Available: 3/3
Deployment        cilium-operator    Desired: 2, Ready: 2/2, Available: 2/2
Deployment        hubble-relay       Desired: 1, Ready: 1/1, Available: 1/1
Containers:       cilium             Running: 3
                  cilium-operator    Running: 2
                  hubble-relay       Running: 1
Cluster Pods:     12/12 managed by Cilium
Helm chart version: 1.19.4

cilium connectivity testは、Pod間通信・DNS解決・ネットワークポリシー等を自動検証する包括的なテストです。すべてのテストがパスすれば、データプレーンは正常に機能しています。

ステップ4：ネットワークポリシーの適用

Ciliumが正常に動作することを確認したら、ゼロトラストの第一歩としてアイデンティティベースのネットワークポリシーを適用します。

まず、デフォルト拒否（default-deny）のポリシーを適用し、すべての通信を一度ブロックします。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

次に、必要な通信のみを許可するCiliumNetworkPolicyを定義します。以下は、frontend Podからのみbackend PodへのHTTP通信を許可する例です。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-zero-trust
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP

CiliumNetworkPolicyは、Kubernetes標準のNetworkPolicyよりも表現力が高く、L7（HTTPパス・HTTPメソッド）レベルの制御も可能です。以下は、L7ポリシーの例です。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/.*"

ポリシー適用後は、Hubbleで意図通り通信が許可・ドロップされているかを確認します。

# ドロップされたパケットを確認（ポリシーでブロックされた通信）
hubble observe --verdict DROPPED

# 特定Podの通信状況を確認
hubble observe --from-pod default/frontend --to-pod default/backend

ステップ5：Tetragonによるランタイム保護

ネットワークポリシーで通信の制御ができたら、次はTetragonでランタイムセキュリティを強化します。TetragonはTracingPolicy CRDを通じて、カーネルレベルでのリアルタイムなセキュリティポリシーを定義します。

まずTetragonをインストールします。

# TetragonのHelmインストール
helm install tetragon cilium/tetragon -n kube-system

次に、コンテナ内でのシェル起動をブロックするポリシーを適用します。これは、攻撃者がコンテナに侵入した後にシェルを起動する手法を防ぐ強力な対策です。

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-shell-in-container
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string"
      matchArgs:
        - index: 0
          operator: "Equal"
          values:
            - "/bin/bash"
            - "/bin/sh"
      matchActions:
        - action: Sigkill

このポリシーは、コンテナ内で/bin/bashや/bin/shの実行が試みられた瞬間に、カーネルレベルでSigkill（プロセス強制終了）を送信します。レイテンシは1ミリ秒未満です。

さらに、機密ファイルへの不正アクセスを検出するポリシーも追加できます。

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-shadow-read
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: "file"
        - index: 1
          type: "int"
      matchArgs:
        - index: 0
          operator: "Prefix"
          values:
            - "/etc/shadow"
            - "/etc/passwd"
      matchActions:
        - action: Post

Tetragonのイベントは以下のコマンドでリアルタイムに確認できます。

# Tetragonのセキュリティイベントをリアルタイム監視
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -f

# tetra CLIによるイベント確認（整形された形式）
tetra getevents -o compact

導入後チェックリスト

Cilium + Hubble + Tetragonの導入が完了したら、以下のチェックリストで確認を行ってください。

• [ ] Ciliumステータス: cilium statusで全PodがRunning、エラー・ワーニングなし
• [ ] 接続性テスト: cilium connectivity testが全項目パス
• [ ] mTLS有効化: 全Pod間通信が暗号化されているか確認（cilium encryption status）
• [ ] Hubble UI: サービストポロジーマップが正しく表示されるか
• [ ] ネットワークポリシー: hubble observe --verdict DROPPEDで意図したドロップが確認できるか
• [ ] Tetragonイベント: テスト用のシェル起動等でセキュリティイベントが検出されるか
• [ ] Prometheusメトリクス: Hubbleメトリクス（dns/drop/tcp/flow/http）がエクスポートされているか
• [ ] Grafanaダッシュボード: Hubbleメトリクスの可視化ダッシュボードが構築されているか
• [ ] DNS解決: CoreDNSとの連携が正常か（hubble observe --protocol dnsで確認）
• [ ] パフォーマンス: 導入前後でレイテンシ・スループットを比較し、劣化がないか

第7章：ケーススタディ — 実際の導入事例と教訓

eBPFベースのインフラは、すでに世界中の大規模環境で実証されています。本章では、実際の導入事例とそこから得られた教訓を解説します。

7.1 ケース：大手Eコマースプラットフォーム（推定18,000 Pod規模）

背景: アジア圏の大手Eコマースプラットフォームでは、ピーク時のトラフィック増大に伴いKubernetesクラスターが18,000 Pod規模に拡大していました。

課題:

• Sidecar Envoyによるメモリ消費が深刻（推定1〜2TBのメモリがプロキシだけで占有される）
• iptablesルールの更新に数秒かかり、サービスデプロイのボトルネック化
• 200サービスを超えたあたりからkube-proxyのパフォーマンスが著しく劣化

解決策: Ciliumへの全面移行を実施。具体的には以下の変更を行いました。

1. kube-proxyの代替: CiliumのeBPFデータプレーンでiptablesルールを完全置き換え
2. サイドカーレス化: EnvoyをPod単位からノード単位のDaemonSet構成に変更
3. Hubbleによる可視化: トラフィックフローの監視を標準化

結果:

• メモリ使用量50%削減: プロキシ関連のメモリ消費が大幅に改善
• ネットワーク遅延の改善: p99レイテンシが30〜50%低減（sidecar Istio比）
• デプロイ速度の向上: iptables更新遅延が解消し、サービスデプロイのボトルネックが解消

教訓: 大規模クラスターほど、eBPFによるカーネルレベルの最適化の恩恵が大きくなります。特に200サービスを超える環境では、iptablesのO(n)ルックアップが致命的なボトルネックになります。

7.2 ケース：金融機関でのゼロトラスト実装

背景: ヨーロッパの金融機関では、NIS2指令やSOC2コンプライアンス要件により、全トラフィックの暗号化・監査・ランタイム保護が義務付けられていました。

課題:

• コンプライアンス要件（SOC2、NIS2）による全トラフィックの暗号化と監査ログが必要
• 従来のsidecar型サービスメッシュでは、レイテンシ增加が取引システムに影響
• ランタイム脅威検知の仕組みがなく、コンテナ侵入後の検出・ブロックができない

解決策: Cilium + Tetragon + Hubbleの三位一体構成を採用。

結果:

• コンプライアンス要件をすべて満たしながら、従来のサービスメッシュ比でレイテンシを改善
• Tetragonによるランタイム保護で、コンテナ内の不正プロセス実行をミリ秒以下でブロック
• Hubbleのフローログを監査証跡としてSIEM（Security Information and Event Management）に統合

教訓: セキュリティ強化とパフォーマンス改善はトレードオフであるという従来の常識を、eBPFは覆します。ゼロトラストの実現において、カーネルレベルでの処理は圧倒的な優位性を持ちます。

7.3 クラウドプロバイダーの採用実績

2025年末〜2026年にかけて、三大パブリッククラウドプロバイダーすべてがCiliumをデフォルトまたは推奨CNIとして採用しました。これはeBPFがクラウドネイティブネットワーキングの事実上の標準となった決定的な証拠です。

Google GKEは最も早くCiliumを採用し、「Dataplane V2」として提供しています。これにより、GKEユーザーは追加設定なしでeBPFベースのネットワーキング・セキュリティを利用できます。

AWS EKSでは、2025年末からCiliumベースのデータプレーンがデフォルトオプションとして利用可能になりました。従来のVPC CNIと比較して、ネットワークポリシーの表現力とパフォーマンスが大幅に向上しています。

Microsoft AKSでは「Azure CNI Powered by Cilium」として、AzureのネットワーキングスタックとCiliumのeBPFデータプレーンを統合したソリューションを提供しています。

採用企業の規模感: Google、AWS、Microsoftに加え、Bell Canada、Datadog、Trip.com、Adobe、Capital Oneなどが本番環境でCiliumを採用しています。これらの実績は、eBPFエコシステムがエンタープライズグレードの信頼性に達していることを示しています。

7.4 失敗パターンと教訓

eBPFエコシステムの導入は強力ですが、いくつかの典型的な失敗パターンがあります。事前に知っておくことで、これらの落とし穴を避けることができます。

❌ 失敗パターン1：カーネルバージョン確認せずに導入

事例: 某企業がオンプレミスのKubernetesクラスターにCiliumを導入したところ、Tetragonのポリシー機能の一部が動作しない問題が発生。原因は、ノードのカーネルバージョンが5.4で、Tetragonの高度な機能（bpf_tracingプログラム等）には5.10以上が必要だったこと。

教訓: 導入前にすべてのノードのカーネルバージョンを確認し、使用したい機能の要件を満たしているかを検証してください。特にTetragonの全機能を利用するには5.10以上、最新のeBPF機能をすべて利用するには5.15以上が望ましいです。

❌ 失敗パターン2：いきなり全クラスタでkube-proxy代替

事例: 某スタートアップが本番クラスタでkubeProxyReplacement=trueをいきなり有効化したところ、一部のレガシーアプリケーションで接続の切断が発生。kube-proxyのセッショントラッキングに依存するアプリケーションが移行に気づかずトラブルに。

教訓: kube-proxy代替は段階的に行ってください。まずはkubeProxyReplacement=false（またはdisabled）でCiliumを導入し、接続性とパフォーマンスを検証してから、新しいクラスタまたは非本番クラスタから順次trueに切り替えることを推奨します。

❌ 失敗パターン3：L7ポリシーを全通信に適用

事例: 某企業がセキュリティ強化のため、すべての通信にL7 HTTPポリシーを適用したところ、高トラフィック環境でCPU使用率が上昇し、レイテンシが10〜15%悪化。L7ポリシーはEnvoy経由の処理が必要なため、無差別な適用はコストが高い。

教訓: L7ポリシーは必要な通信のみに適用してください。大部分の通信はL3/L4ポリシーで十分です。外部APIとの通信や機密性の高いエンドポイントに対してのみ、L7ポリシーを戦略的に適用することで、セキュリティとパフォーマンスのバランスを最適化できます。

失敗パターンまとめ

よくある質問（FAQ）

Q1：eBPFとは何ですか？

A: eBPF（extended Berkeley Packet Filter）は、Linuxカーネルのコードを変更することなく、カーネル空間で安全にプログラムを実行できる技術です。Verifier（検証器）による厳格な安全性検証と、JITコンパイラによるネイティブコード実行により、ランタイムオーバーヘッドなしでネットワーキング、セキュリティ、オブザーバビリティの機能を実装できます。1992年のcBPFから始まり、2014年のeBPFパッチを経て、2026年現在ではクラウドネイティブインフラの中核技術となっています。

Q2：Ciliumはkube-proxyを完全に置き換えられますか？

A: はい。CiliumのeBPFベースのデータプレーンは、kube-proxyのiptablesルールをeBPFマップとプログラムで完全に置き換えます。これにより、O(1)のルックアップ性能と、ルール変更時のほぼゼロのオーバーヘッドを実現します。200サービスを超える大規模クラスターでは、iptables更新に数秒かかるのに対し、Ciliumはほぼ瞬時に反映されます。ただし、本番環境では段階的な移行を強く推奨します。

Q3：CiliumとIstioはどちらを使うべきですか？

A: 用途によります。L3〜L4のアイデンティティベースポリシーと基本的なmTLSが主な要件ならCiliumが適しています。高度なL7ポリシー（JWT検証、ヘッダー操作、レートリミット等）や複雑なマルチクラスタメッシュが必要なら、IstioまたはCiliumのL7機能（Envoy DaemonSet経由）を検討してください。2026年では、CiliumのデータプレーンとIstioのコントロールプレーンを組み合わせるハイブリッド構成も一般的です。意思決定のポイントは、レイテンシ感度・L7要件の複雑さ・運用リソースの3軸で判断することです。

Q4：Tetragonは既存のセキュリティツール（Falco等）とどう違いますか？

A: 最大の違いは「カーネル内でのポリシー評価と強制」です。TetragonはeBPFプログラムとしてカーネル内でフィルタリングとポリシー適用を行うため、検出から応答までのレイテンシが1ミリ秒未満です。一方、Falcoは検出後にユーザー空間でルール評価を行うため、応答までに数ミリ秒〜数十ミリ秒の遅延があります。また、Tetragonはブロック（Sigkill等の強制アクション）が可能ですが、Falcoは通知ベースの検出のみです。KubernetesネイティブなCRDによるポリシー管理もTetragonの強みです。

Q5：Hubbleを使うためにアプリケーションを変更する必要はありますか？

A: いいえ、一切不要です。HubbleはCiliumのeBPFデータプレーンから自動的にフロー情報を取得するため、アプリケーションコードの変更もサイドカーの追加も不要です。CiliumをHubble有効化オプションでインストールするだけで、L3からL7までのネットワークフロー可視化が即座に利用できます。パケットキャプチャツールの導入や、アプリケーションへの計装も不要です。

Q6：eBPFの利用に必要なLinuxカーネルバージョンは？

A: 最低でもLinux Kernel 5.4以上を推奨します。ただし、使用する機能によって要件は異なります。

三大クラウド（GKE・EKS・AKS）の最新ノードイメージでは、5.10以上のカーネルが標準提供されているため、特別なカスタマイズをしていなければ問題なく利用できます。

Q7：eBPFはWindows環境でも使えますか？

A: Windows eBPFプロジェクトが進行中で、一部のシナリオでは利用可能です。ただし、本番環境のKubernetesクラスターではLinuxノードでの使用が主流であり、Cilium・Tetragon・HubbleもLinux環境向けに最適化されています。Windowsコンテナを含むハイブリッドクラスターでは、LinuxノードでCiliumを稼働させつつ、Windowsノードは別のCNIで処理する構成が一般的です。

Q8：Ciliumの本番導入で注意すべき点は？

A: 以下の5点に注意してください。

1. カーネルバージョンの事前確認 — 全ノードが5.4以上（推奨5.10以上）であることを検証
2. 段階的なロールアウト — まず1クラスタ（非本番）で検証し、問題なければ本番へ展開
3. kube-proxy代替は慎重に — 完全置き換え前に、テスト環境でcilium connectivity testを必ず実行
4. L7ポリシーは必要な通信のみに適用 — 全通信へのL7適用はCPU・レイテンシに影響するため、機密通信に限定
5. Hubbleメトリクスの容量計画 — メトリクス保持期間とストレージ要件を事前に計画（Prometheusのretention設定等）

まとめ — 今日から始める3つのアクション

この記事では、eBPFがクラウドネイティブインフラをどう変革するかを、Cilium・Tetragon・Hubbleの三位体構成で解説してきました。eBPFはもはや「将来の技術」ではなく、三大クラウドすべてが採用する「今の標準」です。

理論を理解したら、次は行動です。今日から始められる3つのアクションを紹介します。

アクション1：現状の可視化

あなたのクラスターで以下のコマンドを実行し、現在のスケールを確認してください。

# クラスター内のサービス数を確認
kubectl get svc --all-namespaces | wc -l

# Pod数とノード数の確認
kubectl get nodes | wc -l
kubectl get pods --all-namespaces | wc -l

サービス数が200を超えているなら、iptablesの限界が近づいています。これはCiliumへの移行を検討すべき明確なシグナルです。

アクション2：テスト環境でCilium + Hubbleを試す

kind（Kubernetes in Docker）やminikubeを使えば、ローカル環境ですぐにCilium + Hubbleを体験できます。

# kindクラスタを作成（kube-proxy無効化）
cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
networking:
  disableDefaultCNI: true
  kubeProxyMode: none
EOF

# Ciliumをインストール
cilium install --version 1.19.4

# Hubbleを有効化
cilium hubble enable

# フロー観察を開始
hubble observe

# Hubble UIへのポートフォワード
cilium hubble ui
# → http://localhost:12000 でサービスマップを確認

ローカル環境で5分もあれば、eBPFベースのネットワーキングと可視化を体験できます。

アクション3：ゼロトラストの第一歩

1つのネームスペースにdefault-denyポリシーを適用し、Hubbleでフローを観察してください。これがゼロトラスト・ネットワーキングの具体的な第一歩です。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: my-app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

# ポリシー適用後にドロップされた通信を確認
hubble observe --namespace my-app --verdict DROPPED

# 必要な通信だけを許可するポリシーを追加
kubectl apply -f - <<EOF
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: my-app
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
EOF

# 許可された通信が流れることを確認
hubble observe --namespace my-app --verdict FORWARDED

eBPFは、カーネルというインフラの最深部からクラウドネイティブの未来を塗り替えています。 Cilium・Tetragon・Hubbleという強力なツールが揃った今こそ、ゼロトラスト・オブザーバビリティの新世代に踏み出す最良のタイミングです。まずは小さな一歩から——アクション1のkubectl get svc | wc -lを今すぐ実行してみてください。

参考文献・出典

eBPF基礎

1. eBPF Docs - Verifier: https://docs.ebpf.io/linux/concepts/verifier/
2. Linux Kernel Documentation - eBPF verifier: https://docs.kernel.org/bpf/verifier.html
3. eBPF完全ガイド（youngju.dev）: https://www.youngju.dev/blog/culture/2026-04-15-ebpf-verifier-jit-co-re-bpf-maps-xdp-tracing-deep-dive-guide-2025.ja
4. Pawnyable - 検証器とJIT: https://pawnyable.cafe/linux-kernel/LK06/verifier.html

Cilium

5. Cilium公式: https://cilium.io/
6. Cilium GitHub: https://github.com/cilium/cilium
7. Ciliumデータパスアーキテクチャ: https://www.youngju.dev/blog/cilium/2026-06-13-cilium-ebpf-datapath-architecture-2026.ja
8. Cilium Deep Dive: https://blog.rommelporras.com/cilium-ebpf/
9. Cilium 2026ガイド: https://app-tatsujin.com/cilium-ebpf-2026-guide/
10. Cilium Adopters: https://cilium.io/adopters/

Tetragon

11. Tetragon公式: https://tetragon.io/
12. Tetragon Overview: https://tetragon.io/docs/overview/
13. Tetragon GitHub: https://github.com/cilium/tetragon
14. Tetragon 2026: https://www.programming-helper.com/tech/tetragon-2026-cilium-ebpf-runtime-security-enforcement

Hubble

15. Hubble GitHub: https://github.com/cilium/hubble
16. Hubble Observability Guide: https://oneuptime.com/blog/post/2026-02-09-cilium-hubble-network-observability/view
17. eBPF K8s観測性: https://www.youngju.dev/blog/observability/2026-03-03-ebpf-kubernetes-observability.ja

比較・ベンチマーク

18. Sidecar vs eBPF ADR 2026: https://iotdigitaltwinplm.com/ebpf-vs-sidecar-service-mesh-adr-2026/
19. Cilium vs Istio性能比較: https://app-tatsujin.com/cilium-vs-istio-service-mesh-performance-comparison/
20. Cilium vs kube-proxy: https://app-tatsujin.com/cilium-vs-kube-proxy-kubernetes-network-performance-comparison/
21. Service Mesh完全解剖: https://www.youngju.dev/blog/culture/2026-04-15-service-mesh-envoy-istio-linkerd-cilium-ebpf-ambient-xds-mtls-deep-dive-guide-2025.ja

エコシステム・動向

22. eBPF Foundation: https://ebpf.foundation/announcements/
23. eBPF Company Landscape: https://ebpf.foundation/unveiling-the-ebpf-company-landscape-mapping-the-businesses-powering-the-ebpf-ecosystem/
24. eBPF in 2026: https://devstarsj.github.io/2026/06/29/ebpf-cloud-native-observability-networking-2026/
25. EKS デフォルトCNI: https://www.yusui-wp.com/blog/2026/05/22/0707/
26. EKS Cilium比較: https://www.techleague.io/ja/blog/aws/aws-eks-networking-vpc-cni-vs-cilium/
27. Cilium Production 2026: https://blog.rajpoot.dev/posts/devops/cilium-ebpf-service-mesh-2026/
28. CNCF Landscape: https://landscape.cncf.io/
29. eBPF Kubernetes観測性: https://www.youngju.dev/blog/observability/2026-03-03-ebpf-kubernetes-observability.ja
30. eBPF Networking K8s: https://k8s.info/docs/expert/networking-ebpf