Istioトラフィック管理の実践 — VirtualServiceからカナリア自動化まで

                       (メッシュ外部から入るトラフィック)
                                  |
                                  v
                   +-----------------------------+
                   | Gateway                     |
                   | 「どのポート/ホスト/TLSで     |
                   |  トラフィックを受けるか」     |
                   +-----------------------------+
                                  |  (ホストマッチングで接続)
                                  v
+---------------------------------------------------------------+
| VirtualService                                                |
| 「受けたリクエストをどこへ、どのように送るか」                     |
|  - マッチング: パス/ヘッダー/メソッド/クエリ                     |
|  - 動作: 重み付け分配、リダイレクト、リライト、リトライ、          |
|          タイムアウト、フォールトインジェクション、ミラーリング     |
+---------------------------------------------------------------+
            |                                   |
            | (ホストのsubsetを指定)              | (外部ホストへルーティング)
            v                                   v
+---------------------------+      +---------------------------+
| DestinationRule           |      | ServiceEntry              |
| 「宛先に到着した後のポリシー」 |      | 「メッシュ外部サービスを     |
|  - subset定義(バージョンラベル)|     |  サービスレジストリに登録」  |
|  - ロードバランシングアルゴリズム|    |  - 外部API、レガシーDBなど  |
|  - コネクションプール、外れ値検出|    +---------------------------+
|  - TLS設定(アップストリーム)  |
+---------------------------+

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
  namespace: bookinfo
spec:
  host: reviews.bookinfo.svc.cluster.local
  subsets:
    - name: v1
      labels:
        version: v1     # Podラベルとマッチング
    - name: v2
      labels:
        version: v2
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
  namespace: bookinfo
spec:
  hosts:
    - reviews.bookinfo.svc.cluster.local
  http:
    - route:
        - destination:
            host: reviews.bookinfo.svc.cluster.local
            subset: v1
          weight: 90
        - destination:
            host: reviews.bookinfo.svc.cluster.local
            subset: v2
          weight: 10

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews-routing
  namespace: bookinfo
spec:
  hosts:
    - reviews.bookinfo.svc.cluster.local
  http:
    # ルール1: 社内QAヘッダーがあれば常にv2へ (最も具体的 — 一番上)
    - match:
        - headers:
            x-qa-user:
              exact: "true"
      route:
        - destination:
            host: reviews.bookinfo.svc.cluster.local
            subset: v2
    # ルール2: 特定パス + GETのみv2候補に
    - match:
        - uri:
            prefix: /api/v2/
          method:
            exact: GET
      route:
        - destination:
            host: reviews.bookinfo.svc.cluster.local
            subset: v2
    # ルール3: catch-all — 必ず最後に
    - route:
        - destination:
            host: reviews.bookinfo.svc.cluster.local
            subset: v1

# AND: パスが/adminで、かつヘッダーがあればマッチ
    - match:
        - uri:
            prefix: /admin
          headers:
            x-role:
              exact: admin
# OR: パスが/adminであるか、またはヘッダーがあればマッチ
    - match:
        - uri:
            prefix: /admin
        - headers:
            x-role:
              exact: admin

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: payments-api
  namespace: payments
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payments-api
  service:
    port: 8080
    gateways:
      - istio-system/public-gateway
    hosts:
      - payments.example.com
  analysis:
    interval: 1m          # 1分ごとにメトリクスを評価
    threshold: 5          # 5回連続失敗でロールバック
    maxWeight: 50         # カナリアの最大重み
    stepWeight: 10        # ステップごとに10%ずつ増加
    metrics:
      - name: request-success-rate
        thresholdRange:
          min: 99         # 成功率99%未満なら失敗カウント
        interval: 1m
      - name: request-duration
        thresholdRange:
          max: 500        # p99が500ms超過なら失敗カウント
        interval: 1m
    webhooks:
      - name: load-test           # トラフィックが少ない時間帯に備えた合成負荷
        url: http://flagger-loadtester.test/
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://payments-api-canary.payments:8080/healthz"

1. 新イメージ検知 → payments-api-canary Deploymentを作成
2. 重み10% → 1分間成功率/レイテンシを評価 → 通過なら20% → ... → 50%
3. 全ステップ通過 → primaryを新バージョンに置き換え、カナリアの重みを0%に
4. どのステップでもthreshold(5回)連続失敗 → 重み0%へ即時ロールバック
   → Deploymentはそのまま残すので原因分析が可能

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payments-api
  namespace: payments
