CiliumのeBPFデータプレーンを導入する前に分けて考える機能

eBPFをデータプレーンに置く理由

cilium/ciliumは、eBPFを基盤にしたネットワーク、可観測性、セキュリティのソリューションです。READMEは、複数クラスタへ広げられる平坦なLayer 3ネットワークを提供し、native routingまたはoverlayを選べると説明しています。L7プロトコルを認識し、ネットワークアドレスとは切り離したアイデンティティモデルでL3からL7のポリシーを強制できます。

eBPFはLinuxカーネルへバイトコードを動的に挿入し、ネットワークI/O、アプリケーションソケット、tracepointなどで処理を行う技術として紹介されています。素材時点のGitHub情報ではstarsは25,019、forksは3,999、open issuesは1,085、既定ブランチはmainです。公開数値やREADMEの機能説明は、利用環境の性能や安全性を直接証明しません。

CNIでOverlayとnative routingを選ぶ

CiliumをCNIプラグインとして使う場合、READMEはOverlay networking、native routing、複数の経路学習方法を説明しています。OverlayはVXLANやGeneveでホスト間をカプセル化し、ホスト間にIP接続があれば使える構成です。native routingはLinuxホストの通常のルーティングテーブルを使い、コンテナのIPをネットワーク側で経路化します。

L2近隣探索やBGPによる経路広告など、トポロジーに応じた選択肢もあります。これはクラスターのネットワーク設計とクラウドのルーター、IPv6、ファイアウォールに関係します。導入試験では、Pod間、外部サービス、ノード間、複数クラスタ間の経路を分け、MTU、障害時の経路、名前解決、戻り通信を記録してください。

ポリシーとアイデンティティの設計

Ciliumは、ネットワークアドレスだけに依存せず、アイデンティティに基づくセキュリティモデルでポリシーを適用するとREADMEにあります。L3からL7のプロトコルを対象にできるため、Pod、サービス、外部通信、アプリケーション層の条件を別々に検討します。

ポリシーを導入するときは、既存通信を最初に観測し、許可する通信と拒否する通信を実際のラベルやサービス名で書きます。READMEの概説だけから、社内の全通信が安全に分類できると推測してはいけません。DNS、ヘルスチェック、監視、外部API、管理経路を含めた試験を用意し、変更後に必要な通信が止まっていないかを確認します。

kube-proxy置換とロードバランシング

READMEは、CiliumがPod間と外部サービスへの通信で分散ロードバランシングを実装し、kube-proxyを完全に置き換えられると説明しています。eBPFのハッシュテーブルを使い、大規模化に対応できるという記述もあります。さらにIngressとEgressゲートウェイ、帯域管理、サービスメッシュ、ネットワークとセキュリティの監視機能が挙げられています。

これらは一つの設定で同じ結果になる機能ではありません。kube-proxyを置き換える前に、Serviceの種類、NodePort、外部トラフィック、既存のIngress、ネットワークポリシー、監視のメトリクスを保存します。切り替え後は通信の遅延、接続失敗、ノード停止、ロールバックを比較してください。READMEには環境別の性能値や上限はありません。

安定版の保守とアーキテクチャ

Ciliumコミュニティは、直近三つのマイナー版について安定版を保守し、それより前の版をEOLとみなす方針をREADMEで示しています。素材時点のリリース一覧にはv1.20.1、v1.19.7、v1.18.13があり、READMEの保守表にはv1.20、v1.19、v1.18のブランチが載っています。アップグレードはCilium Upgrade Guideを読むよう案内されています。

CiliumのイメージはAMD64とAArch64向けに配布され、v1.13.0以降のイメージにはSPDX形式のSBOMが含まれるとREADMEは説明しています。SBOMは構成物の確認に使えますが、脆弱性が存在しないことを意味しません。採用版、Kubernetes版、Linuxカーネル、イメージダイジェスト、SBOMを記録し、マイナー更新をテスト環境で再現します。

開発イメージを本番へ持ち込まない

開発と試験用には、mainブランチから作られたスナップショット、リリース候補、CIコンテナイメージが公開されています。READMEは、これらを本番で使わないよう明記しています。v1.21.0-pre.0などの候補版とquay.io/cilium/cilium-ci:latestは、検証のための材料として安定版と分けて扱います。

アップグレードを試すときは、開発版の機能を確認する試験と、安定版からの移行手順を確認する試験を分けます。mainの毎日ビルドは、同じタグを後から取得しても内容を固定できない可能性があります。試験時のイメージ、コミット、設定、カーネル、Kubernetesクラスタを記録し、再現できる状態を残してください。

採用前に残す運用上の質問

CiliumはApache 2.0で提供されています。利用や改変、配布を検討する際は、本体だけでなく、依存物、Helmチャート、監視連携、利用するイメージのライセンスと通知を確認します。READMEは公式ドキュメント、Upgrade Guide、SBOM説明へのリンクを用意していますが、個別環境のSLOやサポート契約を示すものではありません。

採用前には、Overlayとnative routingの比較、ポリシーの段階導入、kube-proxy置換、IngressとEgress、ノード障害、複数クラスタ、安定版アップグレード、開発イメージの排除を検証します。eBPFプログラムの観測方法、カーネル互換性、ログとメトリクスの保存先も確認してください。文書にない性能基準や復旧時間は、未確認事項として明記してから判断します。

編集部の結論

Ciliumは、KubernetesのコンテナネットワークをeBPFデータプレーンで構築し、ネットワークポリシーと可観測性を同じ基盤で検討したい運用者向けの選択肢です。Overlayとnative routing、kube-proxy置換、IngressやEgress、サービスメッシュを一度に有効化せず、必要な機能ごとに検証してください。READMEは直近三つのマイナー版を保守する方針とAMD64、AArch64、SBOMを示しますが、環境固有の性能や移行安全性は保証しません。Linuxカーネル、Kubernetes、ルーター、監視、リリース版を固定し、障害復旧とアップグレードを試してから採用範囲を決めるべきです。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes