訳しながら理解していくIstio_What is Istio?編

はじめに

Istioのドキュメントって英語だし、英検3級レベルで英語力のない私にはつらい・・・
そして、一回(google翻訳を使って)訳しながら読んでまた忘れてまた(google翻訳を使って)訳すを繰り返すのをやめたい。
調べるときは全文を見ずに、必要な部分だけを見てたりするので、公式ドキュメントを訳しながら全体を理解していこうと思う。

英語読むのめんどくせーーーとなっている人の助けになればと思い公開した

今回は What is Istio

注意事項

• 基本的にGoogle翻訳のまんまです。
• 一応、意味が分かるようには訳してるつもりですが、ちょいちょい意味分からない部分もあります。
  誤訳がある可能性があるので、最後はちゃんと公式ドキュメントを読みましょう
• 私の知りたい部分からやるので、訳す部分はバラバラになります。
• 公式ドキュメントに記載されていない部分(自分で調べた部分とか)はitalicで記載しています。
• 1.0でのドキュメントを記載

What is Istio?

クラウドプラットフォームは、クラウドプラットフォームを使用する組織に豊富なメリットをもたらします。しかし、クラウドを採用するとDevOpsチームに負担をかける可能性は否定できない。開発者はマイクロサービスを使用して移植性を設計する必要がありますが、オペレーターは非常に大規模なハイブリッドおよびマルチクラウドのデプロイを管理しています。Istioを使用すると、サービスを接続、保護、制御、および監視できます。

高いレベルでは、Istioはこれらの導入の複雑さを軽減し、開発チームの負担を軽減します。これは、既存の分散アプリケーションに透過的にレイヤする完全にオープンソースサービスメッシュです。また、任意のロギングプラットフォーム、テレメトリまたはポリシーシステムに統合できるようにするAPIも含めて、プラットフォームです。Istioの多様な機能セットにより、分散型マイクロサービスアーキテクチャを正常にかつ効率的に実行でき、マイクロサービスを安全に接続し、監視する統一された方法が提供されます。

What is a service mesh?

Istioは、モノリシックアプリケーションが分散マイクロサービスアーキテクチャに移行するにつれ、開発者とオペレータが直面する課題に対応します。方法を確認するには、Istioのサービスメッシュを詳しく見てください。

用語「サービスメッシュ」は、そのようなアプリケーションおよびそれらの間の相互作用を構成するマイクロサービスのネットワークを記述するために使用される。サービスメッシュのサイズと複雑さが増すにつれて、理解と管理が難しくなります。要件には、検出(discovery)、ロードバランシング、障害回復、メトリック、および監視が含まれます。サービスメッシュには、A/Bテスト、カナリーリリース、レート制限、アクセス制御、エンドツーエンド認証など、より複雑な運用要件が存在することもよくあります。

Istioは、サービスメッシュ全体に対する動作上の洞察と動作制御を提供し、マイクロサービスアプリケーションの多様な要件を満たすための完全なソリューションを提供します。

Why use Istio?

Istioを使用すると、サービスコードを変更することなく、ロードバランシング、サービス間認証、監視などのサービスを展開したネットワークを簡単に作成できます。マイクロサービス間のすべてのネットワーク通信を傍受し、コントロールプレーン機能を使用してIstioを構成および管理する特別なサイドカープロキシを環境全体に展開することにより、サービスにIstioサポートを追加します。これには以下が含まれる。

• HTTP、gRPC、WebSocket、およびTCPトラフィックの自動ロードバランシング。
• 豊富(rich)なルーティングルール、再試行、フェイルオーバー、および障害インジェクションによるトラフィック動作のきめ細かな制御
• アクセス制御、レート制限、クォータをサポートする、プラガブルなポリシーレイヤーと構成API。
• クラスタ内のすべてのトラフィックの自動メトリック、ログ、およびトレース（クラスタの入力と出力を含む）。
• 強力なIDベースの認証と認可を使用して、クラスタ内のサービス間通信を保護します。

Istioは拡張性を考慮して設計されており、多様な導入ニーズに対応しています。

Core features

Istioは、サービスのネットワーク全体にわたって、次のような多くの重要な機能を一様に提供します。

Traffic management

Istioの簡単なルール設定とトラフィックルーティングにより、サービス間のトラフィックやAPIコールのフローを制御できます。Istioは、サーキットブレーカー、タイムアウト、再試行などのサービスレベルプロパティの設定を簡素化し、A/Bテスト、カナリーロールアウト、パーセンテージベースのトラフィック分割による段階的なロールアウトなどの重要なタスクを設定する手間を軽減します。

