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

ノート。 翻訳。: サービス メッシュは、マイクロサービス アーキテクチャに従うアプリケーションの最新のインフラストラクチャに関連するソリューションになっているのは間違いありません。 Istio は多くの DevOps エンジニアが知っているかもしれませんが、非常に新しい製品であり、提供される機能という点では包括的ではありますが、慣れるまでにかなりの時間を必要とする可能性があります。 電気通信会社 Orange Networks で大規模顧客向けのクラウド コンピューティングを担当するドイツ人エンジニアの Rinor Maloku は、Istio を素早く深く掘り下げるための素晴らしい一連の資料を執筆しました。 彼は、Istio で一般的に何ができるのか、そしてそれを自分の目ですぐに確認できる方法から話を始めます。

イスティオ — Google、IBM、Lyft のチームと協力して開発されたオープンソース プロジェクト。 これは、マイクロサービスベースのアプリケーションで生じる次のような複雑さを解決します。

• 交通管理: タイムアウト、再試行、負荷分散;
• セキュリティ: エンドユーザーの認証と認可。
• 可観測性: トレース、モニタリング、ロギング。

これらはすべてアプリケーション レベルで解決できますが、それ以降はサービスは「マイクロ」ではなくなります。 これらの問題を解決するための余分な労力はすべて、ビジネス価値に直接使用できる会社リソースの無駄です。 例を見てみましょう:

プロジェクト マネージャー: フィードバック機能を追加するのにどれくらい時間がかかりますか?
開発者: スプリントは XNUMX つです。

MP: えっ?.それは単なる CRUD です!
R: CRUD を実行するのは簡単ですが、ユーザーとサービスを認証し、認可する必要があります。 ネットワークの信頼性が低いため、繰り返しリクエストを実装する必要があります。 サーキットブレーカーのパターン クライアントで。 また、システム全体がクラッシュしないようにするには、タイムアウトと 隔壁 (前述の両方のパターンの詳細については、記事後半のおおよその翻訳を参照してください。)、問題を検出するために、監視、追跡、[…]

MP: ああ、それではこの機能を Product サービスに挿入しましょう。

この考えは明らかだと思います。XNUMX つのサービスを追加するのに必要な手順と労力は膨大です。 この記事では、Istio が上記のすべての複雑さ (ビジネス ロジックを意図したものではありません) をサービスからどのように除去するかを見ていきます。

注意: この記事は、Kubernetes に関する実践的な知識があることを前提としています。 それ以外の場合は、読むことをお勧めします Kubernetes についての私の紹介 その後、この資料を読み続けてください。

Istio のアイデア

Istio のない世界では、あるサービスが別のサービスに直接リクエストを送信し、障害が発生した場合には、サービス自体がそれを処理する必要があります。つまり、新しい試行を行ったり、タイムアウトを設定したり、サーキット ブレーカーを開いたりする必要があります。

Kubernetes のネットワーク トラフィック

Istio は、ネットワーク通信を妨害することによってサービスや機能から完全に分離された、特殊なソリューションを提供します。 したがって、次のように実装されます。

• 耐障害性: 応答のステータス コードに基づいて、リクエストが失敗したかどうかを理解し、リクエストを再実行します。
• カナリアのロールアウト: 一定の割合のリクエストのみを新しいバージョンのサービスにリダイレクトします。
• モニタリングとメトリクス: サービスが応答するまでにどれくらい時間がかかりましたか?
• トレースと可観測性: 各リクエストに特別なヘッダーを追加し、クラスター全体でそれらを追跡します。
• セキュリティ: JWT トークンを取得し、ユーザーを認証および認可します。

これらは、興味をそそられる可能性のほんの一部 (実際にはほんの一部です!) です。 それでは、技術的な詳細を見ていきましょう。

Istio アーキテクチャ

Istio はすべてのネットワーク トラフィックを傍受し、それに一連のルールを適用し、サイドカー コンテナーの形式でスマート プロキシを各ポッドに挿入します。 すべての機能をアクティブ化するプロキシは、 データプレーンを使用して動的に構成できます。 コントロールプレーン.

データプレーン

ポッドにプロキシを挿入すると、Istio は必要な要件を簡単に満たすことができます。 たとえば、リトライ機能やサーキットブレーカー機能を確認してみましょう。

Envoy での再試行とサーキット ブレークの実装方法

まとめると：

