0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@0h-n0

CiliumとeBPFでサイドカーレスメッシュを構築しネットワーク遅延を削減する実践ガイド

0
Last updated at Posted at 2026-02-28

この記事でわかること

  • eBPFの仕組みとCiliumがサイドカーレスサービスメッシュを実現するアーキテクチャの全体像
  • サイドカーベースのサービスメッシュとの性能比較：レイテンシ、CPU使用量、メモリ消費量の具体的なベンチマーク数値
  • Cilium Service Meshの導入手順とGateway API v1.4.1を使ったL7トラフィック管理の実装方法
  • Hubbleによるアプリケーション無変更でのL3/L4/L7可観測性の設定と活用方法
  • Cilium 1.19の新機能（Ztunnel統合、WireGuard厳格モード）と本番運用時の注意点

対象読者

  • 想定読者: Kubernetesでサービスメッシュを運用中、または導入を検討している中級〜上級のインフラエンジニア・SRE
  • 必要な前提知識:
    • Kubernetes 1.28以降の基本操作（kubectl、Helm）
    • サービスメッシュの概念（サイドカープロキシ、mTLS、トラフィック管理）
    • Linuxネットワーキングの基礎（TCP/IP、iptables）
    • コンテナネットワーキング（CNI）の基本的な理解

結論・成果

サイドカーベースのサービスメッシュからCiliumのeBPFベースアーキテクチャに移行することで、報告されているベンチマークではP99レイテンシを最大79%削減（15.3ms→3.2ms）し、Pod単位のリソースオーバーヘッドをゼロにできます。従来のサイドカーアーキテクチャではPodあたり約100m CPU + 128MBメモリが必要でしたが、eBPFベースではこのコストがノード単位のエージェントに集約されます。さらにHubbleを活用すれば、アプリケーションコードの変更なしにL3〜L7レベルの可観測性を実現でき、運用の複雑さを大幅に低減できます。

ただし、mTLS有効化時のレイテンシ増加率はベンチマーク論文によるとCiliumで+99%（3,200 RPS時点）であり、Istio Ambientの+8%と比較するとL4暗号化のオーバーヘッドが大きい点は認識しておく必要があります。用途・要件に応じた適切な選択が重要です。

eBPFとCiliumのアーキテクチャを理解する

サービスメッシュの性能課題を理解するには、まず従来のサイドカーアーキテクチャの問題点と、eBPFがそれをどう解決するかを把握する必要があります。ここでは、eBPFの基本的な仕組みから、CiliumがLinuxカーネルレベルでネットワーク処理を行うアーキテクチャまでを解説します。

サイドカーアーキテクチャの課題を整理する

従来のサービスメッシュ（Istioのサイドカーモードなど）では、各PodにEnvoyプロキシコンテナが注入されます。すべてのネットワークトラフィックはこのサイドカーを経由するため、以下の問題が生じます。

課題 詳細 影響
レイテンシ増加 トラフィックがサイドカーを2回通過（インバウンド+アウトバウンド） Per-hopで2〜5msの遅延追加
リソース消費 Pod単位でEnvoyコンテナが稼働 約100m CPU + 128MBメモリ/Pod
スケーラビリティ Pod数に比例してリソース消費が増加 1,000 Podsで約100 CPU cores + 128GBメモリのオーバーヘッド
運用複雑性 サイドカーのライフサイクル管理、バージョン管理 アップグレード時に全Podの再デプロイが必要

これらの課題に対して、ベンチマーク論文「Performance Comparison of Service Mesh Frameworks」（arxiv.org）では、Istioのサイドカーモードでは3,200 RPSの負荷でP99レイテンシが+166%増加し、12,800 RPSではターゲットRPSの達成すらできなかった（6,868 RPSにとどまった）と報告されています。

eBPFがカーネルレベルで処理を行う仕組みを知る

eBPF（extended Berkeley Packet Filter） は、Linuxカーネル内でサンドボックス化されたプログラムを安全に実行できる技術です。Ciliumはこの仕組みを活用して、ネットワーク処理をカーネルレベルで実行します。

Ciliumの公式ドキュメントによると、eBPFは以下の複数のフックポイントでパケット処理を行います。

