アリババクラウドの専門家が2020年のサービスグリッドの開発動向を説明

著者|王西寧アリババ上級技術専門家

「Alibaba Cloud Native」パブリックアカウントに従い、記事の最後にあるメッセージのやり取りに参加してください。つまり、本の寄付の特典を受け取る機会があります。

この記事は、Alibaba CloudのシニアテクニカルエキスパートであるWang Xiningが執筆した「Istioサービスグリッドテクノロジーの分析と実践」から引用したもので、基本的な概念から始まり、サービスグリッドとIstioについて紹介しています。大きな開発傾向により、Istioサービスグリッドの関連知識が体系的かつ包括的に導入されました。パブリックアカウントの最後でやり取りに参加していただければ幸いです。支払いは当社が行います。テクニカルマンエッセンシャルブック「Istioサービスグリッドテクノロジーの分析と実践」フリーカラー

あり外国 2020年にサービスメッシュ技術の開発は、以下の3つを持っていること尖ったアウトは：

• 急成長するサービスグリッドの需要。
• Istio
  は打ち負かすことが難しく、サービスメッシュテクノロジーの事実上の標準になる可能性があります。
• より多くのサービスメッシュユースケースが出現し、WebAssemblyは新しい可能性をもたらします。

サービスメッシュとは

サービスグリッドテクノロジーの傾向に関するGartner 2018分析レポートは、一連のサービスグリッドテクノロジーを示しています。サービスグリッドテクノロジーを分割するための基礎は、アプリケーションサービスコードがサービスグリッドを認識する必要があるかどうか、およびサービスグリッドがロックされているかどうか、またはロックの程度に基づいています。

プログラミングフレームワークに基づくグリッドテクノロジーは、開発者が適切に構造化されたサービスを構築するのに役立ちますが、これにより、アプリケーションコードとフレームワーク、およびランタイム環境が密結合されます。サイドカーエージェントに基づくサービスメッシュテクノロジーは、開発者にとってこれらの障壁を設定せず、管理と保守を容易にし、ランタイムポリシーを構成するためのより柔軟な方法を提供できます。

マイクロサービス環境では、単一のアプリケーションを複数の独立したコンポーネントに分解し、分散サービスとして展開できます。これらのサービスは通常、ステートレスで一時的であり、動的にスケーラブルであり、コンテナオーケストレーションシステム（ Kubernetes）。

サービスグリッドは通常、コントロールプレーンとデータプレーンで構成されます。具体的には、コントロールプレーンは、専用の名前空間で実行されるサービスのセットです。これらのサービスは、テレメトリデータの集約、ユーザー向けAPIの提供、データプレーンエージェントへの制御データの提供など、いくつかの制御および管理機能を実行します。データプレーンは、各サービスインスタンスの横で実行される一連の透過エージェントで構成されます。これらのエージェントは、サービスとの間のすべてのトラフィックを自動的に処理します。これらのエージェントは透過的であるため、アウトプロセスネットワークスタックとして機能し、テレメトリデータをコントロールプレーンに送信し、コントロールプレーンから制御信号を受信します。

サービスインスタンスは、必要に応じて開始、停止、破棄、再構築、または置換できます。したがって、これらのサービスには、サービスの動的な検出機能と自己修復接続機能をサポートする通信ミドルウェアが必要です。これにより、これらのサービスは、安全で動的かつ信頼性の高い方法で相互に通信できます。これは、サービスグリッドによってサポートされる機能です。

サービスグリッドは、サービス間の通信をより安全、高速、信頼性の高いものにする専用インフラストラクチャレイヤーです。クラウドネイティブアプリケーションを構築する場合は、サービスメッシュが必要です。昨年、サービスメッシュはクラウドネイティブプログラムの重要なコンポーネントになり、最新のクラウドネイティブアプリケーションを含む複雑なサービストポロジを通じて確実にリクエストを配信します。実際、サービスメッシュは通常、アプリケーションが何であるかを知らなくても、アプリケーションコードと共に展開される軽量ネットワークプロキシの組み合わせとして実装されます。

