eBPFによるCiliumサービスメッシュ：サイドカーレスmTLS、L7トラフィック管理、ベンチマーク

このガイドでは、Cilium Service Mesh のアーキテクチャの基礎、運用メカニズム、およびパフォーマンス特性について詳しく説明し、Kubernetes 環境における mTLS および L7 トラフィック管理に対する eBPF 駆動のサイドカーレスアプローチを強調します。

サービスメッシュのための eBPF 基盤

Cilium の根本的な利点は、eBPF (extended Berkeley Packet Filter) との深い統合に由来します。eBPF は、ネットワークパケットの受信、システムコール、カーネルトレースポイントなどのさまざまなイベントによってトリガーされる、サンドボックス化されたプログラムを Linux カーネル内で実行することを可能にします。この機能により、Cilium はネットワーキング、セキュリティ、および可観測性機能をカーネルのデータパスで直接実装でき、ユーザー空間プロキシや iptables ルールに関連する従来のオーバーヘッドを回避します。

sk_msg と sockmap を備えたカーネルネイティブデータプレーン

従来のサービスメッシュは、各アプリケーションポッドにサイドカープロキシ（例：Envoy）を挿入します。このプロキシは、すべてのインバウンドおよびアウトバウンドトラフィックを傍受し、カーネルとユーザー空間間のコンテキストスイッチ、TCP スタック処理、およびプロキシ処理によるレイテンシーを追加します。Cilium は、eBPF を利用して直接ソケット間通信を行うことで、これを軽減します。

これを可能にする主要な eBPF 機能は sk_msg と sockmap です。

• sk_msg eBPF プログラム: これらのプログラムはソケットにアタッチされ、カーネル内のソケット間でメッセージを直接リダイレクトできます。アプリケーションがデータを送信すると、sk_msg プログラムがそれを傍受し、完全な TCP/IP スタックを通過させる代わりに、同じノード上の別のアプリケーションの受信ソケットにリダイレクトできます。これにより、ネットワークスタック全体、iptables、さらにはループバックデバイスもバイパスされ、レイテンシーと CPU サイクルが大幅に削減されます。
• sockmap: ソケットへの参照を保持する特殊な eBPF マップタイプです。sk_msg プログラムは sockmap を使用して、正しい宛先ソケットを識別し、トラフィックをリダイレクトします。

ノード間通信の場合、sk_msg は物理ネットワークを直接バイパスすることはできませんが、Cilium は引き続き eBPF を使用して、カーネルレベルでパケット転送、ポリシー適用、およびロードバランシングを最適化し、iptables を完全に回避します。これにより、最小限のオーバーヘッドでトラフィックが処理される非常に効率的なデータプレーンが実現されます。

Cilium サービスメッシュアーキテクチャ

Cilium のサービスメッシュアーキテクチャは、そのハイブリッドアプローチによって特徴付けられます。L3/L4 用のデフォルトの eBPF 駆動型サイドカーレスデータプレーンと、L7 機能用の条件付き共有 Envoy プロキシです。

L3/L4 および mTLS 用のサイドカーレスデータプレーン

デフォルトでは、Cilium はすべての L3/L4 ポリシー適用、ロードバランシング、および相互 TLS (mTLS) を eBPF を使用してカーネル内で直接処理します。

• L3/L4 ポリシー適用: CiliumNetworkPolicy オブジェクトは、カーネルのネットワークスタックのできるだけ早い段階でネットワークポリシーを適用する eBPF プログラムに変換されます。これは、多数のルールで複雑になり、遅くなる可能性がある iptables チェーンよりもはるかに効率的です。
• ロードバランシング: Cilium は eBPF を使用して DSR (Direct Server Return) ベースのロードバランシングを実行し、バックエンドポッドからの戻りトラフィックがクライアントに直接送られるようにすることで、戻りパスのロードバランサーをバイパスします。これにより、パフォーマンスが向上し、ロードバランサーのボトルネックが軽減されます。
• サイドカーレス mTLS: Cilium は、ソケット層で TLS ハンドシェイクと暗号化/復号化を処理する eBPF プログラムを挿入することで mTLS を実装します。これは、アプリケーション自体が TLS を認識する必要がなく、TLS 接続を終端して再暗号化するためにユーザー空間サイドカープロキシが不要であることを意味します。eBPF プログラムは生の TCP ストリームを傍受し、TLS 操作を実行し、復号化されたストリームをアプリケーションに提示し、アウトバウンドトラフィックの場合はその逆を行います。これは重要な差別化要因であり、mTLS のためのポッドごとのサイドカープロキシのパフォーマンスペナルティと運用上の複雑さを排除します。