各フックポイントの役割は以下のとおりです。

  • XDP（eXpress Data Path）: ネットワークドライバの最初期段階で動作し、DDoS防御や不正パケットの即座なドロップに使用されます。カーネルのネットワークスタック全体をバイパスできるため、処理速度が非常に高速です。
  • TC（Traffic Control）: カーネルのL3処理前に動作し、エンドポイントごとのポリシー適用やトラフィックリダイレクションを行います。
  • Socket Operations: TCPソケットの状態遷移を監視し、ローカルノード内の接続を高速化するダイレクトリダイレクションを実現します。

なぜこのアーキテクチャを選択するか:

  • ユーザー空間へのコンテキストスイッチが不要で、サイドカーによるhop追加がない
  • eBPF Mapsにより、コネクション追跡やNAT変換、ロードバランシングをカーネル内で完結

注意点:

eBPFはLinuxカーネル5.4以上（推奨は5.8以上）が必要です。カーネルバージョンが古い環境では、Ciliumの一部機能が利用できない場合があります。また、L7レベルのプロトコル処理（HTTP、gRPC、Kafkaなど）が必要な場合は、ノード単位のEnvoyプロキシが自動的に利用されます。eBPFだけですべてのL7処理を完結できるわけではない点を理解しておきましょう。

Cilium Service Meshのデータパスを把握する

Ciliumでは、L4までのトラフィック管理はeBPFプログラムがカーネル内で処理し、L7ポリシーが適用される場合のみ、ノード単位のEnvoyプロキシにトラフィックをリダイレクトします。公式ドキュメントによると、このリダイレクションにはカーネルのTPROXY（Transparent Proxy）機能を使用します。

# CiliumNetworkPolicy でL7ポリシーを適用する例
# L7ルールが指定されたエンドポイントのみ Envoy を経由する
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: http-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: api-server
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/.*"
              - method: POST
                path: "/api/v1/orders"

このポリシーでは、api-serverへの通信のうちfrontendからのリクエストのみがL7検査を受けます。L7ポリシーが定義されていないPod間通信はeBPFが直接処理するため、Envoyプロキシを経由しません。

よくある間違い: 「CiliumはEnvoyを使わない」と誤解されることがありますが、実際にはL7ポリシーが必要な場合にはノード単位のEnvoyプロキシが使用されます。違いは「Pod単位」か「ノード単位」かという点です。ノード単位であれば、100 Podsが稼働するノードでもEnvoyインスタンスは1つで済みます。

サービスメッシュフレームワークの性能を比較する

サイドカーレスアーキテクチャの利点を定量的に把握するために、公開されているベンチマーク結果を確認していきましょう。ここでは、学術論文と実環境での計測結果をもとに、Cilium・Istio・Linkerdの性能を比較します。

ベンチマーク論文の結果を読み解く

arxivに公開された論文「Performance Comparison of Service Mesh Frameworks: the MTLS Test Case」（arxiv.org）では、mTLSを有効にした状態での各サービスメッシュのパフォーマンスが比較されています。

P99レイテンシ増加率（3,200 RPS、ノード内通信）:

フレームワーク アーキテクチャ P99レイテンシ増加 増加率
Istio（サイドカー） サイドカー +0.38s +166%
Cilium サイドカーレス（eBPF） +0.22s +99%
Linkerd サイドカー +0.09s +33%
Istio Ambient サイドカーレス（Ztunnel） +0.02s +8%

CPU使用量の増加（クライアント側、3,200 RPS、ノード内）:

フレームワーク CPU増加 メモリ増加
Istio（サイドカー） +0.81 cores +255 MiB
Linkerd +0.29 cores +62 MiB
Cilium +0.12 cores +95 MiB
Istio Ambient +0.23 cores +26 MiB

この論文のベンチマークから読み取れる重要なポイントがあります。

Ciliumの強み: CPU使用量が+0.12 coresで全フレームワーク中最小です。eBPFがカーネル内で処理を完結するため、ユーザー空間でのプロキシ処理にCPUリソースを消費しません。

Ciliumの制約: mTLS有効時のレイテンシ増加率は+99%であり、Istio Ambientの+8%やLinkerdの+33%と比較すると大きい値です。論文の著者らは、Ciliumがノード内通信のネットワーク暗号化をデフォルトで無効にしている設計上の選択がこの結果に影響していると指摘しています。つまり、暗号化を強制するとオーバーヘッドが顕著になります。

注意: このベンチマークは論文公開時点（2024年11月）のバージョンで実施されたものです。Cilium 1.19（2026年2月リリース）ではWireGuard厳格モードやZtunnel統合など暗号化周りの改善が入っており、最新バージョンでは異なる結果になる可能性があります。