1. エンボイ (ここで話しているのは、サイドカー コンテナ内にあるプロキシであり、次のように配布されます。 別製品 — 約翻訳） サービス B の最初のインスタンスにリクエストを送信しますが、失敗します。
2. Envoy サイドカーが再試行します （リトライ）. (1)
3. リクエストは失敗し、それを呼び出したプロキシに返されます。
4. これにより、サーキット ブレーカーが開き、後続のリクエストに対して次のサービスが呼び出されます。 (2)

これは、別の Retry ライブラリを使用する必要がなく、プログラミング言語 X、Y、または Z でサーキット ブレークとサービス ディスカバリの独自の実装を作成する必要がないことを意味します。これらすべておよびその他の機能がすぐに利用可能です。 Istio にあり、必要ありません ノー コードの変更。

素晴らしい！ ここで、Istio を使って旅に出たいと思っているかもしれませんが、まだ疑問が残っているので、オープンな質問をしてください。 これが人生のあらゆる場面に当てはまる普遍的な解決策であるならば、あなたは自然な疑念を抱きます。結局のところ、現実にはそのような解決策はすべて、どのような場合にも不適切であることが判明します。

そして最後に、「カスタマイズ可能ですか?」と尋ねます。

これで航海の準備が整いました。コントロール プレーンについて見てみましょう。

コントロールプレーン

これは XNUMX つのコンポーネントで構成されます。 パイロット, ミキサー и 要塞これらは連携して、トラフィックのルーティング、ポリシーの適用、テレメトリ データの収集を行うように Envoy を構成します。 概略的には、すべて次のようになります。

コントロール プレーンとデータ プレーンの相互作用

Envoy (つまり、データ プレーン) は次を使用して構成されます。 Kubernetes CRD (カスタム リソース定義) Istio によって定義され、特にこの目的のために意図されています。 これが意味するのは、これらは、使い慣れた構文を備えた Kubernetes の単なる別のリソースであるように見えるということです。 このリソースが作成されると、コントロール プレーンによって取得され、Envoy に適用されます。

サービスと Istio の関係

Istio とサービスの関係については説明しましたが、その逆については説明しませんでした。サービスは Istio にどのように関係するのでしょうか?

正直に言うと、サービスは、「そもそも水とは何だろう?」と自問するときに、魚が水について考えるのと同じくらい、Istio の存在を認識しています。

イラスト ビクトリア・ディミトラコプロス: - 水はどうですか? - そもそも水とは何ですか？

したがって、動作中のクラスターを取得し、Istio コンポーネントをデプロイした後も、そのクラスター内にあるサービスは引き続き動作し、これらのコンポーネントを削除すると、すべてが正常に戻ります。 この場合、Istio が提供する機能が失われることは明らかです。

理論は十分です。この知識を実践してみましょう。

Istio の実践

Istio には、少なくとも 4 つの vCPU と 8 GB の RAM が利用可能な Kubernetes クラスターが必要です。 クラスターをすばやくセットアップして記事の手順に従うには、新規ユーザー向けの Google Cloud Platform を使用することをお勧めします。 無料 $300.

クラスターを作成し、コンソール ユーティリティを使用して Kubernetes へのアクセスを構成した後、Helm パッケージ マネージャーを使用して Istio をインストールできます。

ヘルムの取り付け

「Helm クライアント」の説明に従って、コンピューターに Helm クライアントをインストールします。 公式ドキュメント。 次のセクションでは、これを使用して Istio をインストールするためのテンプレートを生成します。

Istio のインストール

Istio リソースを次からダウンロードします 最新のリリース (元の作成者のバージョン 1.0.5 へのリンクは、現在のリンク、つまり 1.0.6 - およその翻訳に変更されました。)、コンテンツを XNUMX つのディレクトリに抽出します (以降、このディレクトリと呼びます) [istio-resources].

Istio リソースを簡単に識別するには、K8s クラスターに名前空間を作成します。 istio-system:

$ kubectl create namespace istio-system

ディレクトリに移動してインストールを完了します [istio-resources] そしてコマンドを実行します:

$ helm template install/kubernetes/helm/istio 
  --set global.mtls.enabled=false 
  --set tracing.enabled=true 
  --set kiali.enabled=true 
  --set grafana.enabled=true 
  --namespace istio-system > istio.yaml

このコマンドは、Istio の主要コンポーネントをファイルに出力します。 istio.yaml。 標準テンプレートを自分たちに合わせて変更し、次のパラメータを指定しました。

• global.mtls.enabled にインストールされています false (つまり、mTLS 認証が無効になっています - 約)デートのプロセスを簡素化するため。
• tracing.enabled Yeter を使用したリクエスト トレースが含まれます。
• kiali.enabled Kiali をクラスターにインストールして、サービスとトラフィックを視覚化します。
• grafana.enabled 収集されたメトリクスを視覚化するために Grafana をインストールします。

生成されたリソースを次のコマンドで使用してみましょう。

$ kubectl apply -f istio.yaml

クラスターへの Istio のインストールが完了しました。 すべてのポッドが名前空間に入るまで待ちます istio-system ことができるようになります Running または Completed以下のコマンドを実行します。

$ kubectl get pods -n istio-system

これで、次のセクションに進み、アプリケーションを起動して実行する準備が整いました。

感情分析アプリケーションのアーキテクチャ

すでに述べたで使用されているセンチメント分析マイクロサービス アプリケーションの例を使用してみましょう。 Kubernetesの紹介記事。 これは、Istio の機能を実際に示すのに十分なほど複雑です。

アプリケーションは XNUMX つのマイクロサービスで構成されます。

1. サービス SAフロントエンド、Reactjs アプリケーションのフロントエンドとして機能します。
2. サービス SA-WebApp感情分析クエリを処理します。
3. サービス SAロジック、それ自体が実行されます 感情分析;
4. サービス SA フィードバック、分析の精度についてユーザーからフィードバックを受け取ります。

この図では、サービスに加えて、Kubernetes で受信リクエストを適切なサービスにルーティングする Ingress コントローラーも表示されます。 Istio は、Ingress Gateway 内で同様の概念を使用しています。詳細については後述します。

Istio からプロキシを使用してアプリケーションを実行する

記事で説明されているさらなる操作を行うには、リポジトリのクローンを作成します。 istioマスタリー。 これには、Kubernetes と Istio のアプリケーションとマニフェストが含まれています。

サイドカーの挿入

挿入ができる 自動的に または 手動で。 サイドカー コンテナを自動的に挿入するには、名前空間にラベルを設定する必要があります。 istio-injection=enabledこれは次のコマンドで実行します。

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

これで、各ポッドがデフォルトの名前空間 (default) はサイドカー コンテナーを受け取ります。 これを確認するには、リポジトリのルート ディレクトリに移動してテスト アプリケーションをデプロイしてみましょう。 [istio-mastery] そして次のコマンドを実行します。

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

サービスをデプロイしたら、次のコマンドを実行して、ポッドに XNUMX つのコンテナー (サービス自体とそのサイドカーを含む) があることを確認してみましょう。 kubectl get pods 列の下にあることを確認してください READY 指定値 2/2、両方のコンテナが実行されていることを示しています。

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

視覚的には次のようになります。

いずれかのポッドの Envoy プロキシ

アプリケーションが起動して実行されるようになったので、アプリケーションへの受信トラフィックを許可する必要があります。

イングレスゲートウェイ

これを達成する (クラスター内のトラフィックを許可する) ベスト プラクティスは、次のとおりです。 イングレスゲートウェイ Istio では、クラスターの「エッジ」に位置し、ルーティング、ロード バランシング、セキュリティ、受信トラフィックの監視などの Istio 機能を有効にすることができます。

Ingress Gateway コンポーネントとそれを外部に転送するサービスは、Istio のインストール中にクラスターにインストールされました。 サービスの外部 IP アドレスを確認するには、次を実行します。

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

この IP (EXTERNAL-IP と呼びます) を使用してアプリケーションにアクセスし続けるため、便宜上、値を変数に書き込みます。

$ EXTERNAL_IP=$(kubectl get svc -n istio-system 
  -l app=istio-ingressgateway 
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

ここでブラウザ経由でこの IP にアクセスしようとすると、「サービス利用不可」エラーが表示されます。 デフォルトでは、Istio はすべての受信トラフィックをブロックします, ゲートウェイはまだ定義されていません。

ゲートウェイリソース

ゲートウェイは Kubernetes の CRD (カスタム リソース定義) であり、クラスターに Istio をインストールし、受信トラフィックを許可するポート、プロトコル、ホストを指定できるようにした後に定義されます。

この例では、すべてのホストに対してポート 80 での HTTP トラフィックを許可したいと考えています。 タスクは次の定義によって実装されます (http-ゲートウェイ.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
- "*"

この構成はセレクターを除いて説明の必要はありません。 istio: ingressgateway。 このセレクターを使用すると、構成を適用する Ingress Gateway を指定できます。 この場合、これは Istio にデフォルトでインストールされた Ingress Gateway コントローラーです。

構成は、次のコマンドを呼び出すことで適用されます。

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

ゲートウェイはポート 80 へのアクセスを許可しますが、リクエストをどこにルーティングすればよいかわかりません。 このために必要となるのは、 仮想サービス.

仮想サービスリソース

VirtualService は、クラスター内で許可されているリクエストをルーティングする方法を Ingress Gateway に指示します。

http-gateway 経由で送信されるアプリケーションへのリクエストは、sa-frontend、sa-web-app、および sa-フィードバック サービスに送信する必要があります。

VirtualServices で構成する必要があるルート

SA フロントエンドに送信する必要があるリクエストを見てみましょう。

• 途中で完全一致 / index.html を取得するには、SA-Frontend に送信する必要があります。
• 接頭辞付きパス /static/* CSS や JavaScript など、フロントエンドで使用される静的ファイルを受信するには、SA フロントエンドに送信する必要があります。
• 正規表現で一致するパス '^.*.(ico|png|jpg)$'、SA フロントエンドに送信する必要があります。 ページに表示されている写真です。

実装は以下の構成で実現します (sa-virtualservice-external.yaml):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*.(ico|png|jpg)$'
    route:
    - destination:
        host: sa-frontend             # 2
        port:
number: 80

重要事項：

1. この VirtualService は、経由するリクエストを指します httpゲートウェイ;
2. В destination リクエストが送信されるサービスが決定されます。

注意: 上記の設定はファイルに保存されます sa-virtualservice-external.yamlこれには、SA-WebApp および SA-Feedback のルーティングの設定も含まれていますが、簡潔にするためにこの記事では短縮されています。

次を呼び出して VirtualService を適用しましょう。

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created

注意: Istio リソースを使用すると、Kubernetes API サーバーは Istio コントロール プレーンによって受信されるイベントを作成し、その後、新しい構成が各ポッドの Envoy プロキシに適用されます。 また、Ingress Gateway コントローラーは、コントロール プレーンで構成された別の Envoy であるように見えます。 これらすべてを図に示すと次のようになります。

リクエストルーティングのための Istio-IngressGateway 構成

センチメント分析アプリケーションが次から利用可能になりました。 http://{EXTERNAL-IP}/。 「見つかりません」ステータスが表示されても心配する必要はありません。 構成が有効になり、Envoy キャッシュが更新されるまでに少し時間がかかる場合があります。.

先に進む前に、アプリを少しいじってトラフィックを生成してください。 (その後のアクションを明確にするためにその存在が必要です - おおよその翻訳).

キアリ: 可観測性

Kiali 管理インターフェイスにアクセスするには、次のコマンドを実行します。

$ kubectl port-forward 
    $(kubectl get pod -n istio-system -l app=kiali 
    -o jsonpath='{.items[0].metadata.name}') 
    -n istio-system 20001

...そして開きます http://localhost:20001/、管理者/管理者としてログインします。 ここには、Istio コンポーネントの構成を確認したり、ネットワーク リクエストを傍受して収集した情報を使用してサービスを視覚化したり、「誰が誰に連絡しているのか?」、「どのバージョンのサービスで問題が発生しているのか?」という質問に対する回答を得るなど、多くの便利な機能があります。失敗？」 等々。 一般に、Grafana を使用したメトリクスの視覚化に進む前に、Kiali の機能を調べてください。

Grafana: メトリクスの視覚化

Istio で収集されたメトリクスは Prometheus に送られ、Grafana で視覚化されます。 Grafana 管理インターフェイスにアクセスするには、以下のコマンドを実行して開きます。 http://localhost:3000/:

$ kubectl -n istio-system port-forward 
    $(kubectl -n istio-system get pod -l app=grafana 
    -o jsonpath={.items[0].metadata.name}) 3000

メニューをクリックすると ホーム 左上で選択中 Istio サービス ダッシュボード 左上隅でサービスから始めてください sa-ウェブアプリ収集されたメトリクスを確認するには:

ここで私たちを待っているのは、空虚でまったく退屈なパフォーマンスです。経営陣はこれを決して承認しません。 次のコマンドを使用して、小さな負荷を作成してみましょう。

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

現在では、より優れたグラフが表示され、それに加えて、監視用の優れた Prometheus ツールと、時間の経過に伴うサービスのパフォーマンス、健全性、改善/低下について学習できるメトリクスを視覚化するための Grafana が提供されています。

最後に、サービス内のリクエストのトレースを見てみましょう。

イェーガー: 追跡中

サービスが増えれば増えるほど、障害の原因を突き止めるのが難しくなるため、トレースが必要になります。 以下の図から簡単なケースを見てみましょう。

ランダムに失敗したリクエストの典型的な例

依頼が来る、降る―― 理由は何ですか？ 初めてのサービス？ それともXNUMX番目ですか？ どちらにも例外があります。それぞれのログを見てみましょう。 何度こんなことをしていることに気づきましたか? 私たちの仕事は開発者というよりソフトウェア探偵に似ています...

これはマイクロサービスでよくある問題であり、分散トレーシング システムによって解決されます。分散トレーシング システムでは、サービスが相互に固有のヘッダーを渡し、その後、この情報がトレース システムに転送され、リクエスト データと比較されます。 以下に図を示します。

TraceId はリクエストを識別するために使用されます

Istio は、ベンダーに依存しない OpenTracing API フレームワークを実装する Jaeger Tracer を使用します。 次のコマンドを使用して、Jaeger ユーザー インターフェイスにアクセスできます。

$ kubectl port-forward -n istio-system 
    $(kubectl get pod -n istio-system -l app=jaeger 
    -o jsonpath='{.items[0].metadata.name}') 16686

今すぐに行きます http://localhost:16686/ そしてサービスを選択してください sa-ウェブアプリ。 サービスがドロップダウン メニューに表示されない場合は、ページ上でアクティビティを表示/生成し、インターフェイスを更新します。 その後、ボタンをクリックしてください 痕跡を見つける、最新のトレースが表示されます - 任意のトレースを選択します - すべてのトレースに関する詳細情報が表示されます。

このトレースは次のことを示しています。

1. リクエストが入ってくる istio-イングレスゲートウェイ (これはサービスの XNUMX つとの最初の対話であり、その要求に対してトレース ID が生成されます)、その後、ゲートウェイは要求をサービスに送信します。 sa-ウェブアプリ.
2. サービス中 sa-ウェブアプリ リクエストは Envoy サイドカーによって取得され、スパン内に「子」が作成され (これがトレースに表示される理由です)、コンテナにリダイレクトされます。 sa-ウェブアプリ. (スパン - 名前、操作の開始時刻、およびその期間を持つ、Jaeger の作業の論理単位。 スパンはネストして順序付けすることができます。 スパンの有向非巡回グラフがトレースを形成します。 — 約翻訳）
3. ここでリクエストはメソッドによって処理されます 感情分析。 これらのトレースはアプリケーションによってすでに生成されています。 コードの変更が必要でした。
4. この瞬間から、POST リクエストは次のように開始されます。 サロジック。 トレース ID は次から転送する必要があります sa-ウェブアプリ.
5. ...

注意: ステップ 4 では、以下の図に示すように、アプリケーションは Istio によって生成されたヘッダーを確認し、後続のリクエストに渡す必要があります。

(A) Istio はヘッダーの転送を担当します。 (B) サービスがヘッダーを担当する

Istio がほとんどの作業を実行します。その理由は... 受信リクエストのヘッダーを生成し、各サイドケアに新しいスパンを作成して転送します。 ただし、サービス内のヘッダーを操作しないと、完全なリクエスト トレース パスが失われます。

次のヘッダーを考慮する必要があります。

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

これは難しい作業ではありませんが、実装を簡素化するためにすでに用意されています。 多くの図書館 - たとえば、sa-web-app サービスでは、Jaeger ライブラリと OpenTracing ライブラリを単純に追加すると、RestTemplate クライアントはこれらのヘッダーを転送します。 彼の中毒.

センチメント分析アプリケーションは、Flask、Spring、および ASP.NET Core での実装を示していることに注意してください。

箱から出してすぐ (またはほぼ箱から出してすぐに) 何が得られるかは明らかになったので、次に、微調整されたルーティング、ネットワーク トラフィック管理、セキュリティなどを見てみましょう。

ノート。 翻訳。: これについては、Rinor Maloku による Istio に関する資料の次の部分をお読みください。その翻訳は、近い将来、私たちのブログに掲載される予定です。 UPDATE (14月XNUMX日): 第二部 はすでに出版されています。

翻訳者からの追伸

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

• 「Istio でマイクロサービスに戻る」: パート 2 (ルーティング、トラフィック制御), パート 3 (認証と認可);
• «Conduit - Kubernetes 用の軽量サービス メッシュ";
• «サービス メッシュとは何ですか? [マイクロサービスを備えたクラウド アプリケーションに] サービス メッシュが必要な理由は何ですか?";
• «Kubernetes のネットワーキングに関する図入りのガイド。 パート 1 と 2";
• «このサイドカー コンテナはどのようにして [Kubernetes] に配置されたのでしょうか?'。

出所： habr.com