共有 Envoy による条件付き L7 トラフィック管理

eBPF は L3/L4 操作に優れていますが、詳細な L7 検査と操作（例：HTTP ヘッダーの変更、gRPC メソッドルーティング、高度な再試行ロジック）は複雑でリソースを大量に消費します。Cilium は、これらの機能のためにすべてのトラフィックをサイドカー経由で強制するのではなく、インテリジェントで条件付きのアプローチを採用しています。

• 共有ノードレベル Envoy デーモン: L7 CiliumNetworkPolicy がポッドに適用されると、Cilium は Kubernetes ノードに 単一の共有 Envoy プロキシ デーモンをデプロイします。この Envoy インスタンスはサイドカーではなく、ノード上で独立したプロセスとして実行され、L7 ポリシー適用を必要とするそのノード上のすべてのポッドで共有されます。
• Envoy への eBPF リダイレクト: L7 ポリシーを持つサービス宛てのトラフィックの場合、eBPF プログラムは関連する接続をノードローカルの Envoy プロキシにリダイレクトします。Envoy は L7 ポリシー（例：HTTP パスマッチング、ヘッダーベースのルーティング、レート制限）を適用し、トラフィックを転送します。
• L3/L4 トラフィックのバイパス: 重要なことに、L7 ポリシー適用を 必要としない トラフィックは、Envoy プロキシを完全にバイパスして、eBPF データプレーンを直接流れ続けます。このハイブリッドモデルにより、Envoy のパフォーマンスオーバーヘッドは厳密に必要な場合にのみ発生し、そのリソース消費はノード上の複数のポッドに償却されます。

このアーキテクチャは、両方の利点を提供します。つまり、ほとんどのトラフィックに対してカーネルレベルのパフォーマンスを提供し、必要な場合には強力な L7 機能を提供しますが、ポッドごとのサイドカーによる広範なオーバーヘッドはありません。

コントロールプレーン

Cilium コントロールプレーンは以下で構成されます。

• Cilium Agent: 各 Kubernetes ノードで DaemonSet として実行されます。eBPF データプレーンをプログラムし、ポリシーを適用し、ノードローカルの Envoy プロキシのライフサイクルを管理します。
• Cilium Operator: Deployment として実行され、IP アドレス管理 (IPAM)、CiliumNetworkPolicy オブジェクトの管理、クラスター全体の整合性の確保など、クラスター全体のタスクを処理します。
• Kubernetes API Server: Cilium は Kubernetes とシームレスに統合し、CiliumNetworkPolicy、CiliumClusterWideNetworkPolicy、CiliumService などのカスタムリソース定義 (CRD) を使用してその動作を定義および管理します。

Cilium サービスメッシュの構成

このセクションでは、mTLS および L7 トラフィック管理のために Cilium を構成する実践的な例を示します。

インストール

Cilium は Helm 経由でインストールできます。Kubernetes クラスターが eBPF カーネル要件（基本的な機能には Linux カーネル 4.9 以降、サービスメッシュの sockmap や sk_msg などの高度な機能には 5.10 以降）を満たしていることを確認してください。

helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium --version 1.15.0 \
  --namespace kube-system \
  --set ipam.mode=kubernetes \
  --set egressGateway.enabled=true \
  --set hubble.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.relay.enabled=true \
  --set serviceMesh.enabled=true \
  --set serviceMesh.mtls.enabled=true \
  --set serviceMesh.mtls.certProvider.certgen.enabled=true \
  --set serviceMesh.mtls.certProvider.certgen.provisionCertificates=true \
  --set serviceMesh.proxy.enabled=true \
  --set serviceMesh.proxy.envoy.enabled=true \
  --set serviceMesh.proxy.envoy.resources.requests.cpu="100m" \
  --set serviceMesh.proxy.envoy.resources.requests.memory="128Mi" \
  --set serviceMesh.proxy.envoy.resources.limits.cpu="500m" \
  --set serviceMesh.proxy.envoy.resources.limits.memory="512Mi" \
  --set k8sServiceHost=$(kubectl get nodes -o jsonpath='{.items[0].status.addresses[?(@.type=="InternalIP")].address}') \
  --set k8sServicePort=$(kubectl get service kubernetes -n default -o jsonpath='{.spec.ports[0].port}')