実環境でのレイテンシ削減効果を確認する

ベンチマーク論文とは別に、実環境での報告では、サイドカーからeBPFへの移行により以下のような改善が報告されています（oneuptime.com）。

  • P50レイテンシ: 78%削減
  • P99レイテンシ: 79%削減（15.3ms→3.2ms）
  • Per-hopの追加レイテンシ: 1ms未満（サイドカーでは2〜5ms）
  • リソースオーバーヘッド: Pod単位でゼロ（ノード単位のエージェントに集約）

トレードオフの整理:

観点 サイドカーベース eBPFベース（Cilium）
レイテンシ Per-hopで2〜5ms追加 Per-hopで1ms未満
リソース消費 Pod数に比例 ノード数に比例
L7機能の豊富さ Envoyフル機能 L7はノード単位Envoy経由
エコシステム 大規模（Istio等） 成長中（CNCF graduated）
カーネル要件 なし Linux 5.4+（推奨5.8+）

Cilium Service Meshを導入する

ここからは、実際にCilium Service Meshを導入する手順を解説します。Helmを使ったインストールから、Gateway APIによるL7トラフィック管理、暗号化設定までを順を追って実装していきましょう。

Ciliumをインストールしてサービスメッシュを有効化する

まず、CiliumをKubernetesクラスタにインストールします。公式ドキュメントに従い、kube-proxy置換モードを有効にし、サービスメッシュ機能を有効化します。

# 1. Gateway API CRDs をインストール（v1.4.1）
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.1/standard-install.yaml

# 2. Cilium を Helm でインストール
helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium --version 1.19.1 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set gatewayAPI.enabled=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.metrics.enableOpenMetrics=true \
  --set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,httpV2:exemplars=true;labelsContext=source_ip\,source_namespace\,source_workload\,destination_ip\,destination_namespace\,destination_workload\,traffic_direction}"

# 3. インストール状態を確認
cilium status --wait

各パラメータの意味:

  • kubeProxyReplacement=true: kube-proxyをCiliumのeBPFベースのサービスロードバランサーで置換します。これにより、iptablesベースのサービスルーティングがeBPFに移行されます。
  • gatewayAPI.enabled=true: Kubernetes Gateway APIサポートを有効化します。
  • hubble.enabled=true: 可観測性プラットフォームHubbleを有効化します。
  • hubble.metrics.enabled: Prometheus形式で公開するメトリクスの種類を指定します。
# eBPFプログラムがロードされていることを確認
kubectl exec -n kube-system ds/cilium -- bpftool prog list

# Ciliumのステータスを詳細確認
kubectl exec -n kube-system ds/cilium -- cilium status --verbose

ハマりポイント: kubeProxyReplacement=trueを設定する場合、既存のkube-proxyを停止する必要があります。DaemonSetとして稼働しているkube-proxyを削除せずにCiliumをインストールすると、iptablesルールが競合して予期しないルーティング動作が発生することがあります。

Gateway APIでHTTPルーティングを設定する

Cilium 1.19はGateway API v1.4.1をサポートしています。公式ドキュメントによると、Core conformanceテストをすべてパスしています。以下に、HTTPルーティングの設定例を示します。

# gateway.yaml - Gateway リソースの定義
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: cilium-gateway
  namespace: default
spec:
  gatewayClassName: cilium
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: Same
---
# httproute.yaml - HTTPRoute でパスベースルーティングを定義
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-routes
  namespace: default
spec:
  parentRefs:
    - name: cilium-gateway
  rules:
    # /api/v1 へのリクエストを api-v1 サービスにルーティング
    - matches:
        - path:
            type: PathPrefix
            value: /api/v1
      backendRefs:
        - name: api-v1
          port: 8080
          weight: 90
        - name: api-v2
          port: 8080
          weight: 10  # カナリアリリース: 10%のトラフィックを新バージョンへ
    # /healthz へのリクエストを health-check サービスにルーティング
    - matches:
        - path:
            type: Exact
            value: /healthz
      backendRefs:
        - name: health-check
          port: 8080

なぜGateway APIを選択するか:

  • Kubernetes公式の標準仕様であり、Ingress APIの後継として策定されています
  • Cilium、Istio、Envoy Gatewayなど複数の実装で利用でき、ベンダーロックインを回避できます
  • HTTPRoute、GRPCRoute、TLSRouteなど、プロトコルごとのルーティングリソースが分離されており、設定の見通しが良いです

