OS

eBPFが変えるLinuxカーネルの常識——雲の上のコンテナ基盤を支える「プログラマブルカーネル」入門

open claw

• 7 min read
Share

はじめに——「カーネルを変えずにカーネルを変える」とは？ eBPFという発想

Linuxカーネルに手を入れたい——。システムを深く観測したい、パケット処理を高速化したい、不審なプロセスを即座に止めたい。そんな要求は、クラウドネイティブ基盤を運用するSREやプラットフォームエンジニアなら日常的に直面します。ところが伝統的な解決策はどれも痛みを伴うものでした。カーネルにパッチを当てて再コンパイルする？ メンテナの承認を待つのに数年かかることもあります。カーネルモジュールをロードする？ 完全なカーネル権限で動くため、バグひとつでカーネルパニック＝ホスト全体のダウンにつながります。

このジレンマに答えたのがeBPF（extended Berkeley Packet Filter）です。カーネルを再コンパイルせず、危険なカーネルモジュールも使わずに、Verifierで検証された小さなプログラムをカーネル内で実行する——「カーネルを変えずにカーネルを変える」という発想です（Zenn、ebpf.io）。起源は1992年の古典的BPF（cBPF）ですが、2014年にAlexei Starovoitovが投入したeBPFパッチによって、64ビットレジスタとJIT、マップを備えたモダンな仮想マシンへと進化しました（youngju.dev）。

そして2026年現在、eBPFはもはや実験技術ではありません。eBPFベースのCNIであるCiliumは、AKS Automaticでは「Azure CNI powered by Cilium」が既定のデータプレーンになっており、GKEやEKSでもCiliumを利用する構成が選択肢として提供されるなど、大手クラウドでの採用が広がっています（2026年8月時点。出典: Microsoft Azure公式、GKEネットワーク アーキテクチャ、yusui-wp）。Kubernetesを運用していれば、eBPFベースの基盤に触れる機会は増え続けています。

仕組み——Verifier、JIT、マップで動く「カーネル内VM」

eBPFの処理フローを図にすると次のとおりです。

flowchart LR
    subgraph UserSpace["ユーザー空間"]
        A["eBPFプログラム<br/>(C/Rust/bpftrace)"] --> B["clang/LLVMで<br/>eBPFバイトコードにコンパイル"]
        F["ユーザー空間プロセス<br/>(Cilium / Hubble / Tetragon等)"]
    end
    B -->|"bpf()システムコールでロード"| C
    subgraph KernelSpace["カーネル空間"]
        C["eBPF Verifier<br/>全実行パスの静的検証"] -->|"検証通過のみ"| D["JITコンパイラ<br/>ネイティブコード化"]
        D --> E["カーネルフック<br/>XDP / syscall / kprobe / tracepoint"]
        G["eBPFマップ"]
    end
    E <-->|"双方向データ共有"| G
    G <--> F
    E -->|"イベント送信"| F

鍵となるのがVerifierです。ロード時にバイトコードをグラフ化し、すべての実行パスを解析。未初期化メモリの読み取り、境界外アクセス、無限ループを静的に検出し、危険なプログラムのロードをあらかじめ拒否する、クラッシュやフリーズを防ぐ設計上の安全機構です（カーネル公式ドキュメント、youngju.dev）。ただしVerifierを通ったからといって無リスクではありません。Verifier自身やJIT・カーネル実装の不具合、フック・ヘルパーの組み合わせによってリスクは残り得るため、カーネルモジュールより「制約が強くリスクを低減する設計」と理解するのが正確です。通過したプログラムはJITコンパイラでネイティブマシンコードに変換され、小さなオーバーヘッドで実行されます。さらにeBPFマップがカーネルとユーザー空間の双方向データ共有を支え、CO-RE（Compile Once, Run Everywhere）がBTFによるカーネル差異の吸収で、対応ツールとBTF対応カーネルの間では再コンパイルなしの配布を可能にします（libbpf CO-REドキュメント）。このポータビリティがエコシステム普及の前提になっています。

主要ツール比較——Cilium / Tetragon / Falco / Pixie / bpftraceはどう違う？

「eBPFで何ができるか」を知るには、実際のツールを見るのがいちばんの近道です。eBPFそのものは土台であり、私たちが普段触るのはその上に構築されたOSSプロダクト群です。代表的なツールを比較すると次のようになります（CNCFステータスは2026年8月時点）。

ツール 主用途 eBPF利用方式 対象レイヤ CNCFステータス（2026年8月時点） 向いている場面
Cilium K8sネットワーキング（CNI）・サービスメッシュ eBPFでパケット処理＋Envoy（L7） L3〜L7 Graduated iptables置き換え、サイドカーレスメッシュ、Hubble可視化
Tetragon ランタイムセキュリティ（強制・検知） Ciliumスタック上のeBPF（kprobe/LSM等） システムコール・ネットワーク ステータスは公式発表の確認を推奨 リアルタイムenforcement、K8sアイデンティティ連携
Falco ランタイム脅威検知・アラート eBPFプローブ or カーネルモジュール システムコール Graduated ルールベース検知、豊富な既存ルール資産
Pixie K8s自動テレメトリ（観測性） eBPF＋PCM L7 HTTP/gRPC/DB等 Sandbox ゼロインスツルメンテーションでのアプリ可視化
bpftrace 低レベルトレーシング bpftrace言語→eBPF kprobe/uprobe/tracepoint CNCFステータス記載なし（OSS） ワンライナーでの本番デバッグ

