Istio Ambient MeshとSidecarアーキテクチャ: メモリオーバーヘッド、Ztunnel、ゼロトラストセキュリティ

Istioは、Kubernetesにおけるサービスメッシュのデファクトスタンダードとして、その機能をアプリケーションワークロードに拡張するために、従来サイドカーインジェクションモデルに依存してきました。このモデルは効果的である一方で、運用上およびリソース上の大きなオーバーヘッドを伴います。Istio Ambient Meshは、レイヤー4（L4）とレイヤー7（L7）の懸念事項を明確に最適化されたコンポーネントに分離することで、これらの課題に対処することを目的とした根本的なアーキテクチャの転換を表しています。このガイドでは、両モデルのアーキテクチャのニュアンス、パフォーマンスへの影響、およびセキュリティ体制を詳細に比較する包括的な技術比較を提供します。

Istioサイドカーアーキテクチャ：従来のモデル

従来のIstioサイドカーアーキテクチャは、メッシュ内のすべてのアプリケーションPodにEnvoyプロキシコンテナを注入することで動作します。このEnvoyプロキシは、アプリケーションコンテナのすべてのインバウンドおよびアウトバウンドネットワークトラフィックを傍受し、Istioコントロールプレーン（Istiod）によって定義されたポリシーを適用します。

サイドカーの機能

1. インジェクション（Injection）: メッシュが有効な名前空間でPodが作成されると、IstioのミューティングアドミッションWebhookがPod作成リクエストを傍受します。Podマニフェストを修正して、initContainer（iptables構成用）とenvoyコンテナ（サイドカープロキシ）を含めます。
2. トラフィック傍受（Traffic Interception）: initContainerは、Podのネットワーク名前空間内にiptablesルールを設定します。これらのルールは、アプリケーションコンテナとの間のすべてのインバウンドおよびアウトバウンドTCPトラフィックをEnvoyサイドカー経由でリダイレクトします。
3. ポリシー適用（Policy Enforcement）: Istiodによって継続的に構成されるEnvoyサイドカーは、幅広いポリシーを適用します。
   • mTLS: すべてのサービス間通信に対する自動相互TLS。
   • トラフィック管理（Traffic Management）: ルーティングルール、リトライ、タイムアウト、サーキットブレーキング、フォールトインジェクション。
   • 認可（Authorization）: ID、送信元、送信先に基づくアクセス制御ポリシー。
   • テレメトリー（Telemetry）: 可観測性のためのメトリクス、ログ、トレースの収集。

サイドカーモデルの利点

• きめ細かな制御（Granular Control）: ポリシーは個々のPodレベルで適用され、各ワークロードのトラフィックをきめ細かく制御できます。
• 分離（Isolation）: 各サイドカーは独立して動作し、ポリシー適用とリソース消費にある程度の分離を提供します。
• 成熟した機能セット（Mature Feature Set）: サイドカーモデルは長年Istioの基盤となっており、堅牢でよく理解された機能セットにつながっています。

欠点と運用上の課題

サイドカーモデルには利点がある一方で、いくつかの重大な課題があります。

1. リソースオーバーヘッド（Resource Overhead）: 各EnvoyサイドカーはCPUとメモリリソースを消費します。数百または数千のPodを持つ高密度なクラスターでは、この総オーバーヘッドはかなりのものになり、インフラコストの増加やアプリケーションワークロードのためのクラスター容量の減少につながる可能性があります。
   • 一般的なEnvoyサイドカーは、アイドル状態でも50-100MBのRAMと0.05-0.1 CPUコアを消費する可能性があります。
2. 運用上の複雑さ（Operational Complexity）:
   • インジェクション管理（Injection Management）: サイドカーのインジェクション、除外、構成のオーバーライドの管理は複雑になる可能性があります。
   • アプリケーション認識（Application Awareness）: アプリケーションは、特に起動およびシャットダウンシーケンス中に、サイドカーの存在を許容するように設計する必要があります。
