Service Mesh (ASM) は、トラフィックルーティングと Pod スケーリングを分離し、レプリカ数に関係なく、各アプリケーションバージョンにトラフィックが到達する割合ベースの制御を提供します。
このガイドでは、Bookinfo サンプルアプリケーションを使用して、仮想サービスと宛先ルールを用いた 3 つのリリース戦略について説明します。
ブルーグリーンリリース -- すべてのトラフィックを単一ステップで一方のバージョンから別のバージョンに切り替えます。
重みベースのカナリアリリース -- トラフィックを割合で 2 つのバージョンに分割します。
ヘッダーベースのカナリアリリース -- リクエストヘッダーに基づいて、特定のユーザーを新しいバージョンにルーティングします。
前提条件
開始する前に、以下を準備してください。
ASM インスタンス。詳細については、「ASM インスタンスの作成」をご参照ください。
少なくとも 1 つの Container Service for Kubernetes (ACK) クラスターが ASM インスタンスに追加されていること。詳細については、「ASM インスタンスへのクラスターの追加」をご参照ください。
Bookinfo アプリケーションが ACK クラスターにデプロイされていること。詳細については、「ASM インスタンスへのアプリケーションのデプロイ」をご参照ください。
ACK クラスター用にイングレスゲートウェイがデプロイされていること。詳細については、「イングレスゲートウェイサービスの作成」をご参照ください。
仕組み
宛先ルールは、Pod のバージョンラベルにマッピングされる名前付きサブセットを定義します。仮想サービスはこれらのサブセットを参照し、どのバージョンがどの割合でトラフィックを受信するかを制御します。
このガイドでは、以下の現実的な手順に従います。
すべての Bookinfo マイクロサービスバージョン (宛先ルール) のサブセットを定義します。
すべてのトラフィックを v1 (ベースライン) にルーティングします。
ブルーグリーンリリース: reviews サービスを v1 から v2 に切り替えます。
重みベースのカナリアリリース: reviews v2 と v3 間でトラフィックを分割します。
ヘッダーベースのカナリアリリース: 特定のユーザーを reviews v3 にルーティングします。
ステップ 1: 宛先ルールの作成
仮想サービスが名前で参照できるように、各 Bookinfo マイクロサービスのサブセットを定義します。詳細については、「宛先ルールの管理」をご参照ください。
以下の宛先ルールを ASM インスタンスに適用します。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: productpage
spec:
host: productpage
subsets:
- name: v1
labels:
version: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: ratings
spec:
host: ratings
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v2-mysql
labels:
version: v2-mysql
- name: v2-mysql-vm
labels:
version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: details
spec:
host: details
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2宛先ルールが作成されたことを確認します。
kubectl get destinationrules -o name期待される出力:
destinationrule.networking.istio.io/productpage
destinationrule.networking.istio.io/reviews
destinationrule.networking.istio.io/ratings
destinationrule.networking.istio.io/detailsステップ 2: すべてのトラフィックを v1 (ベースライン) にルーティング
各 Bookinfo マイクロサービスの v1 サブセットにすべてのトラフィックをルーティングする仮想サービスを作成します。これにより、トラフィックをシフトする前に安定したベースラインが確立されます。詳細については、「仮想サービスの管理」をご参照ください。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: productpage
spec:
hosts:
- productpage
http:
- route:
- destination:
host: productpage
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: details
spec:
hosts:
- details
http:
- route:
- destination:
host: details
subset: v1ベースラインの確認
ブラウザで Bookinfo 製品ページを更新します。reviews v1 は ratings サービスを呼び出さないため、reviews セクションには星評価が表示されません。
ルーティングルールを確認します。
kubectl get virtualservice reviews -o yaml出力には、reviews サービスの唯一の送信先として subset: v1 が表示されるはずです。
この時点では、reviews v2 および v3 の Pod は実行されていますが、トラフィックは受信しません。
ステップ 3: ブルーグリーンリリース -- reviews v2 への切り替え
ブルーグリーンリリースは、すべてのトラフィックを単一ステップで一方のバージョンから別のバージョンにシフトします。reviews 仮想サービスを更新して、トラフィックの 100% を v2 サブセットにルーティングします。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v2
weight: 50
- destination:
host: reviews
subset: v3
weight: 50ブルーグリーンリリースの確認
Bookinfo 製品ページを更新します。reviews セクションに黒い星評価が表示され、すべてのトラフィックが reviews v2 に到達していることを確認できます。
ルーティングルールを確認します。
kubectl get virtualservice reviews -o yaml出力には、唯一の送信先として subset: v2 が表示されるはずです。
注: ロールバックするには、トラフィックを v1 サブセットにルーティングするステップ 2 の仮想サービスを再適用します。
ステップ 4: 重みベースのカナリアリリース -- v2 と v3 間でトラフィックを分割
すべてのトラフィックを一度に切り替えるのではなく、徐々に新しいバージョンに割合をシフトします。以下の仮想サービスは、reviews v2 と v3 間でトラフィックを 50/50 に分割します。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- route:
- destination:
host: reviews
subset: v2
weight: 50
- destination:
host: reviews
subset: v3
weight: 50weight の値は、各バージョンのトラフィックの割合を制御します。重みの合計は 100 になる必要があります。
カナリアリリースの確認
Bookinfo 製品ページを数回更新します。reviews セクションには、黒い星 (v2) と赤い星 (v3) がほぼ同じ頻度で交互に表示されます。
注: ロールバックするには、v2 送信先でweight: 100を設定し、v3 でweight: 0を設定するか、v3 送信先を完全に削除します。
ステップ 5: ヘッダーベースのカナリアリリース -- ユーザー ID によるルーティング
HTTP ヘッダーに基づいて特定のユーザーを新しいバージョンにルーティングし、他のすべてのユーザーは現在のバージョンに残します。このアプローチは、より広範なロールアウトの前の内部テストに役立ちます。
Bookinfo アプリケーションは、ログインユーザー名を end-user HTTP ヘッダーとして渡します。以下の仮想サービスは、ユーザー jason を reviews v3 にルーティングし、他のすべてのユーザーを reviews v2 にルーティングします。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v3
- route:
- destination:
host: reviews
subset: v2ヘッダーベースリリースの確認
サインインせずに Bookinfo 製品ページを更新します。reviews セクションには黒い星 (v2) が表示されます。
右上隅の[サインイン]をクリックします。
jasonをユーザー名として入力します。パスワードは不要です。サインイン後、ページを更新します。reviews セクションには赤い星 (v3) が表示されます。
これは、Bookinfo 製品ページがバックエンドマイクロサービスへのリクエストに end-user ヘッダーを含めるためです。end-user が jason と一致すると、仮想サービスはリクエストを reviews v3 にルーティングします。
クリーンアップ
このガイドで作成したルーティングルールを削除するには、仮想サービスと宛先ルールを削除します。
kubectl delete virtualservice productpage reviews ratings details
kubectl delete destinationrule productpage reviews ratings details