制約条件: TLSRouteは現時点でexperimentalステータスです。本番環境でTLSパススルーが必要な場合は、十分なテストの上で使用してください。

WireGuardによるノード間暗号化を設定する

Cilium 1.19では、WireGuardとIPsecの厳格モード（Strict Mode） が導入されました（InfoQ）。従来のベストエフォート暗号化から、暗号化されていないノード間トラフィックを明示的にドロップする設計に変更されています。

# WireGuard 厳格モードを有効にしてインストール
helm upgrade cilium cilium/cilium --version 1.19.1 \
  --namespace kube-system \
  --reuse-values \
  --set encryption.enabled=true \
  --set encryption.type=wireguard \
  --set encryption.wireguard.persistentKeepalive="25s" \
  --set encryption.strictMode.enabled=true

# 暗号化ステータスを確認
kubectl exec -n kube-system ds/cilium -- cilium encrypt status

# 出力例:
# Encryption: Wireguard
# Wireguard:
#   Strict Mode:  Enabled
#   Interface:    cilium_wg0
#   Public Key:   <base64-encoded-key>
#   Port:         51871

注意: 厳格モードを有効にすると、暗号化されていないノード間トラフィックがすべてドロップされます。段階的に導入する場合は、まずencryption.strictMode.enabled=false（デフォルト）でWireGuardを有効化し、動作確認後に厳格モードに切り替えることを推奨します。また、Ciliumはデザイン上、ノード内通信の暗号化をデフォルトで無効にしています。同一ノード内のPod間通信を暗号化する必要がある場合は、追加の設定が必要です。

Hubbleで可観測性を実現する

Ciliumの可観測性プラットフォームであるHubbleを活用すると、アプリケーションコードの変更なしにネットワークフローの可視化、サービス依存関係マップの自動生成、L7メトリクスの取得が可能です。ここでは、Hubbleの設定からGrafanaとの連携までを実装します。

Hubble CLIでリアルタイムフロー監視を行う

Hubbleは、Ciliumに統合された可観測性プラットフォームです。Hubbleの公式リポジトリによると、TCP接続、DNSクエリ、HTTPリクエスト、Kafka通信などの個々の通信フローを透過的に観測できます。

# Hubble CLI のインストール
HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
HUBBLE_ARCH=amd64
curl -L --fail --remote-name-all \
  https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-${HUBBLE_ARCH}.tar.gz
sudo tar xzvfC hubble-linux-${HUBBLE_ARCH}.tar.gz /usr/local/bin
rm hubble-linux-${HUBBLE_ARCH}.tar.gz

# Hubble の状態確認
hubble status

# リアルタイムでフローを観測
hubble observe --follow

# 特定 namespace のフローをフィルタリング
hubble observe --namespace production --follow

# HTTP 5xx エラーのみをフィルタリング
hubble observe --http-status 500-599 --follow

# 特定の Pod 間の通信を観測
hubble observe --from-pod default/frontend --to-pod default/api-server --follow

# DNS クエリの監視
hubble observe --type l7 --protocol dns --follow

# ドロップされたパケットの確認
hubble observe --verdict DROPPED --follow

Cilium 1.19では、Hubbleに以下の新機能が追加されています（InfoQ）。

  • IPオプションによるパケットトレーシング: 特定のフローに対してIPオプションを使ったパケット追跡が可能
  • 暗号化ステータスによるフィルタリング: トラフィックが暗号化されているかどうかでフィルタリング可能
  • ドロップイベントへのポリシータグ付け: パケットがドロップされた際、どのネットワークポリシーが原因かを特定可能

PrometheusメトリクスとGrafanaダッシュボードを連携する

Hubbleのメトリクスは、Prometheus形式で公開されます。Ciliumの公式ドキュメントによると、21種類以上のビジュアライゼーションを含む事前構築済みのGrafanaダッシュボードが提供されています。

# prometheus-values.yaml - Prometheus でHubbleメトリクスを収集する設定例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: hubble
  namespace: kube-system
  labels:
    app: hubble
spec:
  selector:
    matchLabels:
      k8s-app: hubble
  endpoints:
    - port: hubble-metrics
      interval: 10s
      path: /metrics
---
# Grafana ダッシュボードの設定
apiVersion: v1
kind: ConfigMap
metadata:
  name: hubble-grafana-dashboards
  namespace: monitoring
  labels:
    grafana_dashboard: "1"
