Istio を使用したマイクロサービスに戻ります。 パート2

ノート。 翻訳。: 最初の部分 このシリーズは、Istio の機能を紹介し、その機能を実際にデモンストレーションすることに専念しました。 ここでは、このサービス メッシュの構成と使用のより複雑な側面、特に、細かく調整されたルーティングとネットワーク トラフィック管理について説明します。

また、この記事ではリポジトリの構成 (Kubernetes および Istio のマニフェスト) が使用されていることにも注意してください。 istioマスタリー.

交通管理

Istio では、次の機能を提供する新しい機能がクラスターに表示されます。

• 動的リクエストルーティング: カナリア ロールアウト、A/B テスト。
• 負荷分散: シンプルで一貫性があり、ハッシュに基づいています。
• 転倒後の回復: タイムアウト、再試行、サーキット ブレーカー。
• フォルトの挿入: 遅延、リクエストのドロップなど。

記事の続きとして、選択したアプリケーションを例として使用してこれらの機能を説明し、途中で新しい概念も紹介します。 そのようなコンセプトの最初のものは、 DestinationRules (つまり、トラフィック/リクエストの受信者に関するルール - およその翻訳)、これを利用して A/B テストを有効にします。

A/B テスト: 実際の DestinationRules

A/B テストは、アプリケーションに 100 つのバージョンがあり (通常は視覚的に異なります)、どちらがユーザー エクスペリエンスを向上させるかが XNUMX% わからない場合に使用されます。 したがって、両方のバージョンを同時に実行し、メトリクスを収集します。

A/B テストのデモンストレーションに必要なフロントエンドの XNUMX 番目のバージョンをデプロイするには、次のコマンドを実行します。

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

緑色のバージョンの展開マニフェストは、次の XNUMX つの場所で異なります。

1. 画像は別のタグに基づいています - istio-green,
2. ポッドにはラベルが付いています version: green.

両方のデプロイメントにラベルがあるため、 app: sa-frontend、仮想サービスによってルーティングされたリクエスト sa-external-services サービス用 sa-frontend、そのすべてのインスタンスにリダイレクトされ、負荷は ラウンドロビンアルゴリズム、これにより、次のような状況が発生します。

要求されたファイルが見つかりませんでした

これらのファイルは、アプリケーションのバージョンによって名前が異なるため、見つかりませんでした。 これを確認しましょう:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

つまり、 index.htmlあるバージョンの静的ファイルを要求するこのファイルは、ロード バランサーによって別のバージョンを持つポッドに送信される可能性がありますが、明らかな理由により、そのようなファイルは存在しません。 したがって、アプリケーションが動作するには、次のような制限を設定する必要があります。index.html を処理したのと同じバージョンのアプリケーションが後続のリクエストを処理する必要があります'。

一貫したハッシュベースの負荷分散によって目標を達成します (一貫したハッシュロードバランシング)。 この場合 同じクライアントからのリクエストは同じバックエンド インスタンスに送信されます。、事前定義されたプロパティ (HTTP ヘッダーなど) が使用されます。 DestinationRules を使用して実装されます。

宛先ルール

後に 仮想サービス 目的のサービスにリクエストを送信しました。DestinationRules を使用して、このサービスのインスタンス宛てのトラフィックに適用されるポリシーを定義できます。

Istio リソースを使用したトラフィック管理

注意: ここでは、ネットワーク トラフィックに対する Istio リソースの影響がわかりやすく示されています。 正確に言うと、どのインスタンスにリクエストを送信するかは、CRD で構成された Ingress Gateway の Envoy によって決定されます。