個別のレイヤーとしてのサービスメッシュの概念は、クラウドネイティブアプリケーションの台頭に関連しています。クラウドネイティブモデルでは、単一のアプリケーションに数百のサービスが含まれ、各サービスには数千のインスタンスがあり、各インスタンスは常に変化する状態にある場合があります。これが、Kubernetesのようなコーディネーターの人気と必要性が高まっている理由です。これらのサービス間の通信はますます複雑になるだけでなく、ランタイム環境の最も一般的な部分にもなるため、これらのサービス間の通信を管理することは、エンドツーエンドのパフォーマンスと信頼性を確保するために重要です。

サービスメッシュは、TCP / IPの上の抽象化レイヤーにあるネットワークモデルです。基盤となる3層または4層のネットワークが存在し、あるポイントから別のポイントにバイトを転送できると想定しています。また、ネットワークは環境の他の側面と同様に信頼性がないと想定しているため、サービスネットワークはネットワーク障害にも対応できる必要があります。いくつかの点で、サービスメッシュはTCP / IPに似ています。TCPプロトコルスタックがネットワークエンドポイント間でバイトを確実に転送するメカニズムを抽象化するのと同じように、サービスグリッドはサービス間で要求を確実に転送するメカニズムを抽象化します。TCPと同様に、サービスメッシュは実際のペイロードやそのエンコーディングを考慮せず、サービスAからサービスBへの送信を完了し、障害を処理しながらこの目標を達成することのみを担当します。ただし、TCPとは異なり、サービスメッシュは「機能させる」だけでなく、アプリケーションランタイムに可視性と制御を導入するための統合されたアプリケーションコントロールポイントも提供します。サービスグリッドの明確な目標は、サービスコミュニケーションを見えないインフラストラクチャ領域から移動し、それらを監視、管理、および制御できるエコシステムの一部に変換することです。

クラウドネイティブアプリケーションでは、リクエストの完全な信頼性を確保することは容易ではありません。サービスネットワークは、さまざまな強力なテクノロジーを通じてこの複雑さを管理し、ヒューズ、遅延対応ロードバランシング、最終的には一貫したサービスディスカバリ、再試行、タイムアウトなどのメカニズムをサポートして、信頼性を可能な限り保証します。これらの機能はすべて連携して動作する必要があり、それらが動作する複雑な環境との相互作用も非常に重要です。

たとえば、要求がサービスグリッドを介してサービスに送信される場合、対話プロセスは次の手順に大まかに簡略化できます。

• サービスメッシュコンポーネントは、動的ルーティングルールを適用することにより、要求者が必要とするサービスを決定します。リクエストを本番サービスまたはプレリリースサービスにルーティングする必要がありますか？ローカルのデータセンターまたはクラウド内のサービスにルーティングされますか？テスト対象のサービスの最新バージョンにグレースケールが必要ですか、それとも本番環境で検証済みの古いバージョンにルーティングされますか？これらのルーティングルールはすべて動的に構成可能であり、グローバルに、または任意のトラフィックセグメントに適用できます。
• 正しい宛先を見つけた後、サービスメッシュコンポーネントは、複数のインスタンスを持つ可能性のある関連するサービスディスカバリエンドポイントから対応するインスタンスプールを取得します。この情報が実際にサービスグリッドコンポーネントによって監視される情報と異なる場合は、信頼する情報ソースを決定します。
• サービスメッシュコンポーネントは、最新のリクエストで観測された遅延データを含むさまざまな要因に基づいて、高速応答を返す可能性が最も高いインスタンスを選択します。
• サービスメッシュコンポーネントは、選択したインスタンスにリクエストを送信しようとし、遅延と応答のタイプを記録します。
• さまざまな理由でインスタンスがダウンしているか、リクエストがまったく応答していないか、他の理由でリクエストを処理できない場合、サービスメッシュコンポーネントは、リクエストがべき等
• インスタンスが常にエラーを返す場合、サービスメッシュコンポーネントはそれを負荷分散プールから追い出し、後で定期的に再試行できるようにします。この状況はインターネット分散アプリケーションで非常に一般的であり、パブリックネットワークのインスタンスは、いくつかの理由により瞬間的な障害を引き起こす可能性が非常に高くなります。
• リクエストのタイムアウトが経過すると、サービスメッシュコンポーネントは、雪崩を防ぐために再試行を繰り返して負荷を追加する代わりに、リクエストをプロアクティブに失敗させます。これは、インターネットの分散アプリケーションにとって非常に重要です。さもなければ、小さな障害が雪崩災害を引き起こす可能性があります。
• 同時に、サービスメッシュコンポーネントは、上記の動作のすべての側面をメトリックと分散トラッキングの形式でキャプチャし、これらのデータを集中メトリックシステムまたはリンクトラッキングシステムに送信します。

