このページでは、GKE マルチクラスタ サービス（MCS）の仕組みの概要を示します。MCS の使用方法については、マルチクラスタ サービスの構成をご覧ください。
MCS の概要
Kubernetes の一般的な Service オブジェクトを使用すると、単一の Kubernetes クラスタ内で Service を検出し、アクセスできます。しかし、状態管理、プライバシー、スケーラビリティ、可用性、データ主権の要件に対応するために、アプリケーションを複数のクラスタに分割したい場合もあるかもしれません。MCS を使用すると、複数のクラスタにまたがる Kubernetes アプリケーションをビルドできます。
MCS は、既存の Service オブジェクトを利用する Google Kubernetes Engine（GKE）のクラスタ間サービス ディスカバリおよび呼び出しのメカニズムです。この機能を有効にしたサービスは、仮想 IP を使用してクラスタ全体で検出とアクセスが可能になり、クラスタ内の ClusterIP Service の動作と一致します。既存の Service と同様に、MCS はコミュニティ主導のオープン API と互換性があり、ワークロードの移植性を維持できます。
MCS は GKE の機能です。MCS では、fleet クラスタ内のエクスポートされた Service ごとに Cloud DNS ゾーンとレコードが構成されます。フリートを使用すると、GKE クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になり、MCS をはじめとするマルチクラスタ機能を利用できるようになります。フリートの利点と作成方法について詳しくは、フリート管理のドキュメントをご覧ください。
タイプに関係なく、エクスポートされた Service には必ず 1 つの Cloud DNS レコードがあり、エクスポートされたヘッドレス タイプの Service には、StatefulSet の Pod を含むホスト名を持つ各バックエンド Pod のレコードがあります。Cloud DNS を使用すると、追加料金が発生します。Cloud DNS の料金に従って課金されます。
MCS を使用して Service をエクスポートするには、Service と同じ名前空間と名前を使用して ServiceExport カスタム リソースを作成します。MCS は、フリート内の各クラスタに Service を自動的にインポートします。MCS が Service をインポートすると、次のものが作成されます。
- Service と同じ名前空間と名前を使用する ServiceImport カスタム リソース。
- Service と同じ名前空間とランダムな名前を使用する Endpoints オブジェクト。
MCS を使用するメリット
MCS を使用すると、次のメリットがあります。
- 高可用性: 複数のリージョンのクラスタで同じサービスを実行することで、フォールト トレランスが向上します。クラスタ内の Service が使用不能である場合、リクエストをフェイルオーバーして、他のクラスタから提供できます。MCS を使用すると、クラスタをまたいで Service 間の通信を管理することで、コンテナ化されたアプリケーションの可用性を向上させることができます。
- ステートフル サービスとステートレス サービス: ステートフル サービスとステートレス サービスでは、運用上の依存関係と複雑さが異なり、運用上のトレードオフも同じではありません。通常、状態管理が不要なため、高可用性によってワークロードのスケール、アップグレード、移行が容易になります。MCS を使用すると、クラスタをステートフル ワークロードとステートレス ワークロード用に分けて独立、分離した状態にでき、管理が容易になります。
- 共有サービス: 高可用性の確保、ステートフル サービスとステートレス サービスの高度な管理、データ主権要件の遵守のしやすさのため、Kubernetes クラスタを個別に作成するのが一般的な手法です。ただし、Prometheus によるモニタリングや Vault での Secret 管理の使用など、多くの Service はクラスタ全体で共有することが少なくありません。MCS では、各クラスタが Service の独自のローカル レプリカを必要とせずに、すべての機能クラスタで使用される個別のクラスタに共通の共有 Service を簡単に設定できます。
- 移行: 既存のアプリケーションをマイクロサービスベースのコンテナ化アーキテクチャにモダナイズするには、たいてい複数の Kubernetes クラスタに Service をデプロイする必要があります。MCS は、こうした Service の間の通信をブリッジできるメカニズムを提供することで、アプリケーションの移行を容易にします。特に、同じ Service を 2 つの異なるクラスタにデプロイでき、1 つのクラスタやアプリケーションから他へのトラフィックのシフトが許可されている場合に役立ちます。
次のステップ
- マルチクラスタ Ingress について確認する。これにより、North-South および East-West トラフィックで Service を提供できます。
- Cloud Service Mesh について確認する。これにより、ルーティングとトラフィック パターンのきめ細かな制御が可能になります。