3. アップグレードの複雑さ（Upgrade Complexity）: Istioのアップグレードには、サイドカープロキシを更新するためにすべてのアプリケーションPodを再起動する必要があることがよくあります。これはサービスの中断につながる可能性があり、慎重なロールアウト戦略が必要です。
4. ネットワークパフォーマンス（Network Performance）: 一般的に効率的ですが、サイドカーを介した追加のホップは、わずかなレイテンシーを発生させる可能性があります。
5. デバッグ（Debugging）: トラフィックが追加のプロキシレイヤーを通過するため、ネットワークの問題のデバッグはより複雑になります。

サイドカーPodの例

注入されたサイドカーを持つPodを観察します。istio-proxyコンテナに注目してください。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld-v1
  labels:
    app: helloworld
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
      version: v1
  template:
    metadata:
      labels:
        app: helloworld
        version: v1
    spec:
      containers:
      - name: helloworld
        image: docker.io/istio/examples-helloworld-v1
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"

Istioが有効な名前空間にデプロイした後、Podを検査すると注入されたサイドカーが明らかになります。

kubectl get pod helloworld-v1-xxxxxxxxx-yyyyy -o yaml

出力スニペット：

...
spec:
  containers:
  - name: helloworld
    image: docker.io/istio/examples-helloworld-v1
    # ... application container details ...
  - name: istio-proxy
    image: docker.io/istio/proxyv2:1.20.0 # Example Istio version
    args:
    - proxy
    - sidecar
    - --domain
    - $(POD_NAMESPACE).svc.cluster.local
    - --configPath
    - /etc/istio/proxy
    - --binaryPath
    - /usr/local/bin/envoy
    # ... other Envoy configuration ...
    resources:
      requests:
        cpu: 10m
        memory: 128Mi # Example resource request for sidecar
      limits:
        cpu: 2
        memory: 1Gi
    # ...
  initContainers:
  - name: istio-init
    image: docker.io/istio/proxyv2:1.20.0
    args:
    - istio-iptables
    - -p
    - "15001"
    - -z
    - "15006"
    - -u
    - "1337"
    - -m
    - REDIRECT
    - -i
    - '*'
    - -x
    - ""
    - -b
    - '*'
    - -d
    - "15090,15021,15020"
    # ...

この出力は、istio-proxyコンテナとistio-init initContainerを明確に示しており、サイドカーのインジェクションを確認しています。

Istio Ambient Meshアーキテクチャ：パラダイムシフト

Istio Ambient Meshはサイドカーレスなアプローチを導入し、サービスメッシュ機能の提供方法を根本的に変革します。これは、L4とL7の機能を2つの異なるオプションのレイヤー、すなわちノードレベルのztunnelと名前空間/サービスアカウントレベルのwaypoint proxiesに分離することで実現されます。このアーキテクチャは、大幅に削減されたオーバーヘッドでユビキタスなL4セキュリティとオプションのL7ポリシー適用を提供することを目指しています。

2層アーキテクチャ

1. Ztunnel: ノードレベルのL4プロキシ

ztunnelは、Kubernetesクラスター内のすべてのノードにDaemonSetとしてデプロイされる軽量で高性能なプロキシです。その主な責任は、メッシュ内のすべてのL4トラフィックに対して安全なmTLS暗号化接続を確立および管理することです。

• 機能:

  • L4 mTLS: ztunnelは、ノード上のアプリケーションPodとの間のすべてのTCPトラフィックを傍受し、自動的に相互TLS（mTLS）にアップグレードします。これにより、アプリケーションの変更やサイドカーのインジェクションを必要とせずに、すべての通信に対してゼロトラストセキュリティの基盤レイヤーが提供されます。
  • ID（Identity）: ワークロードIDを処理し、すべてのmTLS接続が検証済みID間で確立されることを保証します。
  • 認可（Authorization）: 基本的なL4認可ポリシーはztunnelによって適用できます。
  • HBONEプロトコル（HBONE Protocol）: ztunnelはHTTPベースオーバーレイネットワーク環境（HBONE）プロトコルを利用します。HBONEはTCPストリームをHTTP/2上にカプセル化し、ztunnelが異なるノード上のztunnels間で単一の永続的なHTTP/2接続を介して複数のmTLS接続を多重化できるようにします。これにより、接続オーバーヘッドが削減され、効率が向上します。
  • トラフィック傍受（Traffic Interception）: サイドカーと同様に、ztunnelはiptables（または将来のイテレーションではeBPF）を使用して、ノード上のPodからのトラフィックを自身を介してリダイレクトします。

