Skip to main content

Cilium と eBPF で Kubernetes ネットワーキングを革新する

2026年5月27日by Kubo Team #Cilium #eBPF #Kubernetes #ネットワーキング #CNI #CNCF #セキュリティ #Hubble

Kubernetes のネットワーキングは複雑です。Pod 間通信、Service のロードバランシング、NetworkPolicy によるアクセス制御 -- これらすべてが iptables ルールの積み重ねで処理されてきました。しかし、Cilium は eBPF（extended Berkeley Packet Filter）技術を活用して、この構造を根本から変革しています。CNCF Graduated プロジェクトとして認定された Cilium は、Kubo のような K3s ベースのプラットフォームから大規模クラスタまで、あらゆる Kubernetes 環境に適用できるネットワーキングソリューションです。

eBPF とは何か：Linux カーネルのプログラマブル拡張

eBPF（extended Berkeley Packet Filter）は、Linux カーネル内でサンドボックス化されたプログラムを実行する技術です。従来はカーネルモジュールを変更するしかなかった領域に、安全かつ効率的にカスタムロジックを注入できます。

GitHub 上の Cilium プロジェクトが説明するように、eBPF には以下の特長があります：

  • 高性能: カーネル空間で直接実行されるため、ユーザー空間との切り替えコストがない
  • 安全性: eBPF Verifier がプログラムを実行前に検証し、カーネルクラッシュを防止
  • 動的ロード: カーネルの再起動なしにプログラムの追加・変更が可能
  • JIT コンパイル: ネイティブマシンコードにコンパイルされ、最適なパフォーマンスを実現

Cilium は、この eBPF をネットワーキング、セキュリティ、オブザーバビリティに適用した最先端の実装です。Microsoft の Azure CNI powered by Cilium が示すように、大手クラウドプロバイダーも Cilium を採用しています。

Captain.AI は Kubernetes クラスタのネットワーク状態を AI で分析し、パフォーマンスの最適化を支援します。

iptables vs eBPF：パフォーマンスの違い

従来の Kubernetes CNI プラグイン（Calico、Flannel など）は、ネットワークポリシーとサービスルーティングを iptables ルールで実装してきました。しかし、DevOps.dev の詳細記事が指摘するように、この方式にはスケーラビリティの限界があります。

項目iptables ベースCilium (eBPF)
ルール評価線形走査（O(n)）ハッシュテーブル（O(1)）
Service 数増加時の影響ルール数に比例して遅延増大影響なし
NetworkPolicyL3/L4 のみL3/L4/L7 対応
カーネル空間処理限定的完全対応
可視性限定的Hubble によるフル可観測性
スループットベースライン最大 10 倍向上

Gocodeo の解説によると、eBPF ベースのロードバランシングは効率的なハッシュテーブルを使用しており、高いサービス密度でも低レイテンシを維持できます。特に Service 数が 1,000 を超えるような大規模クラスタでは、その差は歴然です。

Cilium のデプロイ

bash
# Helm による Cilium のインストール
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium --version 1.16.5 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

kubeProxyReplacement=true を設定すると、kube-proxy を完全に置き換え、eBPF ベースの Service ルーティングを有効にします。

L7 ネットワークポリシーとアイデンティティベースセキュリティ

Cilium の最大の差別化ポイントは、L7（アプリケーション層）まで対応したネットワークポリシーとアイデンティティベースのセキュリティモデルです。

L7 ポリシーの例

yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-access-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/public/.*"
        - method: "POST"
          path: "/api/v1/data"
          headers:
          - 'content-type: application-json'

この例では、frontend ラベルを持つ Pod からの HTTP リクエストに対して、メソッドとパスレベルでアクセスを制御しています。従来の NetworkPolicy では不可能だった粒度の細かい制御です。

アイデンティティベースセキュリティ

ComputingForGeeks のガイドが説明するように、Cilium はネットワークアドレスではなく Kubernetes のラベルに基づくアイデンティティ でセキュリティを適用します。IP アドレスが動的に変わるコンテナ環境では、この方式が理想的です。

ClusterMesh によるマルチクラスタ接続

yaml
# ClusterMesh の有効化
helm upgrade cilium cilium/cilium \
  --set cluster.name=cluster-1 \
  --set cluster.id=1 \
  --set clustermesh.useAPIServer=true

Cilium ClusterMesh を使えば、複数の Kubernetes クラスタ間でシームレスかつ安全な通信が可能になります。Kubo で複数クラスタを運用する場合にも強力なソリューションです。

Hubble によるネットワーク可観測性

Cilium に内蔵された Hubble は、eBPF を活用した強力なネットワーク可観測性ツールです。

Hubble が提供する情報

  • フローログ: Pod 間のすべてのネットワークフローをリアルタイムで記録
  • L7 プロトコル可視化: HTTP、gRPC、Kafka 等のリクエスト/レスポンスの詳細
  • NetworkPolicy の適用結果: ポリシーによって許可/拒否されたフローの可視化
  • DNS クエリログ: クラスタ内の DNS リクエストの追跡
  • サービスマップ: Pod 間の依存関係を自動生成

Hubble CLI の活用

bash
# 特定 Namespace のフローを監視
hubble observe --namespace production

# HTTP リクエストのみをフィルタ
hubble observe --protocol http --namespace production

# 拒否されたフローを確認
hubble observe --verdict DROPPED

# サービスマップの表示
hubble observe --output json | hubble-ui

Hubble Metrics の Prometheus 連携

yaml
hubble:
  metrics:
    enabled:
    - dns
    - drop
    - tcp
    - flow
    - port-distribution
    - icmp
    - httpV2:exemplars=true;labelsContext=source_ip,source_namespace,destination_ip,destination_namespace

これらのメトリクスを Prometheus でスクレイプし、Grafana で可視化することで、ネットワークレベルの完全なオブザーバビリティが実現します。

Captain.AI とHubble のデータを組み合わせることで、AI がネットワークの異常パターンを自動的に検出し、対処を提案するワークフローの構築が可能です。

まとめ

Cilium と eBPF は、Kubernetes ネットワーキングの新しいスタンダードです。本記事のポイントをまとめると：

  1. eBPF はカーネル内でプログラムを実行し、iptables を超えるパフォーマンスとセキュリティを実現
  2. iptables 比で最大 10 倍のスループット向上と、Service 数に依存しないスケーラビリティ
  3. L7 ネットワークポリシーで HTTP メソッド・パスレベルのアクセス制御が可能
  4. アイデンティティベースセキュリティで動的な Pod 環境に最適なセキュリティモデル
  5. Hubble によるフローログ、L7 プロトコル可視化、サービスマップ

Kubo は K3s ベースで CNCF エコシステムとの高い親和性を持ち、Cilium の導入により軽量かつ高性能なネットワーキング基盤を構築できます。Kubernetes のネットワーキングとセキュリティの強化に取り組む方は、ぜひ Kubo をご検討ください。

AI による Kubernetes 運用の高度化に興味がある方は、Captain.AI の詳細をご覧ください。導入のご相談はお問い合わせからお気軽にどうぞ。

← Back to all posts