第22章Nine Analysisにより、Istio宛先ルールの例を完成させる

一連の記事：

総合カタログインデックス：9つの分析により、Istioサービスグリッドシリーズのチュートリアルを簡単に完了できます

ディレクトリ

1はじめに

2招待

3はじめに

4グレースケール

5宛先ルールの例

5.1クライアントリソースファイル

5.2デプロイメントリソースファイル

5.3サービスリソースファイル

5.4 Istio仮想サービスリソースファイル

5.5 Istio宛先ルールリソースファイル

6 Istioインジェクション

7宛先ルールを確認します

1はじめに

ブログについて質問がある場合は、お知らせください。

2招待

ステーションbから「Nine Analysis」を検索して、無料でより鮮やかなビデオ素材を入手できます。

3はじめに

前のセクションでは、仮想サービスを使用してトラフィックを重みで分散する例を紹介しました。次のアーキテクチャ図にプロセス全体を示します。

フロー制御プロセス全体は、仮想サービスのみを追加することで解決され、仮想サービスのコードは次のとおりです。

ただし、上記の解決策は、呼び出し元が2つのサービス層を介して最終ポッドを呼び出すことができることです（たとえば、クライアントは最終的にNginxポッドを呼び出すためにweb-svcおよびnginx-svcを渡す必要があります）。この効果は、1つのサービス層だけで達成できますか？（つまり、web-svc経由のみ）。答えはイエスです。

4グレースケール

実際、上記のサンプルは非常に模倣的であり、独立した仮想サービス機能を示すためだけに、実際の作業シーンをコピーすることはできません。

しかし、トラフィックを重量で配分することは、実際には、グレースケール、カナリア、青と緑のリリースなどの作業で一般的な要件です。

グレースケールは、物事がそれほどオープンではないことを意味します。たとえば、好きな女性と東京のラブストーリーを上演したい場合、アプローチは多分あいまいで、愛撫し、キスし、最後に彼女を称賛することです。プロセス全体の本質は、状態の移行を完了することです。つまり、単独で戦っている状態から、チームワークが拍手している状態までです。

グレースケールリリースのプロセスは、上記のプロセスと同様であり、段階的なフォローアッププロセスです。つまり、バージョンv1のサービスはバージョンv2に変更されていますが、極端なアプローチは採用されていません。具体的な方法は、最初にトラフィックの20％をバージョンv2にカットし、しばらくの間は異常が発生しないことを観察してから、トラフィックの20％をカットしてから、残りのトラフィックを徐々に切り替え、最後にバージョン全体の置き換えとすべてのユーザートラフィックの転送を完了します。

5宛先ルールの例

以下では、仮想サービス+宛先ルールを使用してグレースケールリリースを実現する方法を紹介します。宛先ルールの理論については、次の章で紹介します。サンプル全体のアーキテクチャ図は次のとおりです。

サンプルで必要なリソースファイルは次のとおりです。

＃クライアント、httpd-v1およびhttpd-v2のコンテナーリソースファイルへのアクセスに使用

jiuxi-client.yaml

＃デプロイ、httpdのリソースファイルを宣言・定義

jiuxi-deploy.yaml

＃httpd podに関連付けられたサービス、リソースファイル

jiuxin-svc.yaml

＃Istio仮想サービス、トラフィックのルーティングと重みを宣言するリソースファイル

jiuxi-vs.yaml

＃Istio宛先ルール、トラフィックルーティングを定義するリソースファイル

jiuxin-dr.yaml