トラフィックの可視性とすぐに使える障害回復機能により、問題が発生する前に問題を把握し、コールの信頼性を高め、ネットワークの堅牢性を向上させることができます。

Security

Istioのセキュリティ機能により、開発者はアプリケーションレベルのセキュリティに専念できます。Istioは、基礎となるセキュアな通信チャネルを提供し、規模でのサービス通信の認証、認可、および暗号化を管理します。Istioでは、デフォルトでサービス通信が保護されているため、アプリケーションの変更がほとんどまたはまったくなく、さまざまなプロトコルやランタイムに一貫してポリシーを適用できます。

Istioはプラットフォームに依存せず、Kubernetes（またはインフラストラクチャ）ネットワークポリシーで使用しているため、ネットワークとアプリケーション層でのポッドツーポッドやサービスとサービスの通信を保護するなど、さらに大きな利点があります。

Observability

Istioの堅牢なトレース、監視、ロギングにより、サービスメッシュの展開を深く理解することができます。Istioの監視機能を使用してサービスのパフォーマンスがアップストリームとダウンストリームにどのように影響するのかを理解し、カスタムダッシュボードですべてのサービスのパフォーマンスを把握し、パフォーマンスが他のプロセスにどのような影響を与えるかを確認できます。

Istioのミキサーコンポーネントは、ポリシーコントロールとテレメトリコレクションを担当します。バックエンドの抽象化と仲介、Istioの残りの部分を個々のインフラストラクチャバックエンドの実装の詳細から隔離し、オペレータにメッシュとインフラストラクチャのバックエンド間のすべての相互作用をきめ細かく制御できるようにします。

これらの機能を使用すると、SLOをより効果的に設定、監視、適用することができます。もちろん、結論は、問題を迅速かつ効率的に検出し修正できるということです。

Platform support

Istioはプラットフォームに依存せず、クラウド、オンプレミス、Kubernetes、Mesosなどのさまざまな環境で動作するように設計されています。
あなたはKubernetesに、またはConsomと共にNomadにIstioを配備することができます。 Istioは現在以下をサポートしています：

• Kubernetesでのサービスデプロイ
• Consulに登録されたサービス
• 個々の仮想マシン上で実行されるサービス

Integration and customization

Istioのポリシー施行コンポーネントは、ACL、ログ、監視、クォータ、監査などの既存のソリューションと統合するために拡張およびカスタマイズすることができます。

Architecture

Istioサービスメッシュは、論理的に データプレーン(data plane) と コントロールプレーン(control plane) に分割されます。

• data planeは、サイドカーとして配置されたインテリジェントプロキシ（Envoy）のセットで構成されています。これらのプロキシは、汎用ポリシーとテレメトリーハブであるMixerと一緒に、マイクロサービス間のすべてのネットワーク通信を仲介して制御します。
• control planeは、トラフィックをルーティングするためにプロキシを管理および構成します。さらに、コントロールプレーンはミキサーを設定してポリシーを適用し、テレメトリを収集します。

次の図は、各プレーンを構成するさまざまなコンポーネントを示しています。

Envoy

IstioはEnvoyプロキシの拡張バージョンを使用します。EnvoyはC ++で開発された高性能プロキシで、サービスメッシュ内のすべてのサービスのすべてのインバウンドおよびアウトバウンドトラフィックを仲介します。IstioはEnvoyの多くの組み込み機能を活用しています。例えば

• 動的サービスディスカバリ
• Load balancing
• TLS termination
• HTTP/2 and gRPC proxies
• サーキットブレーカー
• ヘルスチェック
• ％ベースのトラフィック分割による段階的なロールアウト
• フォルトインジェクション
• リッチインジェクション

Envoiは、同じKubernetesポッド内の関連するサービスにsidecarとして配備されています。このdeploymentにより、Istioはトラフィックの振る舞いに関する豊富なsignalsを属性(attributes)として抽出することができます。Istioは、Mixerでこれらの属性を使用してポリシーの決定を行い、監視システムに送信してメッシュ全体の動作に関する情報を提供することができます。

サイドカープロキシモデルを使用すると、コードを再構築または書き換えなくても、既存のデプロイメントにIstio機能を追加することができます。このアプローチを選択した理由について、Design Goalsで詳しく読むことができます。

Mixer

Mixerはプラットフォームに依存しないコンポーネントです。Mixerは、サービスメッシュ全体でアクセス制御と使用ポリシーを実施し、Envoyプロキシやその他のサービスからテレメトリデータを収集します。プロキシは要求レベルの属性(attributes)を抽出し、評価のためにMixerに送信します。この属性抽出とポリシー評価の詳細については、「Mixer Configuration」のドキュメントを参照してください。