spec:
  replicas: 5
  strategy:
    canary:
      trafficRouting:
        istio:
          virtualService:
            name: payments-api      # 既存VirtualServiceをRolloutsが操作
            routes:
              - primary
      steps:
        - setWeight: 10
        - pause: { duration: 5m }   # 5分間観察
        - analysis:                  # AnalysisTemplateでメトリクスゲート
            templates:
              - templateName: success-rate
        - setWeight: 30
        - pause: { duration: 5m }
        - setWeight: 60
        - pause: { duration: 5m }
  selector:
    matchLabels:
      app: payments-api
  template:
    metadata:
      labels:
        app: payments-api
    spec:
      containers:
        - name: app
          image: registry.example.com/payments-api:v2

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: orders
  namespace: commerce
spec:
  hosts:
    - orders.commerce.svc.cluster.local
  http:
    - route:
        - destination:
            host: orders.commerce.svc.cluster.local
            subset: v1
          weight: 100          # 実際の応答はすべてv1が処理
      mirror:
        host: orders.commerce.svc.cluster.local
        subset: v2             # コピーはv2へ
      mirrorPercentage:
        value: 20.0            # トラフィックの20%だけミラーリング

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings-fault
  namespace: bookinfo
spec:
  hosts:
    - ratings.bookinfo.svc.cluster.local
  http:
    - match:
        - headers:
            x-chaos-test:        # テストトラフィックにのみ注入 (全体注入は禁止)
              exact: "true"
      fault:
        delay:
          percentage:
            value: 50.0          # マッチしたトラフィックの50%に
          fixedDelay: 3s         # 3秒の遅延を注入
        abort:
          percentage:
            value: 10.0          # 10%にはHTTP 503を返す
          httpStatus: 503
      route:
        - destination:
            host: ratings.bookinfo.svc.cluster.local
            subset: v1
    - route:                      # 通常トラフィックはそのまま
        - destination:
            host: ratings.bookinfo.svc.cluster.local
            subset: v1

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: inventory
  namespace: commerce
spec:
  hosts:
    - inventory.commerce.svc.cluster.local
  http:
    - route:
        - destination:
            host: inventory.commerce.svc.cluster.local
      timeout: 3s                # リクエスト全体のデッドライン (リトライ込み)
      retries:
        attempts: 2              # 最大2回リトライ
        perTryTimeout: 1s        # 1回の試行あたり1秒
        retryOn: 5xx,reset,connect-failure,retriable-4xx

1. perTryTimeout: 対象サービスの正常時p99レイテンシ x 1.5~2倍
   (例: p99が400msならperTryTimeoutは1s)
2. attempts: 冪等リクエスト(GET)は2、非冪等(POST)は0~1
   非冪等リクエストのリトライは重複処理リスク — 冪等性キーがなければ禁止
3. timeout(全体): perTryTimeout x (attempts + 1) 以上でないと
   リトライが実際に意味を持たない。1s x 3 = 3s
4. retryOnのreset/connect-failureは安全 (リクエスト到達前の失敗)、
   5xxは非冪等リクエストでは慎重に

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: inventory-cb
  namespace: commerce
spec:
  host: inventory.commerce.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100          # インスタンスごとではなくエンドポイントプール基準
      http:
        http1MaxPendingRequests: 50  # 待ち行列の上限 — 超過分は即503
        http2MaxRequests: 200        # 同時リクエスト上限
        maxRequestsPerConnection: 0  # 0 = 無制限 (keep-alive維持)
    outlierDetection:
      consecutive5xxErrors: 5        # 連続5xxが5回なら
      interval: 10s                  # 10秒周期で評価
      baseEjectionTime: 30s          # 30秒間プールから排除 (繰り返すと倍数増加)
      maxEjectionPercent: 50         # 同時排除は全体の50%まで
      minHealthPercent: 30           # 健全なインスタンスが30%未満なら排除停止

- maxConnections / http2MaxRequests:
  平常時ピークの同時リクエスト数 x 1.5~2倍。小さすぎると平常時でも503、
  大きすぎるとサーキットブレーカーが事実上オフと同じ。
  Grafanaでistio_requests_totalベースに同時性を推定してから設定。
- http1MaxPendingRequests:
  「待たせるくらいなら早く失敗させたい上限」。レイテンシに敏感なサービスは
  小さく(10~50)、バッチ性トラフィックは大きく。
- consecutive5xxErrors + baseEjectionTime:
  デプロイ直後のウォームアップ中の一時エラーで過剰排除されないよう、
  consecutive5xxErrorsを小さすぎる値(1~2)にしないこと。
- maxEjectionPercent:
  インスタンスが3つしかないサービスで100%にすると全排除で
  かえって全面障害。50%以下 + minHealthPercentで安全弁を。

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: search-locality
  namespace: commerce