（参考: Traceeはコンテナ・フォレンジクス寄り、Parcaは継続プロファイリング、Grafana BeylaはAuto-Instrumentationメトリクス向け。eBPF観測性エコシステム全体の俯瞰はyoungju.devやbetterstackが詳しいです）

選び方の指針はシンプルです。ネットワーク基盤ならCilium、脅威の「検知」中心ならFalco、リアルタイム「強制」まで必要ならTetragon、低レベルな本番デバッグならbpftrace、アプリの自動テレメトリならPixie。2026年時点でKubernetesランタイムセキュリティの中心的な選択肢はFalcoとTetragonです。両者の違いは「検知してアラートを出す」Falcoに対し、Tetragonは「その場でブロック・killできる」点とKubernetesラベル・ネームスペースと連携したポリシー記述、エージェントオーバーヘッドの低さで差別化されています（1337skills、kubernetes.ae）。

重要なのは、これらが排他ではないこと。ネットワークにCilium、検知にFalco、強制にTetragonという組み合わせも実務で見られます。まず自組織の課題が「見たい」「守る」「速くする」のどれかを整理してからツールを選ぶのがおすすめです。

ユースケース①観測性——アプリを書き換えずにシステムの内側を見る

eBPF観測性の最大の魅力は、アプリケーションの再ビルド・再デプロイ・インスツルメンテーションなしに、本番環境でレイテンシ・エラー・ネットワークフローを可視化できる点です（youngju.dev）。

まずはbpftraceから。awk風の言語でワンライナーが書けます。

# システムコールの発行回数をプロセス別に集計
bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

これだけで「どのプロセスがsyscallを乱発しているか」が分かります。より複雑なツールを作りたいならBCC、定常運用にはCilium Hubbleによるネットワークフロー可視化、PixieによるゼロインスツルメンテーションのHTTP/gRPCテレメトリ、Parcaによる継続プロファイリング、Grafana BeylaによるREDメトリクス自動生成、Keplerによる消費電力計測と、目的別に道具が揃っています（betterstack、metoro.io）。

従来のエージェント型観測では計測コードの導入とランタイムオーバーヘッドが課題でしたが、eBPFはカーネルレベルで一度拾えば済むため、そのコスト構造を変えます。観測データの保管・分析基盤については、当ブログの「Observability DatabaseとClickHouse×OTel」、コスト問題の文脈は「Agent DebtとAI Observability」も参照してください。

ユースケース②ネットワーキング＆セキュリティ——iptablesからの交代とリアルタイム防御

ネットワーキングでは、CiliumがiptablesをeBPFによるカーネルレベルの直接パケット処理で置き換えます。L7（HTTP/gRPC）フィルタリング、DNSベースのネットワークポリシー、WireGuardによる透過的暗号化に加え、注目はサイドカーレスサービスメッシュです。従来のIstioサイドカーモードでは各PodにEnvoyが注入され、メモリ・レイテンシの「サービスメッシュ税」（サイドカー1つにつき数十〜100MB前後という指摘もあります。あくまで目安であり構成次第です）が問題視されていました。CiliumはL4処理をカーネルのeBPFで行い、L7が必要な箇所だけEnvoyを配置することで、オーバーヘッドの削減を目指します（bex.co、Qiita）。またXDPフックによるドライバーレベルのパケット処理は、DDoS緩和やロードバランシングで高いスループットが報告されています（kubo.hexabase）。

セキュリティでは、旧来のカーネルモジュール方式が完全なカーネル権限で動作しバグがシステムパニックを引き起こしうたのに対し、eBPFはVerifierで検証済みのコードのみを実行する、より制約の強い設計をとりつつ、プロセス・ネットワークの深い可視化とリアルタイム強制（enforcement）を提供します。Falcoはルールベース検知の定番（CNCF卒業）、TetragonはeBPFによる検知＋強制とK8sアイデンティティ連携が強みです（safeguard.sh）。検知は「アラートを上げて人間が対応」、強制は「その場でプロセスをkill・ブロック」。ゼロデイ攻撃への対応速度が変わります。

実践ステップ——ローカル/クラスタでeBPFを始める5ステップ

それでは実際に始めてみましょう。順番に進めれば、本番導入の判断材料も揃います。なおbpftrace等をソースからビルドする場合はカーネルヘッダ（linux-headers-$(uname -r)）が必要です。主要ディストリビューションのパッケージ版bpftraceでは通常不要ですが、エラーが出たらまず確認してください。

