Cilium 1.19 × EKSデフォルトCNI採用の全貌 — eBPFでKubernetesネットワークをIPsec暗号化標準化する実践設定

AWS

この記事の概要

  • Cilium 1.19（2025年11月）でIPsec/WireGuard暗号化がデフォルト強制化。AWS EKSのデフォルトCNIにも採用され、iptables比で30〜40%高スループットを実現
  • eBPFによるカーネル直接パケット処理でiptablesルールの爆発問題を根本解消。大規模クラスターほど効果大
  • Hubbleを使えばアプリコード変更ゼロで全ネットワークフローを可視化でき、トラブルシュートの時間を劇的に短縮できる

背景・概要

「ノード数が増えてきたら、iptablesのルールが何千行にも膨れ上がって、デバッグのたびに冷や汗をかく」——Kubernetesを本番で運用しているインフラSEなら、一度はこの体験をしているのではないでしょうか。

iptablesはLinuxの歴史ある仕組みですが、ルール数に対してO(n)の線形探索が走るため、Podが増えるたびにパフォーマンスが低下していきます。
数百ノード規模になると、ネットワーク遅延の原因がiptablesにある、というケースも珍しくありません。

そこで登場したのが Cilium です。
eBPF（Extended Berkeley Packet Filter）を使い、iptablesを完全に置き換えてカーネル直接でパケット処理を行います。
2025年末時点で、AWS EKS・GKE・AKS の3大クラウド全てがデフォルトCNIとして採用するまでに普及しました。

この記事では、Cilium 1.19の新機能とEKSへの導入手順、そしてHubbleによるネットワーク可視化まで、実際のコマンドをもとに解説します。

詳細解説

なぜCiliumなのか — iptables vs eBPFの本質的な違い

iptablesはルールを線形に評価するため、ルール数が増えるほど遅くなります。
一方、eBPFはカーネル内のBPFマップを使ったハッシュ検索（O(1)）でパケットを処理します。

graph TD
    subgraph 従来のiptables
        P1[パケット受信] --> R1[ルール1チェック]
        R1 --> R2[ルール2チェック]
        R2 --> R3[ルール3チェック ... N個]
        R3 --> D1[転送/ドロップ]
    end

    subgraph Cilium eBPF
        P2[パケット受信] --> BPF[BPFマップ\nハッシュ検索 O1]
        BPF --> D2[即転送/ドロップ]
    end

    style 従来のiptables fill:#ffcccc
    style Cilium eBPF fill:#ccffcc

Cilium公式ベンチマーク（2025年）では、iptables比で スループット30〜40%向上・レイテンシ削減が確認されています。
ノード数が100を超えてくると、この差は無視できないレベルになります。

Cilium 1.19 の主要変更点

暗号化のデフォルト強制化が最大のポイントです。
従来はオプションだったIPsec/WireGuardによるPod間通信の暗号化が、sensitive環境向けにデフォルト有効化されました。

また、AKSでのperflow L7可視化も追加。
HTTP・gRPC・Kafkaのフローをポートレベルで確認でき、Azure Monitorと連携してL7トラフィックのダッシュボードが自動生成されます。

変更点 内容
IPsec/WireGuard 暗号化 sensitive環境でデフォルト強制（従来はオプション）
AKS L7可視化 HTTP/gRPC/Kafkaをフローレベルで監視可能
Azure Monitor連携 L7トラフィックのダッシュボード自動生成
EKSデフォルトCNI採用 新規EKSクラスターでCiliumがデフォルトに

EKSへのCiliumインストール手順

eksctlを使ったインストールが最も簡単です。
ポイントはノードグループ作成前にCiliumを入れることです。

# ① ノードグループなしでクラスターを作成
eksctl create cluster \
  --name cilium-cluster \
  --region ap-northeast-1 \
  --without-nodegroup

# ② aws-nodeデーモンセットを無効化（CiliumがENI管理を引き継ぐ）
kubectl patch daemonset aws-node \
  -n kube-system \
  -p '{"spec":{"template":{"spec":{"nodeSelector":{"io.cilium/aws-node-enabled":"true"}}}}}'