spec:
  host: search.commerce.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      simple: LEAST_REQUEST
      localityLbSetting:
        enabled: true
        failoverPriority:        # 同じzone → 同じregion → その他の順で優先
          - "topology.kubernetes.io/zone"
          - "topology.kubernetes.io/region"
    outlierDetection:            # localityフェイルオーバーにはoutlierDetectionが必須
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s

apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
  name: external-payment-gateway
  namespace: payments
spec:
  hosts:
    - api.pgprovider.example
  location: MESH_EXTERNAL
  ports:
    - number: 443
      name: https
      protocol: TLS
  resolution: DNS
---
# 登録済みの外部ホストにもタイムアウト/リトライを適用可能
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: external-payment-gateway
  namespace: payments
spec:
  hosts:
    - api.pgprovider.example
  tls:
    - match:
        - sniHosts:
            - api.pgprovider.example
      route:
        - destination:
            host: api.pgprovider.example

# メッシュ全体で未登録の外部トラフィックを遮断 (IstioOperatorまたはMeshConfig)
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY    # ServiceEntryにない外部ホストは遮断

# Istio Gateway/VirtualService構成のGateway API等価物
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-ingress
spec:
  gatewayClassName: istio
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      hostname: shop.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - name: shop-example-com-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop-route
  namespace: commerce
spec:
  parentRefs:
    - name: public-gateway
      namespace: istio-ingress
  hostnames:
    - shop.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api/
      backendRefs:
        - name: shop-api
          port: 8080
          weight: 90
        - name: shop-api-canary
          port: 8080
          weight: 10

リトライ増幅の算数:
  AがBを呼ぶ: 1 + リトライ2回 = 最大3回
  BがCを呼ぶ: それぞれ1 + 2回 = 最大3回
  → Cが受けるリクエスト: 3 x 3 = 最大9回 (本来は1回)

チェーンが4段なら27倍。Cが過負荷で死にかけているなら、
リトライが棺に釘を打つようなもの。

原則:
- リトライはチェーンの一箇所(できるだけ最も外側の層)にのみ
- 内部の深い層はattempts: 0または1
- outlierDetectionと併用して、死にかけのインスタンスへのリトライを遮断

誤った構成:
  A --(timeout 1s)--> B --(timeout 3s)--> C
  BがCの応答を2.5秒で受け取っても、Aはすでに1秒で切ってリトライ済み

原則: 外側のタイムアウト >= 内側のタイムアウト合計 + 余裕
  A --(timeout 5s)--> B --(timeout 3s)--> C (各リトライ込みで計算)
  デッドラインは外側から内側へ行くほど短くならなければならない

503デバッグフロー:

1. アクセスログでRESPONSE_FLAGSを確認
   kubectl logs deploy/app -c istio-proxy | grep ' 503 '

2. フラグごとの分岐:
   UH  (no healthy upstream)
       → エンドポイントなし。DestinationRule subsetラベルとPodラベルの
         不一致が定番の原因
       → istioctl proxy-config endpoints deploy/app | grep 対象サービス
   UO  (upstream overflow)
       → connectionPool上限超過。サーキットブレーカーが意図どおり動作中か、
         上限が小さすぎるかを判断
   UF  (upstream connection failure)
       → 接続自体が失敗。mTLS設定の不一致(片側のみSTRICT)または
         ポート/プロトコルのミスマッチ
   URX (max retries reached)
       → リトライ枯渇。根本原因は他のフラグとともに追跡
   NR  (no route)
       → VirtualServiceマッチング漏れ。catch-allルールの存在を確認

3. 設定と実際の状態を照合:
   istioctl analyze -n ネームスペース
   istioctl proxy-config cluster deploy/app --fqdn 対象FQDN -o json

# 1) リスナー: このプロキシがどのポートを聴いているか
istioctl proxy-config listeners deploy/app -n commerce

# 2) ルート: VirtualServiceがどのルーティングテーブルに翻訳されたか
istioctl proxy-config routes deploy/app -n commerce --name 8080 -o json

# 3) クラスタ: DestinationRule(サーキットブレーカー、TLS)が反映されたか
istioctl proxy-config cluster deploy/app -n commerce \
  --fqdn inventory.commerce.svc.cluster.local -o json

# 4) エンドポイント: subsetに実際のPod IPが載っているか
istioctl proxy-config endpoints deploy/app -n commerce \
  | grep inventory

# 5) 全体の同期状態: istiodとプロキシ間の設定伝播を確認
istioctl proxy-status