Mixerには、柔軟なプラグインモデルが含まれています。このモデルにより、Istioはさまざまなホスト環境およびインフラストラクチャーのバックエンドとのインターフェースが可能になります。したがって、Istioは、EnvoyプロキシおよびIstio管理サービスをこれらの詳細から抽象化します。

Pilot

Pilotは、Envoyサイドカー、インテリジェントルーティング（A/Bテスト、カナリーデプロイメントなど）、弾力性（タイムアウト、リトライ、サーキットブレーカーなど）のトラフィック管理機能を提供します。

Pilotは、トラフィックの動作をEnvoy固有の構成に制御する高水準のルーティングルールを変換し、実行時にサイドカーに伝達します。Pilotはプラットフォーム固有のサービス発見メカニズムを抽象化し、EnvoyデータプレーンAPIに準拠するサイドカーが消費できる標準フォーマットにそれらを合成します。この緩やかな結合により、Istioは、Kubernetes、Consul、またはNomadなどの複数の環境で動作し、トラフィック管理用の同じオペレータインターフェイスを維持できます。

Citadel

Citadelは、強力なサービス対サービスとエンドユーザー認証を提供します。組み込みのIDと資格情報管理が組み込まれています。Citadelを使用して、サービスメッシュ内の暗号化されていないトラフィックをアップグレードできます。Citadelを使用すると、オペレータはネットワークコントロールではなくサービスアイデンティティに基づいてポリシーを適用できます。リリース0.5から、Istioの認証機能を使用して、サービスにアクセスできるユーザーを制御できます。

Galley

Galleyは、他のIstioコントロールプレーンコンポーネントに代わって、ユーザーが作成したIstio API構成を検証します。時間が経つにつれて、GalleyはIstioのトップレベル構成の取り込み、処理、および配信コンポーネントとして責任を引き継ぐことになります。Istioコンポーネントの残りの部分を、基礎となるプラットフォーム（Kubernetesなど）からユーザー設定を取得する詳細から隔離する役割を担います。

Design Goals

Istioのアーキテクチャーにいくつかの重要な設計目標が知らされ(informed)ました。これらの目標は、システムを大規模かつ高性能なサービスに対応できるようにするために不可欠です。

• Maximize Transparency: Istioを採用するには、オペレーターまたは開発者は、システムから実際の価値を引き出すために最小限の作業を行う必要があります。この目的のために、Istioは自動的にサービス間のすべてのネットワークパスに自分自身を注入することができます。Istioはサイドカープロキシを使用してトラフィックをキャプチャし、可能であれば、ネットワーク層を自動的にプログラミングして、配備されたアプリケーションコードを変更せずにこれらのプロキシを通過するトラフィックをルーティングします。Kubernetesでは、プロキシはポッドに注入され、トラフィックはiptablesルールをプログラムすることによって取得されます。サイドカープロキシが注入され、トラフィックルーティングがプログラムされると、Istioはすべてのトラフィックを仲介できます。Istioをdeploymentに適用する場合、オペレータは提供される機能のリソースコストを最小限に抑えることができます。コンポーネントとAPIは、すべてパフォーマンスと規模を考慮して設計する必要があります。
• Incrementality: オペレータと開発者がIstioが提供する機能の依存度が高まるにつれて、システムはニーズに沿って成長しなければなりません。新しい機能を追加し続けながら、ポリシーシステムを拡張し、他のポリシーや制御ソースと統合し、メッシュの動作に関する信号を解析用に他のシステムに伝播する能力が最大限必要です。ポリシーランタイムは、他のサービスをプラグインするための標準の拡張メカニズムをサポートしています。さらに、メッシュが生成する新しい信号に基づいてポリシーを適用できるように、ボキャブラリの拡張も可能です。
• Portability: Istioが使用されるエコシステムは、さまざまな次元に沿って変化します。Istioは最小限の労力であらゆるクラウド環境またはオンプレミスで動作する必要があります。Istioベースのサービスを新しい環境に移植する作業は自明(trivial)でなければなりません。Istioを使用すると、複数の環境に展開された単一のサービスを運用することができます。たとえば、複数のクラウドに展開して冗長性を持たせることができます。
• Policy Uniformity: サービス間のAPI呼び出しに対するポリシーの適用は、メッシュの動作を大幅に制御します。ただし、必ずしもAPIレベルで表現されていないリソースにポリシーを適用することも同様に重要です。たとえば、MLトレーニングタスクで消費されたCPUの量にクォータを適用すると、作業を開始したコールにクォータを適用するよりも便利です。このため、Istioはポリシーシステムをプロキシサイドカーに焼き付けるのではなく、独自のAPIを使用して独自のサービスとして維持し、サービスを必要に応じて直接統合できるようにします。