• デプロイモデル（Deployment Model）: ztunnelはDaemonSetとして実行され、ノードごとに1つのインスタンスを意味します。そのリソース消費は、そのノード上のすべてのPodに償却されます。

• 利点:

  • ユビキタスなL4セキュリティ（Ubiquitous L4 Security）: メッシュ内のすべてのトラフィックはデフォルトでmTLSを取得し、Podごとのオーバーヘッドなしで強力なセキュリティベースラインを提供します。
  • リソースフットプリントの削減（Reduced Resource Footprint）: すべてのPodにサイドカーを必要としないため、アプリケーションワークロードごとのメモリとCPUのオーバーヘッドが大幅に削減されます。
  • 運用上の簡素化（Operational Simplicity）: ztunnelのアップグレードはPodレベルではなくノードレベルであるため、メッシュのアップグレードが簡素化され、アプリケーションの再起動が回避されます。
  • アプリケーションの透過性（Application Transparency）: アプリケーションはztunnelの存在を完全に認識しません。

2. Waypointプロキシ: 名前空間レベルのL7プロキシ

Waypointプロキシは、特定のワークロードまたは名前空間でL7ポリシー適用が必要な場合にのみデプロイされる専用のEnvoyプロキシです。これらはアプリケーションPodに注入されるのではなく、高度なL7機能を必要とするトラフィックの中間役として機能します。

• 機能:

  • L7ポリシー適用（L7 Policy Enforcement）: Waypointプロキシは、トラフィックルーティング（例：カナリアデプロイメント、A/Bテスト）、HTTPリトライ、タイムアウト、サーキットブレーキング、フォールトインジェクション、L7認可などの高度なL7ポリシーを処理します。
  • テレメトリー（Telemetry）: 詳細なL7メトリクス、ログ、トレースを収集します。
  • デプロイ（Deployment）: Waypointプロキシは通常、サービスアカウントごと、または名前空間ごとにデプロイされます。これは標準的なKubernetes DeploymentまたはStatefulSetです。

• Waypointプロキシによるトラフィックフロー:

  1. アプリケーションPodが宛先にトラフィックを送信します。
  2. 送信元ノードのztunnelがトラフィックを傍受し、宛先ノードのztunnelへのmTLS HBONE接続を確立します。
  3. 宛先ワークロードがL7ポリシーを必要とする場合（つまり、Waypointプロキシが構成されている場合）、宛先ztunnelはトラフィックをWaypointプロキシに転送します。
  4. WaypointプロキシはL7ポリシーを適用し、実際の宛先アプリケーションPodにトラフィックを転送します。
  5. 宛先アプリケーションPodは、Waypointプロキシの存在を認識せずにトラフィックを受信します。

• 利点:

  • オプトインL7（Opt-in L7）: L7機能は必要な場合にのみ有効になり、単純なサービスに対する不要なオーバーヘッドを回避します。
  • 分離（Isolation）: Waypointプロキシは、アプリケーションワークロードとは独立してスケーリングおよび管理できます。
  • 明確な関心事の分離（Clear Separation of Concerns）: L4とL7の責任は明確に分離されています。

Ambient Meshトラフィックフロー図（概念図）

Ambient Meshコンポーネントの例

Ztunnel DaemonSet:

kubectl get daemonset -n istio-system ztunnel

出力スニペット：

NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ztunnel   3         3         3       3            3           <none>          2d

これは、ztunnelがistio-system名前空間の3つのノードで実行されていることを示しています。

Waypointプロキシのデプロイ:

まず、特定のサービスアカウントまたは名前空間に対して、タイプwaypointのGatewayリソースを定義します。

# waypoint-proxy.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: default-waypoint
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

これをデプロイすると、default名前空間のdefaultサービスアカウント用のWaypointプロキシが作成されます。

kubectl apply -f waypoint-proxy.yaml

次に、作成されたデプロイを観察できます。