この Helm コマンドは、組み込みの証明書プロバイダーによる mTLS や共有 Envoy プロキシを含むサービスメッシュ機能を有効にします。Envoy のリソース要求/制限は、クラスターのニーズに基づいて調整してください。

CiliumNetworkPolicy による相互 TLS の適用

サービス間で mTLS を適用するには、必要な認証を指定する CiliumNetworkPolicy を定義します。Cilium は、メッシュ内のサービスの証明書発行とローテーションを自動的に処理します。

default 名前空間に frontend と backend の 2 つのサービスがあるとします。frontend が backend と mTLS を使用してのみ通信するようにしたいとします。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "backend-mtls-policy"
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    authentication:
      mode: required
  egress:
  - toEndpoints:
    - matchLabels:
        app: frontend
    authentication:
      mode: required

このポリシーは backend ポッドに適用され、frontend ポッドからのイングレストラフィックは相互認証される 必要がある ことを規定します。同様に、エグレスルールは backend が frontend と通信するときに mTLS を開始することを保証します。Cilium の eBPF プログラムはこれをソケット層で適用し、認証されていない接続を拒否します。

CiliumNetworkPolicy による L7 トラフィック管理

L7 ポリシーの場合、Cilium は共有 Envoy プロキシを利用します。ここでは、frontend が backend 上の特定のパスにアクセスすることを許可し、HTTP メソッドの制限を適用するポリシーを定義します。

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "backend-l7-policy"
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/data"
        - method: "POST"
          path: "/api/v1/submit"
          headers:
          - "X-Request-ID"
          - "Content-Type"

この例では：

• endpointSelector は backend ポッドをターゲットとします。
• ingress ルールは、frontend ポッドから backend のポート 8080 へのトラフィックが L7 HTTP ルールの対象となることを指定します。
• rules.http セクションは、許可される HTTP メソッドとパスを定義します。また、ヘッダーの存在チェック（headers フィールド）も示しています。

このポリシーが適用されると、Cilium は L7 ルールを検出し、ノードローカルの Envoy プロキシを構成して、frontend と backend 間のトラフィックに対してこれらの HTTP ポリシーを傍受および適用します。これらのルールに一致しないトラフィック、または backend のポート 8080 宛てではないトラフィックは、Envoy の介入なしに eBPF データプレーンを流れ続けます。

イングレス/エグレスゲートウェイ

Cilium はイングレスまたはエグレスゲートウェイとしても機能し、メッシュに出入りするトラフィックの統一された制御ポイントを提供します。これは、外部通信に一貫したポリシー、mTLS、および可観測性を適用する場合に特に役立ちます。

apiVersion: "cilium.io/v2"
kind: CiliumEgressGatewayPolicy
metadata:
  name: "egress-to-external-db"
  namespace: default
spec:
  selectors:
  - podSelector:
      matchLabels:
        app: my-app
  destinationCIDRs:
  - "192.0.2.0/24" # Example external database CIDR
  egressGateway:
    nodeSelector:
      matchLabels:
        egress-gateway: "true" # Label your gateway node

この CiliumEgressGatewayPolicy は、app: my-app というラベルの付いたポッドからのすべてのエグレストラフィックを、指定されたエグレスゲートウェイノードを介して 192.0.2.0/24 CIDR に転送します。これにより、外部トラフィックに対する集中型ポリシー適用、IP マスカレード、および可観測性が可能になります。

パフォーマンスベンチマークとトレードオフ

サービスメッシュソリューションのベンチマークは、その運用上の影響を理解するために不可欠です。Cilium の eBPF 駆動型アーキテクチャは、特に L3/L4 トラフィックの場合、従来のサイドカーベースのメッシュと比較して、一貫して優れたパフォーマンス特性を示します。