data:
  hubble-overview.json: |
    {
      "annotations": { "list": [] },
      "description": "Hubble Network Observability Overview",
      "panels": [
        {
          "title": "HTTP Request Rate",
          "targets": [
            {
              "expr": "sum(rate(hubble_http_requests_total{reporter=\"destination\"}[5m])) by (destination_workload, method, http_status)",
              "legendFormat": "{{destination_workload}} {{method}} {{http_status}}"
            }
          ]
        },
        {
          "title": "HTTP Request Duration (P99)",
          "targets": [
            {
              "expr": "histogram_quantile(0.99, sum(rate(hubble_http_request_duration_seconds_bucket{reporter=\"destination\"}[5m])) by (le, destination_workload))",
              "legendFormat": "{{destination_workload}}"
            }
          ]
        },
        {
          "title": "Packet Drop Rate",
          "targets": [
            {
              "expr": "sum(rate(hubble_drop_total[5m])) by (reason)",
              "legendFormat": "{{reason}}"
            }
          ]
        }
      ]
    }

主要なHubbleメトリクス:

メトリクス名 内容 用途
hubble_http_requests_total HTTP リクエスト総数 トラフィック量の監視
hubble_http_request_duration_seconds HTTP リクエスト処理時間 レイテンシ監視・SLO
hubble_drop_total ドロップされたパケット数 ネットワークポリシーのデバッグ
hubble_dns_queries_total DNS クエリ総数 DNS 障害の検知
hubble_tcp_flags_total TCP フラグ別カウント 接続リセット・タイムアウトの監視
hubble_flows_processed_total 処理済みフロー総数 Hubble 自体の健全性確認

ポイント: L7メトリクス（HTTPなど）は、対象PodでL7 Protocol Visibilityが有効になっている場合のみ出力されます。CiliumNetworkPolicyでL7ルールを定義するか、Pod annotationで明示的に有効化する必要があります。何も設定しないとL3/L4メトリクスのみが収集されます。

サービス依存関係マップを自動生成する

Hubble UIを使用すると、Kubernetesクラスタ内のサービス依存関係をL3/L4、さらにはL7レベルで自動的に可視化できます。

# Hubble UI にポートフォワードしてブラウザからアクセス
kubectl port-forward -n kube-system svc/hubble-ui 12000:80

# ブラウザで http://localhost:12000 にアクセス

Hubble UIでは以下の情報がリアルタイムで表示されます。

  • サービス間の通信フロー: どのサービスがどのサービスと通信しているかの依存関係グラフ
  • フローのメタデータ: 送信元/送信先のPod名、Namespace、ラベル情報
  • プロトコル情報: HTTP、gRPC、DNS、Kafkaなどのアプリケーションプロトコル
  • エラー情報: HTTPステータスコード、DNSエラー、パケットドロップ理由

制約条件: Hubble UIは2026年2月時点でBetaステータスです（Hubble GitHub）。本番環境での利用は問題ありませんが、UIの機能や表示形式は今後変更される可能性があります。メトリクスの永続化やアラート設定にはGrafana + Prometheusの組み合わせを推奨します。

本番環境への移行とトラブルシューティングを行う

サイドカーベースのサービスメッシュからCiliumへの移行は、段階的に進めることが重要です。ここでは、移行の手順と、本番運用で遭遇しやすい問題への対処法を解説します。

段階的移行のステップを実行する

oneuptime.comの解説によると、以下の段階的アプローチが推奨されています。

  1. 事前評価: カーネルバージョンの確認（5.4+、推奨5.8+）、既存のサービスメッシュ設定の棚卸し
  2. 並行デプロイ: 既存のサービスメッシュと並行してCiliumをインストール
  3. Namespace単位の移行: テスト環境のNamespaceから順にCiliumに移行
  4. ポリシー変換: IstioのVirtualServiceをCiliumEnvoyConfigに変換
  5. 監視期間: Hubbleメトリクスで移行後の状態を継続監視
  6. ロールバック準備: 移行中は既存のサービスメッシュ設定を保持
# カーネルバージョンの確認
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kernelVersion}{"\n"}{end}'

# 全ノードが要件を満たすか確認（5.4以上）
# 出力例:
# node-1  6.1.0-18-generic
# node-2  6.1.0-18-generic
# node-3  5.15.0-91-generic