これらの機能は、ポイントごとの柔軟性とアプリケーション全体の柔軟性を分散アプリケーションに提供することです。大規模な分散システム（構築方法に関係なく）には明確な特性があります。小さな局所的な障害は、システム全体の壊滅的な障害にアップグレードできます。サービスメッシュは、負荷が軽減され、基盤となるシステムが限界に近づいたときにすぐに失敗することによって、これらの障害が拡大するのを防ぐように設計する必要があります。

サービスメッシュが必要な理由

サービスメッシュ自体は新しい機能ではなく、機能の場所の変更に似ています。Webアプリケーションは、サービス通信の複雑さを常に管理する必要があります。過去15年間、サービスメッシュモデルの起源は、これらのアプリケーションの進化に遡ることができます。

今世紀の初めには、中規模のWebアプリケーションの典型的なアーキテクチャは、通常、3層のアプリケーションアーキテクチャであり、アプリケーションロジックレイヤー、Webサービスロジックレイヤー、およびストレージロジックレイヤーに分割されます。レイヤー間の通信は複雑ですが、範囲は限られています。現時点では、アプリケーションアーキテクチャにはグリッドがありませんが、各レイヤーのコード処理ロジック間に通信ロジックがあります。

ネットワークが非常に大規模に発展したとき、このアーキテクチャのアプローチは拡大し始めました。特に、一部の大規模インターネット企業は巨大なトラフィック要求に直面しており、効果的なクラウドネイティブな方法の前身を実現しています。アプリケーションレイヤーは、現在「マイクロサービス」と呼ばれる多くのサービスに分割されており、レイヤーがトポロジを形成しています。通信方法。これらのシステムでは、通常「ファットクライアント」ライブラリの形式であり、これは前述のNetflixに類似したOSSライブラリであり、Hystrixのヒューズ機能が良い例です。これらのコードベースは特定の環境に関連しており、特定の言語とフレームワークの使用を必要としますが、それらはサービス間の通信の形式と機能を管理するために使用されました。これは当時の状況や多くの企業で良い選択でした使用されます。

クラウドネイティブ時代に入った後、クラウドネイティブモデルには2つの重要な要素があります。

• コンテナー（Dockerなど）は、リソースの分離と依存関係の管理を提供します。
• オーケストレーションレイヤー（Kubernetesなど）は、基盤となるハードウェアを同種のリソースプールとして抽象化します。

これらのコードベースコンポーネントにより、アプリケーションは特定の負荷拡張機能を備え、クラウド環境に常に存在するいくつかの障害に対処できます。これには、数百のサービスまたは数千のインスタンスの増加が伴います。スケジューリングインスタンスのビジネスプロセス層では、サービストポロジを介して単一の要求が続くパスは非常に複雑になる可能性があります。同時に、コンテナテクノロジーの普及により、コンテナは各サービスを別の言語で簡単に記述および実行できるようになり、ライブラリメソッドは現在拡張されています。

この複雑さと重要な要求により、アプリケーションはサービス間の通信に専用のレイヤーを必要とするようになりました。これは、アプリケーションコードとは別であり、基盤となる環境の高い動的復元力をキャプチャできます。このレイヤーは、必要なサービスメッシュです。

サービスエージェントは、重要な機能をクラウド環境サービスアーキテクチャに追加するのに役立ちます。各アプリケーションには独自の要件または構成があり、ワークロードターゲットが与えられた場合のエージェントの動作を理解できます。アプリケーションやサービスが増えるにつれ、多数のエージェントを構成および管理することが非常に難しくなる場合があります。さらに、各アプリケーションインスタンスでこれらのエージェントを使用すると、高度な高度な機能を構築する機会が得られます。それ以外の場合は、アプリケーション自体でこれらの機能を実行する必要があります。

