eBPF の基本概念

eBPF は「拡張可能な BPF (Berkeley Packet Filter)」の略称で、Linux カーネルに組み込まれた JIT コンパイラを通じてユーザー空間から安全にコードをロードします。ロードされたプログラムはカーネル空間で直接実行されるため、ネットワークパケットやシステムコールの処理が従来の iptables/nftables に比べて高速になります。

• 安全性：カーネル側でバイトコード検証を行い、クラッシュや特権エスカレーションを防止。
• 動的更新：実行中でもプログラムを書き換えられるため、運用中のサービスに影響を与えずに機能追加が可能。
• 多様なフックポイント：XDP、TC、kprobe、tracepoint など、ネットワーク層からシステムコールまで幅広く利用できる。

参考: eBPF Documentation – Linux Kernel

Kubernetes における eBPF の活用シナリオ

Kubernetes クラスタは大量のポッド間通信を高速かつ安全に処理する必要があります。eBPF はその要件を満たすための基盤技術として、以下のような領域で採用が進んでいます。

• パケットフィルタリングとロードバランシング：従来の iptables よりも軽量に L3/L4 フィルタを実装でき、サービス Mesh のデータプレーンとしても活躍。
• トレース・プロファイリング：bpftrace や cilium monitor でカーネルイベントをリアルタイム取得し、ネットワーク遅延やパケットロスの根本原因を迅速に特定できる。
• ポリシーエンジン：Cilium のような CNI が eBPF を利用して L7 まで細かいアクセス制御を実装し、Kubernetes の NetworkPolicy を拡張する。

Cilium のアーキテクチャと主要コンポーネント

Cilium は eBPF を活用した次世代 CNI（Container Network Interface）です。本セクションでは、Cilium が提供する構成要素とその役割を整理し、実際の運用で意識すべきポイントを示します。

Agent と Operator の役割

Cilium は「データプレーン」と「制御プレーン」を明確に分離しています。Agent は各ノード上で動作し、BPF プログラムのロード・更新やエンドポイント情報の収集を行います。一方 Operator はクラスタ全体を俯瞰し、CNP（CiliumNetworkPolicy）や BPF マップサイズの自動調整など、グローバルな管理タスクを担当します。

• Agent がノード単位で高速にパケット処理を実行することで、レイテンシが最小化されます。
• Operator は CRD（Custom Resource Definition）ベースのポリシー変更を検知し、必要な BPF プログラムへとリアルタイムに反映します。

参考: Cilium Architecture – Official Docs

Hubble と Observability 機能

Hubble は Cilium が標準で提供する可観測性スタックです。BPF イベントを集約し、フロー情報やポリシー適用状況を UI で視覚化します。2024 年時点の公式機能としては以下が挙げられます。

• リアルタイムフロー表示：秒単位で更新されるトラフィックグラフにより、異常な通信パターンを即座に検知可能。
• ポリシーマッピング：どの CNP が特定のフローに影響しているかをハイライトし、デバッグ作業を簡略化。
• Prometheus Exporter：メトリクスが自動的にエクスポートされ、Grafana ダッシュボードと組み合わせて長期監視が行える。

参考: Hubble – Observability Guide

拡張機能と将来のロードマップ

Cilium はプラグインアーキテクチャを採用しており、Envoy や Istio との統合、BPF マップ自動リサイズなどの拡張が公式リポジトリで提供されています。2025 年以降に予定されている主なロードマップ項目は次の通りです（※未確定情報は「計画段階」と明記）。

公式ロードマップは随時更新されますので、最新情報は Cilium Roadmap を参照してください。

前提条件とインストール手順

本章では Cilium を実際に Kubernetes クラスタへ導入するための環境要件と、Helm/Operator を用いた標準的なデプロイフローを示します。安全かつ再現性の高い構成を目指すため、公式ドキュメントへのリンクも併記しています。

必要なカーネル・Kubernetes バージョン

Cilium が eBPF 機能を最大限に活用できる最低要件は以下です。バージョン要件は公式の「Supported Platforms」ページで定期的に更新されますので、導入前に必ず確認してください。

注意: 特定のディストリビューション（例：Ubuntu 22.04、RHEL 9）ではカーネルパッケージがデフォルトで要件を満たしています。

RBAC と権限設定

Cilium の各コンポーネントはクラスタ全体に対して高度な権限を必要とします。最小権限で安全に動作させるための ClusterRoleBinding は以下のように定義します。

ポイント：本サンプルは公式が推奨する「cilium-admin」ロールを使用しています。実運用環境では、必要最低限の権限だけを付与したカスタム Role を作成するとさらに安全です。

公式の RBAC 設定は Cilium RBAC Guide に詳細があります。

Helm Chart によるインストール手順

Helm を使うと Cilium の全コンポーネント（Agent、Operator、Hubble など）を一括でデプロイできます。以下は推奨されるステップです。

1. リポジトリ追加・更新
   bash
helm repo add cilium https://helm.cilium.io/
helm repo update

2. カスタム values.yaml の作成
   必要に応じて BPF マップ自動リサイズや Hubble UI の有効化を設定します。例として bpfMapAutoResize: true と hubble:
enabled: true を記載。

yaml
# values.yaml（抜粋）
bpfMapAutoResize: true
hubble:
enabled: true
ui:
enabled: true

1. インストール実行
   bash
helm install cilium cilium/cilium \
--namespace kube-system \
-f values.yaml

2. デプロイ完了の確認
   bash
kubectl -n kube-system get pods -l k8s-app=cilium-agent
cilium status # コンポーネントのヘルスチェック

Helm に関するベストプラクティスは公式ガイド “Installing Cilium with Helm” を参照してください。

基本的な操作とポリシー管理