よくある問題と解決方法を把握する

問題 原因 解決方法
Podの通信が突然切れる kube-proxyとCiliumのiptablesルールが競合 kube-proxyのDaemonSetを削除してCiliumに完全移行する
L7ポリシーが適用されない l7Proxyが無効 helm upgradeでl7Proxy=trueを設定（デフォルト有効）
Hubbleメトリクスが出力されない メトリクス設定の不備 hubble.metrics.enabledにメトリクス種別を追加
WireGuard有効化後に通信断 一部ノードのカーネルがWireGuard非対応 modprobe wireguardでカーネルモジュールをロード
Gateway APIのルートが反映されない Gateway API CRDsが未インストール kubectl apply -fでCRDsをインストール
DNS解決が遅い Ciliumの DNS proxyとCoreDNSの競合 dnsProxy.enableDnsCompression=trueを設定 
# トラブルシューティングに役立つコマンド集

# Cilium のエンドポイント一覧と状態確認
kubectl exec -n kube-system ds/cilium -- cilium endpoint list

# 特定エンドポイントの BPF ポリシーを確認
kubectl exec -n kube-system ds/cilium -- cilium bpf policy get <endpoint-id>

# Cilium のログを確認（エラーレベル）
kubectl logs -n kube-system ds/cilium --tail=100 | grep -i error

# eBPF プログラムのロード状態を確認
kubectl exec -n kube-system ds/cilium -- cilium bpf prog list

# ネットワークポリシーの適用状態を確認
kubectl exec -n kube-system ds/cilium -- cilium policy get

Cilium 1.19の新機能を活用する

2026年2月にリリースされたCilium 1.19（InfoQ）では、以下の新機能が追加されています。

Ztunnel統合（Beta）: サイドカーなしでTCP接続の透過的な暗号化と認証を実現します。Namespace単位でZtunnelに登録でき、アプリケーションの変更は不要です。

# Ztunnel 統合を有効化する例（Beta機能）
helm upgrade cilium cilium/cilium --version 1.19.1 \
  --namespace kube-system \
  --reuse-values \
  --set encryption.enabled=true \
  --set encryption.type=ztunnel

マルチクラスタのデフォルトポリシー変更: ネットワークポリシーがデフォルトでローカルクラスタにのみ適用されるようになりました。Cluster Mesh環境でのセキュリティリスクを低減する変更ですが、クラスタ間通信を許可するには明示的なポリシー設定が必要になります。

Multi Pool IPAMのStable昇格: 複雑なアドレス空間を持つ環境で、IPsecとダイレクトルーティングの両方をサポートするIPアドレス管理が安定版になりました。

注意: Ztunnel統合はBetaステータスです。本番環境での利用は十分なテストを行った上で判断してください。また、Ztunnelは元々Istio Ambientメッシュのコンポーネントであり、CiliumのZtunnel統合はIstioとの相互運用を意図した機能です。

まとめと次のステップ

まとめ:

  • CiliumはeBPFを活用してLinuxカーネルレベルでサービスメッシュ機能を実現し、サイドカーのPer-hopレイテンシ（2〜5ms）を1ms未満に削減できます
  • ベンチマーク論文によると、CiliumのCPU使用量増加は+0.12 coresで全フレームワーク中最小ですが、mTLS有効時のレイテンシ増加率は+99%であり、Istio Ambientの+8%と比較するとトレードオフがあります
  • Gateway API v1.4.1のサポートにより、Kubernetes標準に沿ったL7トラフィック管理が可能です
  • Hubbleにより、アプリケーション無変更でL3〜L7の可観測性を実現し、Prometheus/Grafanaとの連携で21種類以上のビジュアライゼーションが利用できます
  • Cilium 1.19（2026年2月リリース）では、Ztunnel統合、WireGuard厳格モード、Hubbleのドロップイベントポリシータグ付けなど、セキュリティと可観測性が強化されています

次にやるべきこと:

  • テスト環境でCilium Service Meshをインストールし、既存のワークロードとの互換性を確認する
  • Hubbleメトリクスを設定してPrometheus/Grafanaで可視化し、現状のネットワーク通信パターンを把握する
  • 段階的移行計画を策定し、まずは非本番Namespaceからの移行を開始する

参考

注意: この記事はAI（Claude Code）により自動生成されました。内容の正確性については複数の情報源で検証していますが、実際の利用時は公式ドキュメントもご確認ください。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?