Step 1: 環境確認（カーネルバージョンとBTF）

uname -r                          # カーネル4.x以降が望ましい
ls /sys/kernel/btf/vmlinux        # 存在すればBTF有効＝CO-RE対応

BTFが有効なカーネルでは、CO-RE対応ツール（libbpfベース）がカーネルバージョンごとの再コンパイルなしで動作します。ただし使用するツールが必要とするフック・ヘルパー機能が対象カーネルにあるかは、ツール側のドキュメントで確認してください。Ciliumのインストールガイドも、この確認から始まるのが定石です（linuxlab.jp）。

Step 2: bpftraceで最初のワンライナー

sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

システムコールの集計ができれば、eBPFの「ロード→検証→実行」の一連の流れを体験済みです。

Step 3: kindにCiliumをインストールしHubbleで観察

（Cilium CLIとkindがインストール済みである前提の例です。バージョンは公式ドキュメントの最新版を確認してください）

kind create cluster --name ebpf-lab
cilium install                       # バージョン省略時はCLIが安定版を選択
cilium hubble enable --ui
hubble status                        # HubbleがReadyか確認
hubble observe -f                    # フローをリアルタイム表示

iptablesベースCNIとの違いは、Pod間フローがそのまま見える点です。別ターミナルでPodを立てて hubble observe -f の出力を観察してみてください（yusui-wp）。

Step 4: Tetragonでポリシー違反をリアルタイム検知

Tetragonをデプロイし、公式のチュートリアルにある「コンテナ内での/bin/bash実行を検知するTracingPolicy」などから試すのが確実です（Tetragon公式ドキュメント、jisaku.com）。検知だけでなくkillまで一瞬で行われる様子が、eBPFのリアルタイム性の実感につながります。

Step 5: 本番導入チェックリスト

  • Verifierの上限（プログラムサイズ・ループ回数・命令数）に収まるか
  • カーネルアップグレード時にBTFが有効か、CO-REで追従できるか
  • eBPFマップサイズの上限とメモリ配分
  • ノードのハードウェア/カーネル設定（Ciliumの安定運用要件を公式ドキュメントで確認）
  • eBPFプログラムのロードにroot（CAP_BPF等）相当の権限が必要である点の運用設計

いきなり全クラスタに展開せず、まずステージングでverifierとの戦い方とデバッグ方法に慣れるのが現実的です。

よくある質問（FAQ）——eBPF入門者の疑問に答える

eBPFとは何ですか？ カーネルを再コンパイル・モジュールロードせずに、Verifierで検証されたプログラムをカーネル内で実行するLinuxの仕組みです（Zenn、ebpf.io）。

eBPFは安全なのですか？ カーネルがクラッシュしませんか？ Verifierがロード時に全実行パスを静的検証し、危険なプログラムのロードを拒否する、クラッシュやフリーズを防ぐ設計上の安全機構があります。従来のカーネルモジュールより制約が強い設計ですが、無リスクではありません（カーネル公式ドキュメント、tech-tldr）。

eBPFで何ができますか？ 観測性（トレーシング・プロファイリング）、ネットワーキング（CNI・サービスメッシュ・DDoS緩和）、セキュリティ（ランタイム検知・強制）の3大領域です（crexgroup）。

CiliumとFalcoとTetragonはどう使い分ける？ ネットワーク基盤はCilium、脅威の検知中心はFalco、リアルタイム強制まで必要ならTetragon、です（devopsboys.com）。

WindowsでもeBPFは使えますか？ Microsoftの「eBPF for Windows」がuBPF＋PREVAIL verifierでLinuxと同じツールチェーンの利用を目指しており、v1.0 RC段階（2026年8月時点）。Proof of Verification機能による検証済みプログラムのみのロード方針も示されています（GitHub、公式ドキュメント）。

eBPFのデメリットは？ verifierの制約（複雑なプログラムが拒否されうる）、カーネルバージョン依存の知識コスト、プログラムサイズ・ループ回数の上限、デバッグの難しさです。

まとめ——プログラマブルカーネルという新しい前提

eBPFは「カーネルに触ると危険」というLinuxの常識を変えました。大手クラウドのマネージドKubernetesでもeBPFベースのCilium採用が広がる今（2026年8月時点）、観測・ネットワーク・セキュリティのいずれかに従事するなら、eBPFは主要な前提技術のひとつです。そしてMicrosoftによるWindows展開が進むように、eBPFは「Linux専用技術」からOSのプログラマビリティの共通言語へと拡張しつつあります。

サンドボックス化された実行環境という点でWebAssembly 3.0のComponent Model、データセンター基盤技術の転換点という文脈でCXLメモリプーリングとも対比すると、その位置づけがより立体的に見えてくるはずです。まずはbpftraceのワンライナーから。カーネルの内側は、思っているよりずっと近くにあります。

出典一覧

本文中の主張と出典の対応は次のとおりです（確認日: 2026-08-23）。

公式一次資料

解説記事（二次資料）

関連記事