Cilium が提供する CLI と CRD（Custom Resource Definition）を組み合わせることで、ネットワーク制御と可視化がシームレスに行えます。本章では日常運用で頻繁に使用するコマンド例と、ポリシー設計のベストプラクティスを紹介します。

Cilium CLI の主要コマンド

CLI はデバッグ・診断・状態確認に不可欠です。以下は実務で最も利用されるサブコマンドです。

実行例：

CiliumNetworkPolicy のベストプラクティス

Cilium のポリシーは 最小特権 を基本に設計することで、攻撃面を抑えつつトラブルシューティングを容易にします。以下のポイントを意識してください。

1. ラベルでエンドポイントを限定
   endpointSelector は必ず Pod ラベルで絞り込み、曖昧なワイルドカードは使用しない。

2. 方向（ingress/egress）とポートの明示
   必要最小限のプロトコル・ポートだけを許可し、デフォルトは deny-all に設定する。

3. 名前空間境界の活用
   Namespace 毎に共通のラベル（例：team=frontend）を付与し、ポリシーでネームスペース横断を制御する。

具体的なポリシー例

以下は frontend 名前空間のアプリが backend の HTTP (80) にだけアクセスできる最小構成です。

詳細は公式の “CiliumNetworkPolicy Reference” を確認してください。
https://docs.cilium.io/en/stable/policy/language/

可視化とトラフィックモニタリング

Hubble UI と Grafana ダッシュボードを組み合わせることで、リアルタイムのフロー情報と長期的なメトリクスを一元管理できます。

• Hubble UI：https://<cluster-endpoint>/hubble/ui にアクセスし、ポッド単位で送受信フローをフィルタリング。
• Grafana ダッシュボード：公式チャート cilium-grafana-dashboards をインストールすれば、以下のような重要指標が可視化されます。

Grafana の設定手順は Cilium Observability Guide に詳述されています。

障害診断・アップグレード・パフォーマンスチューニング

本章では障害時のトラブルシューティング手順、バージョンアップの安全な実施方法、そして本番環境で推奨されるパフォーマンス調整ポイントをまとめます。

デバッグツールの使い方

cilium monitor の活用例

cilium monitor は BPF プログラムが生成するイベントをストリーム形式で出力します。特に drop と trace イベントはポリシー違反やマップ不足を示す手掛かりになります。

bpftrace によるカスタム集計

bpftrace を使えば、Cilium の内部関数呼び出し回数やエラーカウントを簡単に可視化できます。以下は cilium_drop 関数の発生頻度をリアルタイムで表示する例です。

これらツールの詳細は公式リファレンス “Troubleshooting with Cilium” を参照してください。
https://docs.cilium.io/en/stable/troubleshooting/

安全なアップグレード手順とロールバック

Cilium のバージョン更新は Helm が提供する upgrade コマンドで実施できますが、事前に以下のチェックリストを完了させることが重要です。

1. 現在のバージョン確認
   bash
cilium version

2. 互換性マトリクスの確認
   公式リリースノートで対象 Kubernetes バージョンとカーネル要件を再チェック。

3. バックアップ取得（CRD）
   bash
kubectl get cnp -A -o yaml > cnp-backup.yaml

4. Helm Upgrade 実行
   bash
helm repo update
helm upgrade cilium cilium/cilium \
--namespace kube-system \
--set image.tag=v1.14.0 # 例: v1.14.0 に更新

5. ヘルスチェック
   bash
cilium status
kubectl -n kube-system get pods -l k8s-app=cilium-agent

ロールバック手順

アップグレード後に不具合が確認された場合は、以下のコマンドで直前リリースへ戻します。

※<REVISION_NUMBER> は helm history cilium -n kube-system で取得できます。

本番環境向けパフォーマンスチューニングポイント

BPF マップ自動リサイズの活用

大量のエンドポイントが存在するクラスタでは、BPF マップのサイズがボトルネックになることがあります。bpfMapAutoResize: true を有効にすると、Cilium がマップ使用率を監視しつつ自動的に拡張します。ただし、ノードのメモリ容量に余裕があるか事前に確認してください。

Envoy（L7 プロキシ）の設定最適化

Envoy を Cilium の L7 フィルタとして利用する場合は、以下パラメータを調整するとリソース消費が抑えられます。

• proxyIdleTimeout: 30s〜60s に設定し、アイドル状態の接続を早めにクローズ。
• listenerResourceLimit: 必要な同時接続数に合わせて上限値を調整。

エージェント数と CPU リソース

ノードあたり 1 インスタンスの Agent が標準ですが、CPU コアが 4 未満の小規模マシンでは --max-bpf-progs-per-node をデフォルト（128）から低めに設定し、CPU 使用率を抑制できます。

まとめ

• eBPF はカーネルレベルで高速・安全なパケット処理と豊富なトレース機能を提供し、Kubernetes のネットワーク基盤として最適です。
• Cilium は Agent と Operator による二層構造と Hubble などの可観測性スタックで、運用負荷を大幅に軽減します。公式ドキュメントに記載された要件（Linux カーネル 5.10+, Kubernetes v1.27+）を満たす環境であれば、Helm だけで数分で導入可能です。
• CLI と CNP を組み合わせることで、最小特権のポリシー設計とリアルタイムモニタリングが実現できます。
• 障害時は cilium monitor や bpftrace でカーネルイベントを取得し、Helm のロールバック機能で安全にバージョンダウングレードできます。
• 本番向けには BPF マップ自動リサイズや Envoy のタイムアウト調整などのチューニングが効果的です。

以上の手順とベストプラクティスを踏襲すれば、Cilium を用いた安全かつ高性能な Kubernetes ネットワーク基盤を安定的に運用できるでしょう。