サービスエージェントはメッシュ化されたデータプレーンを形成し、それを介してすべてのサービス間のトラフィックが処理および監視されます。データプレーンは、グリッドを通るフローの確立、保護、および制御を担当します。データプレーンの実行方法を管理する管理コンポーネントは、コントロールプレーンと呼ばれます。コントロールプレーンはグリッドの頭脳であり、グリッドユーザーがネットワークの動作を操作するためのパブリックAPIを提供します。

Istioサービスグリッド

Istioは、接続/管理と安全なマイクロサービスのためのオープンプラットフォームです。マイクロサービスグリッドを作成する簡単な方法を提供し、負荷分散、サービス間認証、モニタリング機能を提供します。重要なポイントは上記の機能は、あまり多くのサービスを変更することなく実現できます。Istio自体はオープンソースプロジェクトであり、マイクロサービスを接続、強化、管理、監視するための一貫した方法を提供します。元々は、Google、IBM、Lyftによって作成されたサービスネットワークのオープンソース実装でした。Istioは、透過的方法でサービスアーキテクチャに柔軟性と可観測性を追加するのに役立ちます。Istioを使用すると、アプリケーションはサービスメッシュの一部であることを認識する必要がありません。アプリケーションが外部とやり取りするときはいつでも、Istioはアプリケーションに代わってネットワークトラフィックを処理します。つまり、マイクロサービスを実行している場合、Istioには多くのメリットがあります。

Istioは主に次の機能を提供します。

• トラフィック管理、サービス間のトラフィックとAPI呼び出しの制御、呼び出しの信頼性の向上、厳しい条件下でのネットワークの堅牢性の向上。
• 可観測性、サービス間の依存関係へのアクセス、およびサービス呼び出しのフロー。これにより、問題をすばやく特定する機能を提供します。
• サービス自体を変更せずに、ポリシーの実行、サービスアクセス戦略の制御。

サービスIDとセキュリティは、グリッド内のサービスに検証可能なIDを提供し、サービストラフィックを保護して、信頼度の異なるネットワーク上で循環できるようにします。

Istioの最初の製品版バージョン1.0は2018年7月31日に正式にリリースされ、バージョン1.1は2019年3月にリリースされました。その後、コミュニティは10の小さなバージョンを3か月以内に続けてリリースしました。この本の終わりの時点で、コミュニティはバージョン1.4をリリースしました。

IstioのデータプレーンはデフォルトでEnvoyプロキシを使用し、すぐに動作し、サービスプロキシインスタンスをその隣にデプロイするようにアプリケーションを構成するのに役立ちます。Istioのコントロールプレーンは、エンドユーザーとオペレーション担当者にオペレーションAPIとメンテナンスAPI、プロキシ構成API、セキュリティ設定、ポリシーステートメントなどを提供するコンポーネントで構成されています。これらのコントロールプレーンコンポーネントについては、この本の後続の部分で紹介します。

Istioは元々Kubernetesで実行するように構築されていましたが、コードはデプロイメントプラットフォームの中立的な観点から実装されました。つまり、Kubernetes、OpenShift、Mesos、Cloud FoundryなどのデプロイプラットフォームでIstioベースのサービスメッシュを利用でき、仮想マシンや物理的なベアメタルにIstio環境をデプロイすることもできます。後の章では、プライベートデータセンターを含むクラウドポートフォリオのハイブリッド展開でIstioがいかに強力であるかを示します。この本では、Kubernetesへのデプロイを優先し、より高度な章で仮想マシンとその他のリンクを紹介します。

Istioはギリシャ語で「出航」を意味し、Kubernetesはギリシャ語で「舵取り」または「パイロット」として翻訳できます。そのため、Istioは最初からKubernetesとうまく連携して、分散マイクロサービスアーキテクチャを効率的に実行し、マイクロサービスのセキュリティ、接続、モニタリングのための統一された方法を提供することを期待しています。

各アプリケーションインスタンスの横にあるサービスプロキシを使用すると、アプリケーションは、ヒューズ、タイムアウト、再試行、サービス検出、ロードバランシングなどの機能を実装するための言語固有のエラスティックライブラリを必要としません。さらに、サービスエージェントは、メトリック収集、分散追跡、およびログ収集も処理します。