方法論

ベンチマークには通常以下が含まれます。

• スループット: 単位時間あたりに転送されるデータ量（例：Gbps）または HTTP/gRPC の 1 秒あたりのリクエスト数（RPS）を測定します。iperf3、wrk、fortio などのツールを使用します。
• レイテンシー: リクエストが完了するまでにかかる時間（例：P99 レイテンシー（ミリ秒））を測定します。
• リソース消費: データプレーンコンポーネント（サイドカー、Cilium エージェント、Envoy デーモン）の CPU およびメモリ使用量を監視します。

テストシナリオにはしばしば以下が含まれます。

• ノード内通信: 同じ Kubernetes ノード上のポッド間通信。これは sk_msg が最も大きな利点を提供する場所です。
• ノード間通信: 異なる Kubernetes ノード間のポッド間通信。
• mTLS オーバーヘッド: 暗号化/復号化の影響を測定します。
• L7 ポリシーオーバーヘッド: HTTP/gRPC ポリシー適用の影響を測定します。

ベンチマーク比較表

次の表は、さまざまな業界ベンチマークと Cilium 独自のパフォーマンスレポートの結果を統合した、代表的なパフォーマンスメトリックを示しています。実際の数値は、ハードウェア、カーネルバージョン、ワークロード、およびネットワーク条件によって異なります。

分析

• レイテンシー: Cilium の eBPF データプレーンは、sk_msg を利用してネットワークスタックをバイパスすることで、特にノード内通信のレイテンシーを大幅に削減します。ノード間トラフィックの場合でも、eBPF ベースの転送は iptables やサイドカープロキシよりも効率的です。L7 ポリシーがアクティブな場合、共有 Envoy へのリダイレクトにより多少のレイテンシーが発生しますが、L7 以外のトラフィックに対する最適化された eBPF パスと、単一の Envoy インスタンスの償却コストにより、ポッドごとのサイドカーよりも一般的に低くなります。
• スループット: カーネルネイティブのデータパスにより、Cilium はより高い生の TCP スループットを実現できます。L7 トラフィックの場合、共有 Envoy は依然としてかなりの RPS を処理でき、競合の減少とリソース利用の最適化により、ポッドごとのサイドカーよりも優れていることがよくあります。
• リソース消費: これが Cilium の強みです。ほとんどのトラフィックでポッドごとのサイドカーを排除することで、クラスター全体の CPU とメモリの総フットプリントを劇的に削減します。共有 Envoy デーモンのリソースは、ポッドごとではなくノードごとに 1 回消費されるため、大規模なデプロイメントで大幅な節約につながります。
• 運用上の複雑さ: 単一の Cilium エージェントとノードごとの条件付き Envoy を管理することは、それぞれ独自のライフサイクル、構成、およびリソース要件を持つ数百または数千のサイドカープロキシを管理するよりも本質的に単純です。

よくある落とし穴と本番環境での問題点

サービスメッシュ、特に Cilium のようにカーネルと深く統合されたものをデプロイおよび運用するには、独自の課題があります。

1. カーネルバージョンの要件:

   • 落とし穴: 古い Linux カーネルバージョン（例：5.10 未満）で Cilium を実行すると、sockmap や sk_msg のような特定の高度な eBPF 機能が利用できないか、最適化されていない可能性があります。これにより、パフォーマンスが低下したり、特定のサービスメッシュ機能が動作しなくなったりする可能性があります。
   • 問題点: デプロイ前にすべてのノードでカーネルバージョンを検証しないと、一貫性のない動作や機能のギャップにつながる可能性があります。
   • 対策: Cilium のドキュメントで最小および推奨カーネルバージョンを常に確認してください。eBPF 機能の可用性を診断するには cilium status と cilium sysdump を使用してください。カーネルのアップグレードは慎重に計画してください。

