[{"data":1,"prerenderedAt":328},["ShallowReactive",2],{"blog-ja-kubernetes-ebpf-inspektor-gadget-observability":3,"blog-related-ja-kubernetes-ebpf-inspektor-gadget-observability":281,"blog-ja-kubernetes-ebpf-inspektor-gadget-observability-alt":270},{"id":4,"title":5,"author":6,"body":7,"date":264,"description":265,"extension":266,"image":267,"locale":268,"meta":269,"navigation":270,"path":271,"seo":272,"stem":273,"tags":274,"__hash__":280},"blog\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability.md","strace禁止、sidecar禁止、それでも診断できる。KubernetesをeBPFで透視するInspektor Gadgetという回答","Kubo Team",{"type":8,"value":9,"toc":254},"minimark",[10,15,23,35,50,59,63,69,78,81,110,113,117,123,130,143,150,154,160,175,190,199,203,209,212,219,228,232,235],[11,12,14],"h2",{"id":13},"_1-動いているはずなのに中で何が起きているか分からないという現場の詰み","1. 「動いているはずなのに中で何が起きているか分からない」という現場の詰み",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ebpf-inspektor-gadget-observability\u002Fsection01.webp",[16,24,25,26,30,31,34],{},"Kubernetes を本番で運用していると、必ず一度はこの壁にぶつかる。Pod は Running のまま、ヘルスチェックも通っている。なのに、特定の通信だけが妙に遅い、あるいは特定のリクエストだけがどこかで消えている。",[27,28,29],"code",{},"kubectl logs"," にも ",[27,32,33],{},"kubectl describe"," にも、原因を示す手がかりは出てこない。",[16,36,37,38,41,42,49],{},"こういうとき、従来の解決策は決して魅力的ではなかった。イメージに ",[27,39,40],{},"strace"," を仕込んで再ビルドする、デバッグ用の sidecar を注入する、特権コンテナを一時的に追加する、あるいはノードにカスタムのカーネルモジュールを配布する。どれも本番環境では簡単に許可されない。変更管理のプロセスを通すだけで数時間、場合によっては数日かかることもある。これは自前で構築したクラスタに限った話ではなく、",[43,44,48],"a",{"href":45,"rel":46},"https:\u002F\u002Fkubo.hexabase.io\u002F",[47],"nofollow","Kubo"," のようなマネージド Kubernetes を使っていても、標準のメトリクス監視だけでは同じ壁にぶつかる。",[16,51,52,53,58],{},"Kubernetes eBPF という技術の組み合わせは、この詰みを別の角度から解決する。アプリケーションのイメージにもワークロードにも一切手を加えず、カーネルレベルで何が起きているかを観測できるからだ。CNCF の Sandbox プロジェクトである ",[43,54,57],{"href":55,"rel":56},"https:\u002F\u002Fgithub.com\u002Finspektor-gadget\u002Finspektor-gadget",[47],"Inspektor Gadget"," は、まさにこの発想を Kubernetes 運用の現場に落とし込んだツールである。",[11,60,62],{"id":61},"_2-ebpfとは何かアプリを一切触らずに中身が見える理由","2. eBPFとは何か—アプリを一切触らずに「中身」が見える理由",[16,64,65],{},[19,66],{"alt":67,"src":68},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ebpf-inspektor-gadget-observability\u002Fsection02.webp",[16,70,71,72,77],{},"eBPF（extended Berkeley Packet Filter）を一言で説明すると、「Linux カーネルに、監視カメラを一時的に安全に設置できる仕組み」だ。",[43,73,76],{"href":74,"rel":75},"https:\u002F\u002Febpf.io\u002F",[47],"eBPF 公式サイト","によれば、eBPF はカーネル内で安全に実行されることが検証されたプログラムを、カーネルの任意のフックポイントに差し込み、JIT コンパイラによってネイティブに近い速度で実行できる技術だと説明されている。",[16,79,80],{},"これが重要なのは、カーネルの再起動もパッチも不要な点だ。実行時にプログラムをロード・アンロードできるため、本番環境を止めずに観測を開始し、必要がなくなればすぐに外せる。公式サイトでは、eBPF の主要な用途として次の4分野が挙げられている。",[82,83,84,92,98,104],"ul",{},[85,86,87,91],"li",{},[88,89,90],"strong",{},"ネットワーク処理",": パケット処理をカーネル空間で高速化し、独自のプロトコルパーサーを追加できる",[85,93,94,97],{},[88,95,96],{},"可観測性",": カーネル内でカスタムメトリクスを集約し、さまざまなソースからイベントを生成する",[85,99,100,103],{},[88,101,102],{},"トレーシング・プロファイリング",": トレースポイントやプローブに接続し、システムパフォーマンスを診断する",[85,105,106,109],{},[88,107,108],{},"セキュリティ",": システムコールやパケット・ソケットレベルの監視により、文脈を踏まえたセキュリティ検知を実現する",[16,111,112],{},"Kubernetes eBPF の組み合わせが強力なのは、この「カーネルレベルの生データ」だけでは、実は Pod やコンテナといった Kubernetes の文脈が分からないという点にある。ここを埋めるのが、次に紹介する Inspektor Gadget の役割だ。",[11,114,116],{"id":115},"_3-inspektor-gadgetがkubernetesの文脈を可視化する仕組み","3. Inspektor GadgetがKubernetesの「文脈」を可視化する仕組み",[16,118,119],{},[19,120],{"alt":121,"src":122},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ebpf-inspektor-gadget-observability\u002Fsection03.webp",[16,124,125,129],{},[43,126,128],{"href":55,"rel":127},[47],"Inspektor Gadget の GitHub リポジトリ","によれば、このプロジェクトは「Kubernetes クラスタと Linux ホストのデータ収集・システム検査のためのツール群とフレームワーク」と定義されている。中核となるのが「gadget」という単位だ。gadget は eBPF プログラムとメタデータ（場合によっては WebAssembly モジュールも含む）を1つの OCI イメージとしてパッケージ化したもので、コンテナレジストリを介して保存・配布できる。",[16,131,132,133,138,139,142],{},"これにより、カーネルが観測した生のシステムコールやネットワークパケットが、「どの名前空間の、どの Pod の、どのプロセスが」発生させたものかまで自動的にひも付けられる。例えば、ある Pod からの通信が Pod 宛てなのか、生の IP アドレス宛てなのか、あるいは Kubernetes の Service 経由なのかを区別し、DNS の名前解決までトレースすることも可能だ。動作確認は ",[43,134,137],{"href":135,"rel":136},"https:\u002F\u002Fminikube.sigs.k8s.io\u002Fdocs\u002Fhandbook\u002Faddons\u002Finspektor-gadget\u002F",[47],"Minikube のアドオンドキュメント","にある通り、",[27,140,141],{},"minikube addons enable inspektor-gadget"," の一行だけで試せる手軽さも用意されている。",[16,144,145,146,149],{},"つまり Inspektor Gadget は、Kubernetes eBPF という組み合わせにおいて、強力だが低レベルすぎる技術と、Kubernetes という高レベルな抽象化の間を橋渡しするレイヤーだと言える。この設計思想は、",[43,147,48],{"href":45,"rel":148},[47]," のようなマネージド Kubernetes 環境で標準搭載されている Prometheus + Grafana によるメトリクス監視とは、補い合う関係にある。メトリクスは「何かがおかしい」ことを教えてくれるが、「なぜ」までは踏み込まない。そこから先の深掘りに、eBPF ベースの可観測性が力を発揮する。",[11,151,153],{"id":152},"_4-2026年cncfエコシステムでinspektor-gadgetに起きていること","4. 2026年、CNCFエコシステムでInspektor Gadgetに起きていること",[16,155,156],{},[19,157],{"alt":158,"src":159},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ebpf-inspektor-gadget-observability\u002Fsection04.webp",[16,161,162,163,168,169,174],{},"Inspektor Gadget は、",[43,164,167],{"href":165,"rel":166},"https:\u002F\u002Fgithub.com\u002Fcncf\u002Fsandbox\u002Fissues\u002F7",[47],"CNCF Sandbox の申請 Issue","によると2022年10月にプロジェクトとして申請され、承認された。",[43,170,173],{"href":171,"rel":172},"https:\u002F\u002Fwww.cncf.io\u002Fsandbox-projects\u002F",[47],"CNCF Sandbox の定義","では、Sandbox は「early stage projects の入口」であり、本番で広く使われる前段階の実験的プロジェクトを育成する場と位置づけられている。",[16,176,177,178,183,184,189],{},"2026年に入り、このプロジェクトは2つの大きな節目を迎えた。1つは、",[43,179,182],{"href":180,"rel":181},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F06\u002F03\u002Finspektor-gadget-results-from-the-first-security-audit\u002F",[47],"CNCF の公式ブログ","が発表した独立セキュリティ監査の完了だ。CNCF が資金を提供し、Open Source Technology Improvement Fund（OSTIF）が調整、",[43,185,188],{"href":186,"rel":187},"https:\u002F\u002Fwww.shielder.com\u002Fblog\u002F2026\u002F04\u002Finspektor-gadget-security-audit\u002F",[47],"Shielder","が実施したこの監査では、コマンドインジェクション（中程度）や DoS の可能性、ANSI エスケープシーケンスのサニタイズ不足（低程度）といった脆弱性が発見され、いずれも修正済みだ。Shielder は監査範囲について、eBPF プログラム実行に必要な高い権限レベルと、観測を回避されるリスクに焦点を当てたと説明しており、最終的に「セキュアなコーディングと設計の両面で成熟している」と結論づけている。",[16,191,192,193,198],{},"もう1つは、AI との統合だ。",[43,194,197],{"href":195,"rel":196},"https:\u002F\u002Finspektor-gadget.io\u002Fblog\u002F2026\u002F03\u002Finspektor-gadget-holmesgpt\u002F",[47],"Inspektor Gadget の公式ブログ","によれば、AIOps ツールの HolmesGPT との統合により、DNS 追跡・TCP 接続監視・ネットワークパケットキャプチャなど8種類の eBPF ベースの調査ツールを、自然言語の指示だけで呼び出せるようになった。「特定 Pod のネットワークトラフィックを取得して要約して」と頼むだけで、複雑な kubectl コマンドを覚えなくても深いトラブルシューティングができる時代が近づいている。AI エージェントが実際の運用オペレーションを担うようになるほど、その裏側でこうした低レベルな可観測性の基盤が求められることになる。",[11,200,202],{"id":201},"_5-本番のkubernetes運用にebpf可観測性をどう組み込むか","5. 本番のKubernetes運用にeBPF可観測性をどう組み込むか",[16,204,205],{},[19,206],{"alt":207,"src":208},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ebpf-inspektor-gadget-observability\u002Fsection05.webp",[16,210,211],{},"ここまでの内容を踏まえると、Kubernetes eBPF を本番運用に組み込む際の現実的な位置づけが見えてくる。Prometheus と Grafana によるメトリクス監視で「何かがおかしい」ことを検知し、それでも原因が特定できない場合に、Inspektor Gadget のような eBPF ベースのツールでシステムコールやネットワークパケットのレベルまで深掘りする。この二段構えの運用設計こそが、Kubernetes 運用を属人化させないための現実解だ。",[16,213,214,215,218],{},"重要なのは、こうした CNCF エコシステムのツールを後から自由に追加導入できるかどうかは、クラスタの構成に依存するという点だ。ベンダー独自の拡張が入り込んだ Kubernetes 環境では、標準ツールが期待通りに動かないことがある。",[43,216,48],{"href":45,"rel":217},[47]," は K3s ベースの Pure Kubernetes を採用しており、標準の Kubernetes API に準拠しているため、Inspektor Gadget のような CNCF プロジェクトのツールもそのまま動かせる。ベンダーロックインを避けたいインフラエンジニアにとって、これは地味だが効いてくる違いだ。",[16,220,221,222,227],{},"さらに、AI との統合が進む可観測性の潮流を踏まえると、",[43,223,226],{"href":224,"rel":225},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[47],"Captain.AI"," のような AI エージェント実行基盤と組み合わせることで、障害調査の一次対応を自動化する構想も現実味を帯びてくる。まずは標準搭載のモニタリングで運用を始め、必要に応じて eBPF ベースの深い可観測性を足していく。この段階的なアプローチを取れる基盤かどうかが、今後のインフラ選定で問われることになるだろう。",[11,229,231],{"id":230},"_6-まとめ","6. まとめ",[16,233,234],{},"特権コンテナも sidecar も strace もままならない本番の Kubernetes で、Podの中身を診断する手段がない、という悩みは今や過去のものにできる。eBPF は、アプリケーションに一切手を加えずにカーネルレベルの真実を取り出す技術であり、Inspektor Gadget はそれを Kubernetes の文脈に翻訳するレイヤーだ。2026年に入ってセキュリティ監査を経て成熟度を証明し、AI との統合によって使いやすさも増している。",[16,236,237,238,241,242,247,248,253],{},"メトリクスだけで運用の全てを説明しようとせず、eBPF という「見えない層」を埋める手段を選択肢に持っておくこと。それが、障害対応を属人化させない本番運用への一歩になる。",[43,239,48],{"href":45,"rel":240},[47]," のような Pure Kubernetes 準拠の環境なら、こうした CNCF エコシステムのツールをそのまま活用しながら、月額48,000円〜という予測可能なコストで本格的な Kubernetes 運用を始められる。気になる方は、",[43,243,246],{"href":244,"rel":245},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[47],"料金プラン","や",[43,249,252],{"href":250,"rel":251},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[47],"お問い合わせ","から詳細を確認してみてほしい。",{"title":255,"searchDepth":256,"depth":256,"links":257},"",2,[258,259,260,261,262,263],{"id":13,"depth":256,"text":14},{"id":61,"depth":256,"text":62},{"id":115,"depth":256,"text":116},{"id":152,"depth":256,"text":153},{"id":201,"depth":256,"text":202},{"id":230,"depth":256,"text":231},"2026-08-15","特権コンテナもsidecarも追加できない本番Kubernetesで、Podの通信とシステムコールをどう診断するか。eBPFツール「Inspektor Gadget」の仕組みと2026年の最新動向を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-ebpf-inspektor-gadget-observability\u002Feyecatch.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability",{"title":5,"description":265},"blog\u002Fja\u002Fkubernetes-ebpf-inspektor-gadget-observability",[275,276,277,278,279],"k3s","kubernetes","ebpf","observability","cncf","xvWzwvXpor4GA1QeauJWQzJceEQnm7MhuYMXioseeTA",[282,290,298,305,313,321],{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","Docker Hubの無料枠が凍りついた朝、K3sクラスタは静かに詰む。Harborを自前で持つべきタイミング","Docker Hubのpull rate limitで本番K3sクラスタのイメージ取得が止まるリスクが現実味を増している。CNCF卒業プロジェクトHarborを自前運用する設計判断と隠れたコストを解説する。","2026-08-23",[275,276,288,289,279],"harbor","container-registry",{"path":291,"title":292,"description":293,"date":294,"tags":295},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[275,276,296,278,297],"opentelemetry","distributed-tracing",{"path":299,"title":300,"description":301,"date":302,"tags":303},"\u002Fblog\u002Fja\u002Fcncf-project-maturity-graduation-criteria-production","GitHubスター1万は『卒業証書』にならない。KubernetesでCNCFプロジェクトを選ぶ基準はコミット数ではなく成熟度ステージ","Kubernetesの技術選定でCNCFプロジェクトを採用する際、GitHubスター数や知名度だけで判断していないか。Sandbox\u002FIncubating\u002FGraduatedという成熟度基準とHarborの事例から、本番導入前に確認すべき基準を解説する。","2026-08-19",[275,276,279,304,289],"oss-governance",{"path":306,"title":307,"description":308,"date":309,"tags":310},"\u002Fblog\u002Fja\u002Fkubernetes-servicemonitor-silent-metrics-failure","Prometheusは動いている。なのにメトリクスが無い。ServiceMonitorが『静かに』失敗する3つの理由","Kubernetesのkubernetes service monitorが原因不明にスクレイプされない——ラベル不一致・namespaceSelector・RBACという3つの落とし穴を、公式ドキュメントを元に切り分け手順つきで解説する。","2026-08-14",[275,276,311,278,312],"prometheus","servicemonitor",{"path":314,"title":315,"description":316,"date":317,"tags":318},"\u002Fblog\u002Fja\u002Fkubernetes-ai-inference-reversal-conformance-design","推論が学習を逆転した。KubeCon Japanで語られた、AI時代のKubernetesクラスタ設計指針","AI計算需要は学習から推論へ逆転し、2030年には推論の計算能力が学習の1.5倍に達すると予測される。KubeCon Japanの議論とCNCF AI Conformance Programから、Kubernetes\u002FK3sクラスタが備えるべき設計指針を解説する。","2026-08-01",[276,275,319,279,320],"ai-inference","managed-kubernetes",{"path":322,"title":323,"description":324,"date":325,"tags":326},"\u002Fblog\u002Fja\u002Fkubernetes-aiops-incident-response-distributed-tracing","AIに『直して』と頼んでも直らない。Kubernetes本番障害調査は分散トレーシングから始まる","Kubernetes本番環境の障害対応をAIに任せても、分散システムの因果関係が見えなければ的外れな対処になる。AIOpsを機能させる分散トレーシング設計とOpenTelemetry導入の実践ステップを解説する。","2026-07-27",[276,275,278,297,296,327],"aiops",1787649512664]