サービスメッシュ内のトラフィックはIstioサービスプロキシを経由するため、Istioは各アプリケーションに制御ポイントを持ち、ネットワークの動作に影響を与えてガイドします。これにより、サービスオペレーターはカナリアデプロイ、ダークローンチ、階層ローリング、A / Bテストを通じてルーティングトラフィックを制御し、きめ細かなデプロイを実現できます。これらの機能については、後の章で説明します。

コア機能

Istioは、トラフィック管理、セキュリティ、可観測性、プラットフォームサポート、統合、カスタマイズの5つの部分を含む、サービスネットワークで多くの主要な機能を提供します。

1.トラフィック管理

シンプルなルール構成とトラフィックルーティングを通じて、Istioはサービス間のトラフィックとAPI呼び出しを制御できます。Istioは、ヒューズ、タイムアウト、再試行などのサービスレベル属性の構成を簡素化し、A / Bテスト、カナリアデプロイメント、割合ベースのトラフィック分割に基づく段階的デプロイメントなどの重要なタスクを簡単に設定できます。

Istioにはすぐに使用できる障害回復機能があり、問題が発生する前に問題を見つけ、サービス間の呼び出しを最適化してより信頼性を高めることができます。

2.セキュリティ

Istioには、開発者がアプリケーションレベルのセキュリティに集中できる強力なセキュリティ機能があります。Istioは、基盤となる安全な通信チャネルを提供し、サービス通信の認証、承認、および暗号化を大規模に管理します。Istioを使用すると、デフォルトでサービス通信が安全になり、ポリシーを複数のプロトコルとランタイムに一貫して実装できます。重要なことは、これらすべてにアプリケーションの変更がほとんどまたはまったく必要ないことです。

Istioはプラットフォームとは関係ありませんが、Kubernetesネットワーク戦略で使用すると、ネットワークおよびアプリケーションレイヤーでのポッド間の通信やサービス間の通信を保護する機能など、その利点が大きくなります。以降の章では、サービスを共同で保護するためにKubernetesでネットワーク戦略とIstioを組み合わせる方法について説明します。

3.可観測性

Istioには強力な追跡、モニタリング、ロギング機能があり、サービスグリッドのデプロイメントを詳細に理解できます。Istioのモニタリング機能を通じて、サービスのパフォーマンスが上流および下流の機能にどのように影響するかを真に理解でき、そのカスタムダッシュボードはすべてのサービスのパフォーマンスを可視化し、そのパフォーマンスが他のプロセスにどのように影響するかを理解できます。

IstioのMixerコンポーネントは、ポリシー制御とテレメトリの収集を担当し、バックエンドの抽象化と仲介を提供し、各バックエンドインフラストラクチャの実装の詳細からIstioの残りを分離し、運用および保守担当者にグリッドとバックエンドインフラストラクチャを提供します間のすべての相互作用のきめ細かな制御。

これらのすべての機能を使用すると、サービスのサービスレベルターゲットSLOをより効果的に設定、監視、および実装できます。もちろん、最も重要なことは、問題をすばやく効果的に検出して修復することです。

4.プラットフォームのサポート

Istioはプラットフォームに依存せず、その目標は、クロスクラウド、オンプレミス、Kubernetes、Mesosなどのさまざまな環境で実行することです。Istioは、KubernetesまたはNomad with Consulにデプロイできます。Istioは現在以下をサポートしています。

• Kubernetesにデプロイされたサービス。
• 領事に登録されたサービス。
• さまざまな仮想マシンで実行されるサービス。

5.統合とカスタマイズ

Istioのポリシー実装コンポーネントを拡張およびカスタマイズして、ACL、ロギング、モニタリング、割り当て、監査などの既存のソリューションと統合できます。

さらに、バージョン1.0以降、IstioはMCP（Mesh Conf？Iguration Protocol、メッシュ構成プロトコル）に基づく構成配布をサポートしています。MCPを使用すると、外部システムを簡単に統合できます。たとえば、MCPサーバーを自分で実装して、Istioに統合できます。MCPサーバーは、次の2つの主要機能を提供できます。