kubectl get deployment -n default istio-waypoint-default-waypoint

出力スニペット：

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
istio-waypoint-default-waypoint   1/1     1            1           5m

このデプロイは、default名前空間のdefaultサービスアカウントに関連付けられたワークロードのL7ポリシーを処理するEnvoyプロキシを実行します。

メモリオーバーヘッドとパフォーマンスベンチマーク

Ambient Meshの主な推進要因は、リソースオーバーヘッドの削減です。サイドカーモデルのPodごとのリソース消費はPodの数に比例して増加し、大規模なクラスターではすぐにボトルネックになります。Ambient Meshはこの方程式を大幅に変更します。

メモリオーバーヘッド

• サイドカーモデル: 各Envoyサイドカーは通常、50-100 MiBのRAM（アイドル時）を消費し、負荷がかかるとさらに高くなる可能性があります。1000個のPodを持つクラスターの場合、これはサイドカーだけで50-100 GiBのRAMに相当します。
• Ambient Mesh:
  • Ztunnel: ztunnelインスタンスは、ノードあたり約100-200 MiBのRAMを消費します。このオーバーヘッドは、そのノード上のすべてのPodに償却されます。ノードが50個のPodをホストする場合、L4セキュリティのPodごとのオーバーヘッドは2-4 MiBに減少します。
  • Waypointプロキシ: Waypointプロキシは、デプロイされると、単一のサイドカーと同様のリソース（例：50-100 MiB RAM）を消費します。ただし、これらはL7ポリシーが必要な場合にのみデプロイされ、複数のワークロードまたは名前空間全体にサービスを提供できるため、コストがさらに償却されます。

メモリ節約の例: 20個のアプリケーションPodを持つノードを考えます。

• サイドカー: 20個のPod * 75 MiB/サイドカー = 1500 MiB (1.5 GiB)
• Ambient: 1個のztunnel (150 MiB) + 1個のwaypoint (75 MiB、L7がすべてに必要と仮定) = 225 MiB。
  • これは、このシナリオでノードあたり1.2 GiB以上のRAMの節約を表します。多数のノードを持つクラスターでは、これはアプリケーションワークロードのために数百ギガバイトのメモリが解放されることを意味します。

CPU使用率

• サイドカーモデル: 各サイドカーは、トラフィック傍受、mTLSネゴシエーション、ポリシー評価、テレメトリーのためにCPUサイクルを消費します。アイドル状態のサイドカーは0.05-0.1 CPUコアを消費する可能性があります。
• Ambient Mesh:
  • Ztunnel: ztunnelはL4処理に高度に最適化されています。ノードあたり0.1-0.2 CPUコアを消費する可能性がありますが、これも償却されます。
  • Waypointプロキシ: サイドカーと同様に、Waypointプロキシはアクティブなときに0.05-0.1 CPUコアを消費する可能性がありますが、L7が有効なトラフィックに対してのみです。

Ambient Meshでは、特にL4セキュリティのみを必要とするワークロードの場合、全体的なCPUフットプリントは一般的に低くなります。

レイテンシーへの影響

• サイドカーモデル: トラフィックは、mTLSおよびL7ポリシーのために2つのEnvoyプロキシ（送信元サイドカー、宛先サイドカー）を通過します。各ホップは、完全なL7パスの場合、リクエストあたり通常0.5-1.5 msのわずかなレイテンシーを追加します。
• Ambient Mesh:
  • L4のみ: トラフィックは送信元ztunnelと宛先ztunnelを通過します。HBONEプロトコルは効率的です。レイテンシーオーバーヘッドは通常0.2-0.8 msです。
  • L7有効: トラフィックは送信元ztunnel、宛先ztunnel、そしてWaypointプロキシを通過します。これはL4のみと比較して追加のホップを追加しますが、ztunnelの効率とWaypointプロキシの専用性により、全体的なパスはサイドカーと同等か、わずかに優れていることがよくあります。レイテンシーオーバーヘッドは通常0.6-1.2 msです。

包括的な比較表：サイドカー vs. Ambient Mesh

| 機能 / メトリクス | Istioサイドカーアーキテクチャ | Istio Ambient Meshアーキテクチャ |