Container Service for Kubernetes (ACK) のマルチクラスターサービスアクセス - ACK

マルチクラスターサービス (MCS) を使用すると、ロードバランサーを作成することなく、ある Kubernetes クラスター内の Pod が別のクラスターで実行中のサービスにアクセスできます。以下の要件がある場合に MCS をご利用ください。

クラスター間でワークロードを分離しつつ、内部サービスを共有する
高可用性とクラスター間の負荷分散のために、複数のクラスターにわたってサービスをデプロイする
パブリックエンドポイントを介さずに、個別の VPC 間でクラスターを接続する

基本概念

用語	説明	作成者
ServiceExport	プロバイダークラスターで作成するカスタムリソースで、他のクラスターに対してサービスを公開します。	ユーザー
ServiceImport	コンシューマークラスター内でマルチクラスターサービスを表すカスタムリソースです。	ユーザー
Clusterset	MCS を通じてサービスを共有するクラスターのグループです。各クラスターはサービスプロバイダー、サービス利用者、またはその両方として機能できます。	—
サービスプロバイダー	ServiceExport を介してサービスをエクスポートするクラスターです。	—
サービス利用者	ServiceImport を介してエクスポートされたサービスをインポートし、アクセスするクラスターです。	—

アーキテクチャ

MCS 機能は、関連付けられた Container Service for Kubernetes (ACK) クラスター間で ServiceExport および ServiceImport オブジェクトを調整するために、ACK One Fleet インスタンスを利用します。

図には次の 2 つの接続が示されています。

接続 1 — ACK One Fleet インスタンスが、関連付けられた ACK クラスター内の ServiceExport および ServiceImport を管理します。プロバイダークラスター (ACK クラスター 1) に ServiceExport を作成し、コンシューマークラスター (ACK クラスター 2) に ServiceImport を作成します。
接続 2 — データはクラスター間を直接フローします。ACK クラスター 1 から Service 1 がエクスポートされ、ACK クラスター 2 にインポートされた後、ACK クラスター 2 内の Pod は Service 1 に到達できます。

仕組み

次の図は、クラスター間のトラフィックフローを示しています。

ACK クラスター 1 (プロバイダー) に ServiceExport を作成し、ACK クラスター 2 (コンシューマー) に ServiceImport を作成します。
ACK One Fleet は、ACK クラスター 2 に amc-<service-name> という名前のサービスを作成し、ACK クラスター 1 の Pod IP アドレスをそのバックエンドに同期します。
ACK クラスター 2 内の Pod は、次のいずれかのドメイン名形式を使用して Service 1 にアクセスできます。

形式例

amc-<service-name>.<provider-namespace> amc-Service1.provider-ns

<service-name>.<provider-namespace>.svc.clusterset.local Service1.provider-ns.svc.clusterset.local

形式	例
`amc-<service-name>.<provider-namespace>`	`amc-Service1.provider-ns`
`<service-name>.<provider-namespace>.svc.clusterset.local`	`Service1.provider-ns.svc.clusterset.local`

ユースケース

別のクラスターからサービスにアクセスする

ACK クラスター 1 にサービスをデプロイし、ServiceExport を作成します。ACK クラスター 2 に ServiceImport を作成すると、ACK クラスター 2 内の Pod は DNS 経由でそのサービスにアクセスできます。トラフィックは ACK クラスター 1 内のバックエンド Pod 全体に負荷分散され、Pod 数は動的にスケーリングされます。

複数クラスターにデプロイされたサービスにアクセスする

高可用性のために、同一のサービスを複数のクラスターにわたってデプロイします。Pod がサービスにアクセスすると、参加しているすべてのクラスター内の Pod 全体にトラフィックが分散されます。

ネットワーク要件

MCS を機能させるには、Pod 間のトラフィックがクラスター間を直接フローする必要があります。MCS を有効化する前に、次の 3 つのネットワーク要件が満たされていることを確認してください。

要件	重要性
複数の仮想プライベートクラウド (VPC) を使用する場合、VPC の CIDR ブロックが重複してはならず、すべての VPC が Cloud Enterprise Network (CEN) を介して接続されている必要があります。	CIDR ブロックが重複するとルーティング競合が発生します。CEN は VPC 間のネットワークパスを提供します。
クラスター間で Pod の CIDR ブロックが重複してはなりません。ノードプールのセキュリティグループは、Pod の CIDR ブロック間のトラフィックを相互に許可する必要があります。	Pod 間の直接ルーティングには、一意のアドレスとオープンなセキュリティグループルールが必要です。
どのクラスターにおいても、Pod の CIDR ブロックがサービスの CIDR ブロックと重複してはなりません。	Pod とサービスの CIDR ブロックが重複すると、クラスター間での DNS ベースのサービス検出が機能しなくなります。

クラスターレベルのネットワーク計画については、「ACK クラスターのネットワーク計画」をご参照ください。

制限事項

関連付けられたすべてのクラスターの Kubernetes バージョンは、1.22 以降である必要があります。