• 外部サービス登録システムを接続して監視し、最新のサービス情報（Eureka、ZooKeeper、その他のシステムなど）を取得します。
• 外部サービス情報をIstio ServiceEntryに変換
  し、MCPリソースを通じて公開します。

Istioを使用する理由

モノリシックアプリケーションから分散型マイクロサービスアーキテクチャに変換する過程で、開発者と運用担当者は多くの課題に直面し、Istioはこれらの問題を解決できます。規模と複雑さが増すにつれ、サービスグリッドの理解と管理が難しくなっています。さまざまな要件には、サービスの検出、ロードバランシング、障害回復、インデックスの収集と監視、A / Bテストなどのより複雑な操作とメンテナンスが含まれます。カナリアリリース、現在の制限、アクセス制御、エンドツーエンド認証など。Istioは、サービスグリッド全体の動作に関する洞察と動作制御を提供することにより、マイクロサービスアプリケーションの多様なニーズを満たす完全なソリューションを提供します。

Istioは、デプロイされたサービスのネットワークを確立する簡単な方法を提供します。このネットワークには、負荷分散、サービス間認証、モニタリングなどの機能があり、サービスコードを少しまたはまったく変更する必要がありません。サービスでIstioをサポートするには、特別なSidecarプロキシを環境にデプロイし、Istioコントロールプレーンを使用してプロキシを構成および管理し、マイクロサービス間のすべてのネットワーク通信をインターセプトする必要があります。

さらに、サービス指向アーキテクチャー（SOA）エンタープライズサービスバス（ESB）は、サービスグリッドといくつかの類似点があります。SOAアーキテクチャーでは、ESBはアプリケーションサービスに対して透過的です。知覚。サービスグリッドは同様の動作を行うことができます。サービスグリッドは、サービス間の呼び出しを簡略化するために、ESBと同様にアプリケーションに対して透過的である必要があります。もちろん、ESBには対話型プロトコルのリレー、メッセージ変換、コンテンツベースのルーティングなども含まれており、サービスメッシュはESBが行うすべての機能を担当するわけではありません。サービスグリッドは、再試行、タイムアウト、フューズを通じてサービスリクエストに回復力を提供し、サービスディスカバリやロードバランシングなどのサービスも提供します。複雑なビジネス変換、ビジネスプロセスオーケストレーション、異常なビジネスプロセス、およびサービスオーケストレーション機能は、サービスグリッドソリューションの範囲には属していません。ESBの集中型システムと比較して、サービスグリッドのデータプレーンは高度に分散され、そのエージェントとアプリケーションが共存するため、ESBアーキテクチャで頻繁に発生する単一障害点のボトルネックが解消されます。

もちろん、サービスグリッドが解決しない問題を知ることも必要です。Istioなどのサービスグリッドテクノロジーは、通常、分散アーキテクチャの多くの領域に影響を与えることができる強力なインフラストラクチャ機能を提供しますが、発生する可能性のあるすべての問題を解決できるわけではありません。質問。理想的なクラウドアーキテクチャは、実装の各層からさまざまな懸念を分離できます。

インフラストラクチャの下位レベルでは、インフラストラクチャと、自動展開のためのインフラストラクチャ機能を提供する方法にさらに注意が向けられています。これにより、コンテナ、Kubernetes、仮想マシンなど、さまざまなプラットフォームにコードをデプロイできます。Istioは、使用する自動デプロイメントツールを制限しません。

より高いビジネスアプリケーションレベルでは、アプリケーションビジネスロジックは、企業がコア競争力を維持するための差別化された資産です。これらのコード資産には、単一のビジネス機能と呼び出す必要のあるサービスが含まれています。これらのサービスは、これらのサービスの相互作用を実行する方法、それらをまとめる方法、および障害が発生したときに実行される操作をこの順序で実行します。Istioはビジネスロジックの実装や置き換えを行いません。サービスオーケストレーション自体を実行したり、コンテンツの変換やビジネス負荷の強化を提供したり、負荷を分割または集約したりしません。これらの関数は、アプリケーションのライブラリとフレームワークに任せるのが最適です。