2. CiliumNetworkPolicy の複雑さ:

   • 落とし穴: 広すぎる、または特定しすぎたポリシーは、予期しないトラフィックのドロップや意図しないアクセスを許可する可能性があります。特に複雑な正規表現やヘッダーマッチングを使用する L7 ポリシーは、デバッグが困難な場合があります。
   • 問題点: ステージング環境で徹底的なテストを行わずにポリシーを適用すること。dry-run や audit モードを使用しないこと。
   • 対策: 寛容なポリシーから始めて、徐々に厳しくしてください。ポリシー評価を理解するには cilium policy get と cilium policy trace を使用してください。ポリシー決定とドロップされた接続のリアルタイム可視性のために Hubble を活用してください。

3. 共有 Envoy のリソース競合:

   • 落とし穴: 共有 Envoy は効率的ですが、多数の L7 対応ポッドと高いトラフィック量を持つノードでは、共有 Envoy の CPU またはメモリ制限を使い果たし、パフォーマンスの低下やクラッシュにつながる可能性があります。
   • 問題点: 共有 Envoy プロキシのリソース（Helm 値の serviceMesh.proxy.envoy.resources）を過小にプロビジョニングすること。
   • 対策: 共有 Envoy デーモンのリソース使用量（例：kubectl top pod -n kube-system -l k8s-app=cilium-envoy）を監視してください。観測された負荷に基づいてリソース要求/制限を調整してください。必要に応じて、L7 ヘビーなワークロードをより多くのノードに分散してください。

4. eBPF プログラムのデバッグ:

   • 落とし穴: eBPF プログラムはカーネル内で実行されるため、ユーザー空間アプリケーションよりもデバッグが困難です。eBPF プログラムのエラーは、カーネルパニックや予期しないネットワーク動作につながる可能性があります。
   • 問題点: eBPF ツールやカーネルデバッグ技術に不慣れであること。
   • 対策: Cilium は Hubble のような優れた可観測性ツールを提供しています。洞察を得るには cilium monitor、cilium status、cilium debug を使用してください。より深い問題については、bpftool とカーネルログ（dmesg）が不可欠です。トラブルシューティング時には、Cilium エージェントの debug ロギングが有効になっていることを確認してください。

5. 他のネットワークコンポーネントとの相互作用:

   • 落とし穴: Cilium は CNI です。Cilium と並行して別の CNI プラグインを実行することは一般的にサポートされておらず、競合につながります。
   • 問題点: 適切な理解なしに、既存の iptables ルールや他のネットワークオーバーレイと Cilium を統合しようとすること。
   • 対策: Cilium は唯一の CNI であるべきです。別の CNI から移行する場合は、公式の移行ガイドに従ってください。Cilium が kube-proxy の置き換えと hostPort サービスをどのように処理するかを理解してください。

6. mTLS 証明書管理:

   • 落とし穴: Cilium は mTLS 証明書管理を自動化しますが、証明書プロバイダー（例：certgen または Vault/SPIFFE との統合）の問題により、サービスが mTLS 接続を確立できない場合があります。
   • 問題点: 証明書のローテーションや有効性を監視しないこと。
   • 対策: Cilium エージェントのログで証明書関連のエラーを監視してください。選択した証明書プロバイダーが正しく構成され、必要な権限を持っていることを確認してください。

7. 可観測性のギャップ:

   • 落とし穴: Hubble は優れたネットワーク可観測性を提供しますが、従来のサイドカーメッシュがデフォルトで公開する可能性のあるすべてのアプリケーションレベルのメトリックやトレース（例：HTTP ステータスコード、プロキシの視点からのリクエスト期間）をカバーしない場合があります。
   • 問題点: アプリケーションパフォーマンス監視のために Cilium のネットワーク可観測性のみに依存すること。
   • 対策: 包括的な可観測性のために、アプリケーションレベルの計測（例：Prometheus、OpenTelemetry）で Hubble を補完してください。Cilium が公開するメトリックと、アプリケーション自体から収集する必要があるものを理解してください。

よくある質問 (FAQ)

Cilium Service Mesh とは何ですか？

Cilium Service Mesh は、Kubernetes ネイティブのサービスメッシュソリューションであり、Linux カーネルの eBPF (extended Berkeley Packet Filter) を活用して、マイクロサービスに高性能なネットワーキング、セキュリティ、および可観測性を提供します。従来のサイドカーベースのアーキテクチャと比較して、大幅にオーバーヘッドを削減してサービスメッシュ機能を提供することを目指しています。