# ③ CiliumをHelmでインストール（WireGuard暗号化有効）
helm repo add cilium https://helm.cilium.io/
helm install cilium cilium/cilium \
  --version 1.19.0 \
  --namespace kube-system \
  --set eni.enabled=true \
  --set ipam.mode=eni \
  --set egressMasqueradeInterfaces=eth0 \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --wait

# ④ ノードグループを追加
eksctl create nodegroup \
  --cluster cilium-cluster \
  --region ap-northeast-1 \
  --name standard-workers \
  --node-type m7g.xlarge \
  --nodes 3

インストール後、Ciliumのステータスを確認します。

# cilium CLIのインストールと状態確認
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --remote-name "https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz"
tar xzvf cilium-linux-amd64.tar.gz
sudo mv cilium /usr/local/bin

cilium status
# 全ノードで "OK" が表示されればOK

Hubbleでネットワークを可視化する

Ciliumに組み込まれた Hubble は、アプリコードを1行も変えずに全ネットワークフローをリアルタイム観測できる強力なツールです。
「このPodはどのサービスに通信しているか」「HTTPのどのエンドポイントが失敗しているか」が一目でわかります。

# Hubble UIを有効化
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

# Hubble CLIでリアルタイム監視
hubble observe \
  --namespace default \
  --protocol http \
  -f
# 出力例:
# Jan  1 12:00:00.000: default/frontend → default/backend:80 HTTP/1.1 200 GET /api/v1/users (0ms)
# Jan  1 12:00:01.000: default/frontend → default/backend:80 HTTP/1.1 500 POST /api/v1/order (23ms) ← これを即検知

ここ、地味に便利なポイントで… サービスメッシュなしでL7レベルの情報が取れるのが特徴です。
Istioのサイドカーを入れなくても、HTTP ステータスコードやDNSクエリがそのまま見えます。

L7 NetworkPolicyで細かいアクセス制御

CiliumNetworkPolicyを使うと、通常のKubernetes NetworkPolicyでは不可能なL7（HTTP/gRPC）レベルのアクセス制御が実現できます。

# GETの/api/*のみ許可、POSTは全拒否
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: api-read-only
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/.*"
        # POSTやDELETEはデフォルト拒否

従来のNetworkPolicyではIP/ポートレベルまでしか制御できませんでしたが、CiliumNetworkPolicyならHTTPメソッド・パスまで指定できます。
マイクロサービス間の最小権限通信を実現する上で、これは非常に強力です。

実務での活用方法

シナリオ1: 大規模クラスターのネットワーク性能改善

100ノード以上のクラスターでレイテンシの問題が出始めたら、CNIをCiliumに移行するのが有効打です。
iptablesのルール数は劇的に減り、パケット処理のオーバーヘッドが解消されます。
既存のNetworkPolicyはそのままCiliumで読み込めるため、移行リスクも低いです。

シナリオ2: コンプライアンス要件を満たすPod間暗号化

金融・医療など規制の厳しい業界では、クラスター内のPod間通信も暗号化が求められるケースがあります。
Cilium 1.19のWireGuard暗号化をHelmオプション一つで有効化すれば、アプリコードを変えずにmTLS相当の通信暗号化が実現できます。

まとめ

  • CiliumはeBPFベースのCNIでiptablesを置き換え、30〜40%高スループットを実現
  • Cilium 1.19でIPsec/WireGuard暗号化がデフォルト強制化、全3大クラウドのデフォルトCNIに
  • EKSへのインストールはHelmで数コマンド。WireGuard暗号化もencryption.type=wireguardで有効化
  • Hubbleでコード変更なしにL7レベルのネットワーク可視化が実現
  • CiliumNetworkPolicyでHTTPメソッド・パス単位のL7アクセス制御が可能

iptablesの限界を感じ始めたタイミングが、Ciliumへの移行を検討するベストなタイミングです。
既存のNetworkPolicyとの互換性も高いので、ぜひ試してみてください。

⚠️ 料金・バージョン情報は執筆時点（2026年5月）のものです。最新情報はCilium公式サイトおよびAWS公式ドキュメントでご確認ください。

参考リンク

コメント