次の図は、クラウドネイティブアプリケーションでの懸念の分離に関するものです。Istioはアプリケーションレイヤーをサポートし、下位レベルのデプロイレイヤーの上にあります。
Istioは、デプロイメントプラットフォームとアプリケーションコードの間の接続の役割を果たします。その役割は、リクエストの一部である外部メタデータ（HTTPヘッダーなど）に基づいてコンテンツベースのルーティングを実行できる、アプリケーションからの複雑なネットワークロジックの削除を容易にすることです。サービスと要求されたメタデータのマッチングに基づいて、きめ細かなフロー制御とルーティングも実行できます。また、送信を保護してセキュリティトークン検証をオフロードしたり、サービスオペレーターが定義した割り当てや使用ポリシーを実装したりすることもできます。

Istioの機能、他のシステムとの類似点、およびアーキテクチャーでの位置を理解すると、過去に遭遇した可能性のある有望なテクノロジーと同じ間違いを犯す可能性があります。

成熟度とサポートレベル

Istioコミュニティは、各コンポーネント機能の相対的な成熟度とサポートレベルについて、さまざまな機能段階の定義を提案しています。表1-1に示すように、アルファ、ベータ、安定は、それぞれの状態を説明するために使用されます。

表1-2は、ベータ版および安定版の機能段階に達した、抽出したIstio 1.4バージョンの既存の機能のリストです。この情報はリリースごとに更新されます。更新状況については、公式Webサイトを参照してください。

もちろん、IstioにはまだIstio CNIプラグインなど、Alpha状態のいくつかの機能があり、これはistio-initコンテナーを置き換えて同じネットワーク機能を完了することができ、Istioユーザーが追加のKubernetes RBAC承認を申請する必要がなく、Envoyでカスタムフィルターを使用する必要もありません能力など その後の継続的な改善により、これらの機能は徐々に安定し、生産に使用できるようになると考えられています。

まとめ

Istioは現在、業界のサービスグリッド分野で最も人気のある実装であり、その機能により、ハイブリッド環境でのクラウドネイティブサービスアーキテクチャアプリケーションの操作と操作を簡素化できます。Istioを使用すると、開発者はお気に入りのプログラミング言語を使用してサービス機能を構築することに集中できるため、開発者の生産性を効果的に向上させると同時に、分散システムの問題を解決するコードをビジネスコードに混在させる必要がなくなります。

Istioは、活発でオープンで多様なコミュニティを持つ完全にオープンな開発プロジェクトです。その目的は、開発者と運用担当者があらゆる環境で迅速にマイクロサービスをリリースして維持できるようにすることです。基盤となるネットワークを完全に可視化し、一貫した制御とセキュリティ機能を獲得します。この本の後続の部分では、Istioの機能を使用して、クラウドネイティブな世界でマイクロサービスを実行する方法を示します。

この記事は、「Istio Service Grid Analysis and Actual Combat」からの抜粋であり、発行元の許可を得て公開されています。この本は、Alibaba CloudのシニアテクニカルエキスパートであるWang Xiningによって書かれました。Istioの基本原則と実際の開発を詳細に紹介しています。選択した多数のケースとリファレンスコードが含まれており、Istio開発をすぐに開始できます。ガートナーは、2020年にサービスグリッドがすべての主要なコンテナー管理システムの標準技術になると考えています。この本は、マイクロサービスとクラウドネイティブに興味があるすべての読者に適しています。この本を詳しく読むことをお勧めします。

推奨読書：
[1] Alibaba Cloud Service Grid ASMパブリックベータ攻撃シリーズ1：ASMの
記事のリンクをすぐに理解する：https : //yq.aliyun.com/articles/748761
[2] Alibaba Cloud Service Grid ASM拡張性（1）：ASM
記事リンクのEnvoyFilterを介してHTTPリクエストヘッダーを追加：https : //yq.aliyun.com/articles/748807

「Alibaba Cloud Nativeは、マイクロサービス、サーバーレス、コンテナ、サービスメッシュ、およびその他の技術分野に焦点を当て、クラウドネイティブの一般的なテクノロジートレンド、クラウドネイティブの大規模なランディングプラクティスに焦点を当て、クラウドネイティブの開発者を最もよく理解している公開番号です。」

元のリンク
この記事はYunqiコミュニティの元のコンテンツであり、許可なしに複製することはできません。