Cilium はどのようにしてサイドカーレスサービスメッシュを実現していますか？

Cilium は、L3/L4 ポリシー適用、ロードバランシング、および相互 TLS (mTLS) を Linux カーネル内で eBPF プログラムを使用して直接実装することで、サイドカーレスサービスメッシュを実現しています。これにより、これらのコア機能のためにポッドごとのユーザー空間サイドカープロキシが不要になり、レイテンシーとリソース消費が削減されます。

eBPF における sk_msg とは何ですか？

sk_msg は、Linux カーネル内のソケット間でメッセージを直接リダイレクトできる eBPF プログラムタイプです。アプリケーションがデータを送信すると、sk_msg プログラムがそれを傍受し、同じノード上の別のアプリケーションの受信ソケットにリダイレクトできます。これにより、従来の TCP/IP スタック、iptables、およびループバックデバイスを完全にバイパスします。これにより、ノード内通信のレイテンシーが大幅に削減されます。

Cilium はいつ Envoy を使用しますか？

Cilium は、高度なレイヤー 7 (L7) トラフィック管理ポリシー（例：HTTP パスルーティング、ヘッダー操作、gRPC メソッドマッチング）が CiliumNetworkPolicy を介して明示的に構成されている場合にのみ Envoy を使用します。Cilium は、Envoy をポッドごとのサイドカーとしてデプロイする代わりに、各 Kubernetes ノードで単一の共有 Envoy プロキシデーモンを実行します。eBPF プログラムは、L7 検査を必要とするトラフィックのみをこのノードローカルの Envoy にインテリジェントにリダイレクトし、他のすべてのトラフィックは高性能な eBPF データプレーンを流れ続けます。

Cilium は CNI ですか、それともサービスメッシュですか？

Cilium は、コンテナネットワークインターフェース (CNI) プラグインであり、サービスメッシュでもあります。Kubernetes の主要な CNI として機能し、ネットワーキングとネットワークポリシー適用を提供します。CNI 機能に基づいて、Cilium は eBPF を利用した mTLS、L7 トラフィック管理、高度な可観測性などのサービスメッシュ機能を提供するために機能を拡張しています。

Cilium Service Mesh のパフォーマンス上の利点は何ですか？

Cilium Service Mesh は、次のような重要なパフォーマンス上の利点を提供します。

• 低レイテンシー: ノード内通信では eBPF sk_msg を使用してネットワークスタックをバイパスし、ノード間トラフィックでは最適化されたカーネルレベル処理により実現されます。
• 高スループット: 直接カーネルデータパスにより、より高いデータ転送速度が可能になります。
• リソース消費の削減: ほとんどのトラフィックでポッドごとのサイドカープロキシが不要になり、クラスター全体の CPU とメモリを大幅に節約できます。
• 効率的な mTLS: カーネルレベルの mTLS は、ユーザー空間プロキシから暗号化/復号化をオフロードし、パフォーマンスを向上させます。

Cilium はマルチクラスターをサポートしていますか？

はい、Cilium はマルチクラスターデプロイメントをサポートしています。Cluster Mesh のような機能を提供し、複数の Kubernetes クラスター間でシームレスな接続、ポリシー適用、サービスディスカバリを可能にし、それらを単一の論理ネットワークとして扱います。これは、安全な暗号化されたトンネルとクラスター間の共有 ID を通じて実現されます。

結論

Cilium Service Mesh は、Kubernetes 内でサービスメッシュ機能が提供される方法におけるパラダイムシフトを表しています。eBPF の力を活用することで、Cilium は従来のサイドカーベースのメッシュに代わる、高性能でリソース効率が高く、運用がよりシンプルなソリューションを提供します。カーネルネイティブのデータプレーンをデフォルトとし、L7 のために共有 Envoy プロキシを条件付きで採用するインテリジェントなハイブリッドアーキテクチャにより、パフォーマンスオーバーヘッドは厳密に必要な場合にのみ発生します。マイクロサービスアーキテクチャにおいて、低レイテンシー、高スループット、および運用コストの削減を優先する組織にとって、eBPF を備えた Cilium Service Mesh は、魅力的で将来性のあるソリューションを提供します。