宛先ルールを使用すると、一貫したハッシュを使用し、同じサービス インスタンスが同じユーザーに応答するように負荷分散を構成できます。 次の構成により、これを実現できます (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - HTTP ヘッダーの内容に基づいてハッシュが生成されます version.

次のコマンドを使用して構成を適用します。

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

次に、以下のコマンドを実行し、ヘッダーを指定したときに正しいファイルが取得されることを確認します。 version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

注意: ヘッダーにさまざまな値を追加し、結果をブラウザーで直接テストするには、次を使用できます。 この拡張子 クロムへ （または これとともに Firefox の場合 - 約。 翻訳）.

一般に、DestinationRules には負荷分散の分野でより多くの機能があります - 詳細については、 公式ドキュメント.

VirtualService についてさらに学習する前に、次のコマンドを実行して、アプリケーションの「グリーン バージョン」と対応するトラフィック方向ルールを削除しましょう。

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

ミラーリング: 仮想サービスの実践

シャドウイング (「シールド」) またはミラーリング (「ミラーリング」) エンドユーザーに影響を与えずに本番環境での変更をテストしたい場合に使用されます。これを行うには、必要な変更が加えられた XNUMX 番目のインスタンスにリクエストを複製 (「ミラーリング」) し、その結果を確認します。 簡単に言うと、これは、同僚が最も重要な問題を選択し、実際には誰もレビューできないような巨大な土の塊の形でプルリクエストを作成したときです。

このシナリオを実際にテストするために、バグを含む SA-Logic の XNUMX 番目のインスタンスを作成しましょう (buggy) 次のコマンドを実行します。

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

次に、コマンドを実行して、すべてのインスタンスが app=sa-logic 対応するバージョンのラベルも付いています。

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

サービス sa-logic ラベルが付いたポッドをターゲットにします app=sa-logicしたがって、すべてのリクエストはすべてのインスタンスに分散されます。

...ただし、リクエストを v1 インスタンスに送信し、v2 インスタンスにミラーリングする必要があります。

これは、VirtualService と DestinationRule を組み合わせて実現します。ルールにより、VirtualService のサブセットと特定のサブセットへのルートが決定されます。

宛先ルールでのサブセットの定義

サブセット (サブセット) は次の構成によって決定されます (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. ホスト （host) ルートがサービスに向かう場合にのみこのルールが適用されることを定義します sa-logic;
2. タイトル (name) サブセットは、サブセット インスタンスにルーティングするときに使用されます。
3. ラベル (label) は、インスタンスがサブセットの一部となるために一致する必要があるキーと値のペアを定義します。

次のコマンドを使用して構成を適用します。

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

サブセットが定義されたので、次は、sa-logic へのリクエストにルールを適用するように VirtualService を構成して、次のようにすることができます。

1. サブセットにルーティングされる v1,
2. サブセットにミラーリング v2.

次のマニフェストにより、計画を達成できます (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

ここでは説明は不要なので、実際の動作を見てみましょう。

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

次のコマンドを呼び出して負荷を追加しましょう。

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

Grafana で結果を見てみましょう。バグのあるバージョンであることがわかります (buggy) リクエストの最大 60% で失敗しますが、これらの失敗は実行中のサービスによって応答されるため、エンド ユーザーには影響しません。

sa-logic サービスのさまざまなバージョンの成功した応答

ここでは、VirtualService がサービスの Envoy にどのように適用されるかを初めて確認しました。 sa-web-app にリクエストを出します sa-logic、サイドカー Envoy を経由します。これは、VirtualService を介して、リクエストを v1 サブセットにルーティングし、リクエストをサービスの v2 サブセットにミラーリングするように構成されています。 sa-logic.

仮想サービスは単純だとすでに思われているかもしれません。 次のセクションでは、それらが本当に素晴らしいものであることを述べて、さらに詳しく説明します。

カナリアのロールアウト

カナリア デプロイメントは、アプリケーションの新しいバージョンを少数のユーザーにロールアウトするプロセスです。 これは、リリースに問題がないことを確認するために使用され、その後、その（リリースの）品質にすでに自信を持って、他のユーザーに配布します。оより大きな聴衆。

カナリアのロールアウトを実証するために、サブセットの使用を継続します。 buggy у sa-logic.

些細なことで時間を無駄にせず、すぐにユーザーの 20% をバグのあるバージョン (これがカナリア ロールアウトを表します) に送り、残りの 80% を通常のサービスに送りましょう。 これを行うには、次の VirtualService (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 は重量 (weight)、受信者または受信者のサブセットに送信されるリクエストの割合を指定します。

以前の VirtualService 構成を更新しましょう。 sa-logic 次のコマンドを使用します。

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

...そして、いくつかのリクエストが失敗につながることがすぐにわかります。

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices によりカナリア ロールアウトが可能になります。この場合、問題の潜在的な影響をユーザー ベースの 20% に絞り込みました。 素晴らしい！ コードが不明な場合は常に (つまり、常に...)、ミラーリングとカナリア ロールアウトを使用できます。

タイムアウトと再試行

ただし、バグが常にコードに存在するとは限りません。 からのリストでは、分散コンピューティングに関する 8 つの誤解「第一に、「ネットワークは信頼できる」という誤った信念があります。 実はネットワークは ノー 信頼性が高く、このためタイムアウトが必要です (タイムアウト) そして再試行します （再試行）.

デモンストレーションでは、同じ問題のあるバージョンを引き続き使用します。 sa-logic (buggy)、ランダムな障害によるネットワークの信頼性の低さをシミュレートします。

バグのあるサービスの応答に時間がかかりすぎる可能性が 1/3、内部サーバー エラーで終了する可能性が 1/3、ページが正常に返される可能性が 1/3 であるとします。

このような問題の影響を軽減し、ユーザーの生活をより良いものにするために、次のことが可能です。

1. サービスの応答に 8 秒以上かかる場合はタイムアウトを追加します。
2. リクエストが失敗した場合は再試行します。

実装には、次のリソース定義を使用します(sa-logic-retries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. リクエストのタイムアウトは 8 秒に設定されています。
2. リクエストは 3 回再試行されます。
3. また、応答時間が 3 秒を超えると、各試行は失敗したとみなされます。

これは、ユーザーが 8 秒以上待つ必要がなく、失敗した場合に応答を取得するために XNUMX 回の新たな試行を行うため、応答が成功する可能性が高まるための最適化です。

次のコマンドを使用して、更新された構成を適用します。

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

そして、成功した応答の数が上記のように増加していることを Grafana グラフで確認します。

タイムアウトと再試行を追加した後の成功応答統計の改善

次のセクションに進む前に (むしろ、この記事の次の部分に進んでください。この記事ではこれ以上実際的な実験は行わないためです。おおよその翻訳です。)、 消去 sa-logic-buggy 次のコマンドを実行して、VirtualService を実行します。

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

サーキットブレーカーとバルクヘッドのパターン

ここでは、自己回復を実現するマイクロサービス アーキテクチャの XNUMX つの重要なパターンについて説明します。 (自己修復) サービス。

サーキットブレーカー (「サーキットブレーカー」) 異常とみなされるサービスのインスタンスに送信されるリクエストを終了し、クライアントのリクエストがそのサービスの正常なインスタンスにリダイレクトされる間にそれを復元するために使用されます (これにより、成功した応答の割合が増加します)。 (注: パターンのより詳細な説明は、たとえば、 ここで.)

隔壁 （"パーティション"） サービス障害がシステム全体に影響を及ぼさないように隔離します。 たとえば、サービス B が壊れており、別のサービス (サービス B のクライアント) がサービス B にリクエストを行うと、サービス B のスレッド プールが枯渇し、他のリクエスト (サービス B からのものでない場合でも) を処理できなくなります。 (注: パターンのより詳細な説明は、たとえば、 ここで.)

これらのパターンの実装の詳細は、以下で簡単に見つけることができるため省略します。 公式ドキュメントまた、認証と認可についても実際に示したいと思っています。これについては、記事の次の部分で説明します。

翻訳者からの追伸

私たちのブログもお読みください:

• 「Istio でマイクロサービスに戻る」: パート 1 (主な機能の紹介), パート 3 (認証と認可);
• «Conduit - Kubernetes 用の軽量サービス メッシュ";
• «サービス メッシュとは何ですか? [マイクロサービスを備えたクラウド アプリケーションに] サービス メッシュが必要な理由は何ですか?'。

出所： habr.com