デプロイメントモデル
Istioの本番環境へのデプロイを設定する際には、いくつかの質問に答える必要があります。メッシュは単一のクラスターに限定されるのか、それとも複数のクラスターに分散されるのか？すべてのサービスは単一の完全に接続されたネットワークに配置されるのか、それとも複数のネットワークにまたがるサービスを接続するためにゲートウェイが必要になるのか？単一のコントロールプレーンがあり、潜在的にクラスター間で共有されるのか、それとも高可用性（HA）を確保するために複数のコントロールプレーンがデプロイされるのか？すべてのクラスターは単一のマルチクラスターサービスメッシュに接続されるのか、それともマルチメッシュデプロイメントに連合されるのか？
これらすべての質問は、とりわけ、Istioデプロイメントの構成の独立した側面を表しています。
- 単一または複数のクラスター
- 単一または複数のネットワーク
- 単一または複数のコントロールプレーン
- 単一または複数のメッシュ
複数のクラスターを含む本番環境では、複数のデプロイモデルを組み合わせて使用できます。たとえば、HAのために複数のコントロールプレーンを持つことが推奨されますが、単一の共有コントロールプレーンを持つ2つのクラスターをデプロイし、異なるネットワークに2番目のコントロールプレーンを持つ3番目のクラスターを追加することで、3クラスターのデプロイメントでこれを実現できます。その後、3つのクラスターすべてが両方のコントロールプレーンを共有するように構成できるため、すべてのクラスターにHAを確保するための2つのコントロールソースがあります。
適切なデプロイモデルの選択は、ユースケースの分離、パフォーマンス、およびHAの要件によって異なります。このガイドでは、Istioデプロイメントを構成する際のさまざまなオプションと考慮事項について説明します。
クラスタモデル
アプリケーションのワークロードインスタンスは、1つ以上のクラスターで実行されます。分離、パフォーマンス、および高可用性のため、クラスターをアベイラビリティーゾーンとリージョンに限定できます。
本番システムは、要件に応じて、複数のゾーンまたはリージョンにまたがる複数のクラスターで実行し、クラウドロードバランサーを活用して、ロケールやゾーンまたはリージョンフェイルオーバーなどの処理を行うことができます。
ほとんどの場合、クラスターは構成とエンドポイント検出の境界を表します。たとえば、各Kubernetesクラスターには、クラスターの構成を管理し、ポッドが起動または停止するときのサービスエンドポイント情報を提供するAPIサーバーがあります。Kubernetesはこの動作をクラスターごとに構成するため、このアプローチは誤った構成によって引き起こされる可能性のある問題を制限するのに役立ちます。
Istioでは、単一のサービスメッシュが任意の数のクラスターにまたがるように構成できます。
シングルクラスタ
最も単純なケースでは、Istioメッシュを単一のクラスターに限定できます。通常、クラスターは単一のネットワーク上で動作しますが、インフラストラクチャプロバイダーによって異なります。単一のクラスターと単一のネットワークモデルにはコントロールプレーンが含まれており、最もシンプルなIstioデプロイメントになります。
単一クラスターのデプロイメントはシンプルさを提供しますが、フォールトアイソレーションやフェールオーバーなどの他の機能が欠けています。高可用性が必要な場合は、複数のクラスターを使用する必要があります。
マルチクラスタ
複数のクラスターを含むように単一のメッシュを構成できます。マルチクラスターデプロイメントを単一のメッシュ内で使用すると、単一クラスターデプロイメントの他に次の機能が提供されます。
- フォールトアイソレーションとフェールオーバー：
cluster-1がダウンした場合、cluster-2にフェールオーバーします。 - ロケーション対応のルーティングとフェールオーバー：最も近いサービスにリクエストを送信します。
- さまざまなコントロールプレーンモデル：さまざまなレベルの可用性をサポートします。
- チームまたはプロジェクトの分離：各チームは独自のクラスターセットを実行します。
マルチクラスターデプロイメントは、より高いレベルの分離と可用性を提供しますが、複雑さが増します。システムに高可用性の要件がある場合は、複数のゾーンとリージョンにまたがるクラスターが必要になる可能性があります。構成の変更や新しいバイナリリリースを単一のクラスターでカナリアデプロイできます。構成の変更は、少量のユーザートラフィックにのみ影響します。さらに、クラスターに問題が発生した場合は、問題に対処するまで、トラフィックを近くのクラスターに一時的にルーティングできます。
クラウドプロバイダーでサポートされているネットワークとオプションに基づいて、クラスター間通信を構成できます。たとえば、2つのクラスターが同じ基盤ネットワーク上にある場合、ファイアウォールルールを構成するだけでクラスター間通信を有効にできます。
マルチクラスターメッシュ内では、名前空間の同等性の概念に従って、すべてのサービスがデフォルトで共有されます。トラフィック管理ルールは、マルチクラスタートラフィックの動作をきめ細かく制御します。
マルチクラスタでのDNS
クライアントアプリケーションが何らかのホストにリクエストを行う場合、まずホスト名のDNSルックアップを実行して、リクエストを続行する前にIPアドレスを取得する必要があります。Kubernetesでは、クラスター内にあるDNSサーバーが通常、構成されたService定義に基づいてこのDNSルックアップを処理します。
Istioは、DNSルックアップによって返された仮想IPを使用して、リクエストされたアクティブなサービスのエンドポイントリスト全体でロードバランスを行います。このとき、構成されたIstioルーティングルールを考慮に入れます。Istioは、Kubernetes Service/EndpointまたはIstio ServiceEntryのいずれかを使用して、ホスト名からワークロードIPアドレスへの内部マッピングを構成します。
この2段階の名前付けシステムは、複数のクラスターがある場合に複雑になります。Istioは本質的にマルチクラスター対応ですが、Kubernetesは（今日では）そうではありません。このため、DNSルックアップを成功させ、リクエストを正常に送信するには、クライアントクラスターにサービスのDNSエントリが必要です。これは、クライアントクラスターで実行されているサービスのポッドのインスタンスがない場合でも当てはまります。
DNSルックアップが成功するようにするには、そのサービスを使用する各クラスターにKubernetes Serviceをデプロイする必要があります。これにより、リクエストの送信元に関係なく、DNSルックアップに合格し、適切なルーティングのためにIstioに渡されます。これは、Kubernetes Serviceではなく、Istio ServiceEntryでも実現できます。ただし、ServiceEntryはKubernetes DNSサーバーを構成しません。つまり、DNSは、手動で構成するか、アドレス自動割り当てなどの自動ツールを使用して構成する必要があります。Istio DNSプロキシの機能を使用します。
ネットワークモデル
Istioは、直接到達可能なワークロードインスタンスを参照するために、ネットワークの簡略化された定義を使用します。たとえば、デフォルトでは、単一のクラスター内のすべてのワークロードインスタンスは同じネットワーク上にあります。
多くの本番システムでは、隔離と高可用性を実現するために複数のネットワークやサブネットが必要です。Istioは、様々なネットワークトポロジにサービスメッシュを拡張することをサポートしています。このアプローチにより、既存のネットワークトポロジに適合するネットワークモデルを選択できます。
シングルネットワーク
最も単純なケースでは、サービスメッシュは単一の完全に接続されたネットワーク上で動作します。単一ネットワークモデルでは、すべてのワークロードインスタンスは、Istioゲートウェイなしで直接互いに到達できます。
単一のネットワークでは、Istioは、ワークロードインスタンスを直接アドレス指定できる機能により、メッシュ全体で均一な方法でサービスコンシューマーを構成できます。ただし、複数のクラスターにまたがる単一のネットワークの場合、サービスとエンドポイントはIPアドレスが重複することはできません。
マルチネットワーク
単一のサービスメッシュを複数のネットワークにまたがって拡張できます。このような構成はマルチネットワークと呼ばれます。
マルチネットワークは、単一ネットワークに加えて次の機能を提供します
- サービスエンドポイントのIPまたはVIP範囲の重複
- 管理境界の横断
- フォールトトレランス
- ネットワークアドレスのスケーリング
- ネットワークセグメンテーションを必要とする標準への準拠
このモデルでは、異なるネットワーク内のワークロードインスタンスは、1つ以上のIstioゲートウェイを介してのみ互いに到達できます。Istioは、分割されたサービスディスカバリーを使用して、コンシューマーにサービスエンドポイントの異なるビューを提供します。ビューは、コンシューマーのネットワークによって異なります。
このソリューションでは、すべてのサービス（またはサブセット）をゲートウェイ経由で公開する必要があります。クラウドベンダーは、パブリックインターネットでサービスを公開する必要がないオプションを提供する場合があります。そのようなオプションが存在し、要件を満たしている場合は、それが最良の選択となるでしょう。
コントロールプレーンモデル
Istioメッシュは、メッシュ内のワークロードインスタンス間のすべての通信を構成するためにコントロールプレーンを使用します。ワークロードインスタンスは、構成を取得するためにコントロールプレーンインスタンスに接続します。
最も単純なケースでは、単一のクラスターでコントロールプレーンを使用してメッシュを実行できます。
独自のローカルコントロールプレーンを持つこのようなクラスターは、プライマリークラスターと呼ばれます。
マルチクラスターデプロイメントでは、コントロールプレーンインスタンスを共有することもできます。この場合、コントロールプレーンインスタンスは、1つ以上のプライマリークラスターに存在できます。独自のコントロールプレーンを持たないクラスターは、リモートクラスターと呼ばれます。
マルチクラスターメッシュでリモートクラスターをサポートするには、プライマリークラスターのコントロールプレーンが安定したIP（クラスターIPなど）を介してアクセスできる必要があります。ネットワークにまたがるクラスターの場合、これはIstioゲートウェイを介してコントロールプレーンを公開することで実現できます。クラウドベンダーは、パブリックインターネットでコントロールプレーンを公開せずにこの機能を提供するためのオプション（内部ロードバランサーなど）を提供する場合があります。そのようなオプションが存在し、要件を満たしている場合は、それが最良の選択となるでしょう。
複数のプライマリークラスターを持つマルチクラスターデプロイメントでは、各プライマリークラスターは、同じクラスターにあるKubernetes APIサーバーから構成（Service、ServiceEntry、DestinationRuleなど）を受け取ります。したがって、各プライマリークラスターには、独立した構成ソースがあります。プライマリークラスター間で構成が重複するため、変更を展開する際には追加の手順が必要になります。大規模な本番システムでは、構成のロールアウトを管理するために、CI/CDシステムなどのツールを使用してこのプロセスを自動化する場合があります。
メッシュ内のプライマリークラスターでコントロールプレーンを実行する代わりに、リモートクラスターだけで構成されるサービスメッシュは、外部コントロールプレーンによって制御できます。これにより、分離された管理と、メッシュを構成するデータプレーンサービスからのコントロールプレーンデプロイメントの完全な分離が提供されます。
クラウドベンダーのマネージドコントロールプレーンは、外部コントロールプレーンの典型的な例です。
高可用性を実現するには、クラスター、ゾーン、またはリージョン全体に複数のコントロールプレーンをデプロイする必要があります。
このモデルには、次の利点があります
可用性の向上：コントロールプレーンが利用できなくなった場合、停止の範囲は、そのコントロールプレーンによって管理されるクラスター内のワークロードのみに限定されます。
構成の分離：1つのクラスター、ゾーン、またはリージョンで構成を変更しても、他のクラスターに影響を与えることはありません。
制御されたロールアウト：構成のロールアウト（一度に1つのクラスターなど）をより細かく制御できます。特定のプライマリークラスターによって制御されるメッシュのサブセクションで構成変更をカナリア化することもできます。
選択的なサービス可視性：サービス可視性をメッシュの一部に制限して、サービスレベルの分離を確立するのに役立ちます。たとえば、管理者は
HelloWorldサービスをクラスターAにデプロイすることを選択できますが、クラスターBにはデプロイしないことを選択できます。クラスターBからHelloWorldを呼び出そうとすると、DNSルックアップが失敗します。
次のリストは、可用性によるコントロールプレーンデプロイメントの例をランク付けしたものです
- リージョンごとに1つのクラスター（可用性が最も低い）
- リージョンごとに複数のクラスター
- ゾーンごとに1つのクラスター
- ゾーンごとに複数のクラスター
- 各クラスター（可用性が最も高い）
複数コントロールプレーンでのエンドポイント検出
Istioコントロールプレーンは、各プロキシにサービスエンドポイントのリストを提供することにより、メッシュ内のトラフィックを管理します。マルチクラスターシナリオでこれを機能させるには、各コントロールプレーンがすべてのクラスターのAPIサーバーからエンドポイントを監視する必要があります。
クラスターのエンドポイントディスカバリーを有効にするには、管理者はremote secretを生成し、メッシュ内の各プライマリークラスターにデプロイします。remote secretには、クラスター内のAPIサーバーへのアクセスを許可する資格情報が含まれています。その後、コントロールプレーンは接続してクラスターのサービスエンドポイントをディスカバリーし、これらのサービスのクロスクラスターロードバランシングを有効にします。
デフォルトでは、Istioは、各クラスターのエンドポイント間でリクエストを均等にロードバランシングします。地理的リージョンにまたがる大規模なシステムでは、トラフィックが同じゾーンまたはリージョンにとどまることを優先するために、ロカリティロードバランシングを使用することが望ましい場合があります。
一部の高度なシナリオでは、クラスター間のロードバランシングは望ましくない場合があります。たとえば、ブルー/グリーンデプロイメントでは、異なるバージョンのシステムを異なるクラスターにデプロイする場合があります。この場合、各クラスターは実質的に独立したメッシュとして動作しています。この動作は、いくつかの方法で実現できます
クラスター間でリモートシークレットを交換しないでください。これにより、クラスター間で最も強力な分離が提供されます。
VirtualServiceとDestinationRuleを使用して、サービスの2つのバージョン間のルーティングを禁止します。
いずれの場合も、クロスクラスターロードバランシングは阻止されます。外部トラフィックは、外部ロードバランサーを使用して、一方のクラスターまたはもう一方のクラスターにルーティングできます。
アイデンティティと信頼モデル
ワークロードインスタンスがサービスメッシュ内で作成されると、Istioはワークロードにアイデンティティを割り当てます。
認証局（CA）は、メッシュ内で使用されるアイデンティティを検証するために使用される証明書を作成して署名します。そのアイデンティティの証明書を作成して署名したCAの公開鍵を使用して、メッセージの送信者のアイデンティティを検証できます。信頼バンドルは、Istioメッシュで使用されるすべてのCA公開鍵のセットです。メッシュの信頼バンドルを使用すると、誰でもそのメッシュから送信されるメッセージの送信者を検証できます。
メッシュ内の信頼
単一のIstioメッシュ内では、Istioは各ワークロードインスタンスが、独自のIDを表す適切な証明書と、メッシュ内およびフェデレーションされたメッシュ内のすべてのIDを認識するために必要なトラストバンドルを持つことを保証します。CAはこれらのIDの証明書を作成し、署名します。このモデルにより、メッシュ内のワークロードインスタンスは通信時に相互認証を行うことができます。
メッシュ間の信頼
異なるCAを持つ2つのメッシュ間の通信を有効にするには、メッシュのトラストバンドルを交換する必要があります。Istioは、メッシュ間でトラストバンドルを交換するためのツールを提供していません。トラストバンドルは、手動で交換するか、SPIFFEトラストドメインフェデレーションなどのプロトコルを使用して自動的に交換できます。トラストバンドルをメッシュにインポートすると、それらのIDのローカルポリシーを構成できます。
メッシュモデル
Istioは、すべてのサービスをメッシュ内に配置するか、複数のメッシュを連携させることができます。これはマルチメッシュとも呼ばれます。
シングルメッシュ
最も単純なIstioデプロイメントは、単一のメッシュです。メッシュ内では、サービス名は一意です。たとえば、foo名前空間には、mysvcという名前を持つサービスは1つしか存在できません。さらに、ワークロードインスタンスは、サービスアカウント名がサービス名と同様に名前空間内で一意であるため、共通のIDを共有します。
単一のメッシュは、1つ以上のクラスターと1つ以上のネットワークにまたがることができます。メッシュ内では、名前空間がテナンシーに使用されます。
マルチメッシュ
複数のメッシュのデプロイメントは、メッシュフェデレーションの結果として発生します。
複数のメッシュは、単一のメッシュを超える以下の機能を提供します。
- 組織の境界：事業部門
- サービス名または名前空間の再利用：
default名前空間の複数の異なる使用法 - より強力な分離：テストワークロードを本番ワークロードから分離する
メッシュフェデレーションを使用して、メッシュ間の通信を有効にできます。フェデレーション時、各メッシュは、参加しているすべてのメッシュが認識できる一連のサービスとIDを公開できます。
サービス名の衝突を避けるために、各メッシュにグローバルに一意のメッシュIDを付与して、各サービスの完全修飾ドメイン名（FQDN）が明確になるようにできます。
同じトラストドメインを共有しない2つのメッシュをフェデレーションする場合、それらの間でIDとトラストバンドルをフェデレーションする必要があります。詳細については、メッシュ間の信頼のセクションを参照してください。
テナンシーモデル
Istioでは、テナントとは、デプロイされたワークロードのセットに対して共通のアクセスと特権を共有するユーザーのグループです。テナントを使用して、異なるチーム間の分離レベルを提供できます。
分離に関する次の組織要件を満たすようにテナンシーモデルを構成できます。
- セキュリティ
- ポリシー
- キャパシティ
- コスト
- パフォーマンス
Istioは、3種類のテナンシーモデルをサポートしています。
名前空間テナンシー
クラスターは複数のチーム間で共有でき、各チームは異なる名前空間を使用します。チームに、特定の名前空間または名前空間のセットにのみワークロードをデプロイする権限を付与できます。
デフォルトでは、複数の名前空間のサービスは相互に通信できますが、他の名前空間に公開するサービスを選択的に選択することで分離を強化できます。公開されたサービスに対する承認ポリシーを構成して、適切な呼び出し元のみにアクセスを制限できます。
名前空間テナンシーは、単一のクラスターを超えて拡張できます。複数のクラスターを使用する場合、同じ名前を共有する各クラスターの名前空間は、デフォルトで同じ名前空間と見なされます。たとえば、クラスターWestのTeam-1名前空間のService Bと、クラスターEastのTeam-1名前空間のService Bは同じサービスを指し、Istioはサービス検出とロードバランシングのためにそれらのエンドポイントをマージします。
クラスタテナンシー
Istioは、クラスターをテナンシーの単位として使用することをサポートしています。この場合、各チームに専用のクラスターまたはクラスターのセットを与えて、ワークロードをデプロイできます。クラスターの権限は、通常、それを所有するチームのメンバーに限定されます。たとえば、次のようないくつかの役割を設定して、よりきめ細かい制御を行うことができます。
- クラスター管理者
- 開発者
Istioでクラスタテナンシーを使用するには、各チームのクラスターを独自のコントロールプレーンで構成し、各チームが独自の構成を管理できるようにします。あるいは、Istioを使用して、リモートクラスターまたは複数の同期されたプライマリークラスターを使用して、クラスターのグループを単一のテナントとして実装できます。詳細については、コントロールプレーンモデルを参照してください。
メッシュテナンシー
メッシュフェデレーションを使用するマルチメッシュデプロイメントでは、各メッシュを分離の単位として使用できます。
各メッシュは異なるチームや組織によって運用されるため、サービス名は区別されないことがほとんどです。例えば、Team-1 クラスターの foo 名前空間にある Service C と、Team-2 クラスターの foo 名前空間にある Service C サービスは、同じサービスを指すわけではありません。最も一般的な例は、Kubernetes で多くのチームがワークロードを default 名前空間にデプロイするシナリオです。
各チームが独自のメッシュを持っている場合、クロスメッシュ通信は複数のメッシュモデルで説明されている概念に従います。