マルチクラスタ Ingress は、Google Kubernetes Engine(GKE)クラスタ用のクラウドホスト型コントローラです。Ingress for Anthos は Google がホストするサービスであり、クラスタ間やリージョン間で共有されたロード バランシングのリソースをデプロイできます。複数のクラスタにマルチクラスタ Ingress をデプロイするには、マルチクラスタ Ingress の設定を完了してから、マルチクラスタに Ingress をデプロイするをご覧ください。
マルチクラスタ Ingress(MCI)、マルチクラスタ Gateway(MCG)、スタンドアロン ネットワーク エンドポイント グループを使用するロードバランサ(LB とスタンドアロン NEG)の詳細な比較については、GKE のマルチクラスタ ロード バランシング API を選択するをご覧ください。
マルチクラスタ ネットワーキング
アプリケーションに対するユーザーの近接性、クラスタとリージョンの高可用性、セキュリティと組織の分離、クラスタの移行、データの局所性など、多数の要因によってマルチクラスタのトポロジが機能します。これらのユースケースが単独で発生することはほとんどありません。複数のクラスタを使用する理由が増えるほど、正式で製品化されたマルチクラスタ プラットフォームの必要性が高まります。
マルチクラスタ Ingress は、マルチクラスタ、マルチリージョン環境の負荷分散に関するニーズを満たすように設計されています。これは、1 つまたは複数のクラスタ間でインターネットからのトラフィックの Ingress を提供する外部 HTTP(S) ロードバランサのコントローラです。
マルチクラスタ Ingress では複数のクラスタがサポートされているため、次のような多数のユースケースに対応できます。
- アプリがグローバルにデプロイされている場所に影響を受けない、アプリ用の単一で一貫した仮想 IP(VIP)。
- ヘルスチェックとトラフィック フェイルオーバーによるマルチ リージョン、マルチクラスタの可用性。
- クライアントの低レイテンシ用のパブリック Anycast VIP を介した近接性ベースのルーティング。
- アップグレードやクラスタの再構築のための透過的なクラスタ移行。
デフォルトの割り当て
マルチクラスタ Ingress には、次のデフォルトの割り当てがあります。
- フリートのメンバー制限の詳細については、フリートでサポートされているメンバー数に関するフリート管理の割り当てをご覧ください。
- プロジェクトあたり 100 個の
MultiClusterIngress
リソースと 100 個のMultiClusterService
リソース。プロジェクトごとのクラスタの最大数に達するまで、任意の数のバックエンド クラスタに対して、構成クラスタで最大 100 個のMultiClusterIngress
リソースと 100 個のMultiClusterService
リソースを作成できます。
料金とトライアル
マルチクラスタ Ingress の料金については、マルチクラスタ Ingress の料金をご覧ください。
マルチクラスタ Ingress の仕組み
マルチクラスタ Ingress は、グローバル外部アプリケーション ロードバランサのアーキテクチャ上に構築されています。グローバル外部アプリケーション ロードバランサは、プロキシを使用してグローバルに分散されたロードバランサであり、世界中にある 100 を超える Google の接続拠点(PoP)でデプロイされています。これらのプロキシは Google Front End(GFE)と呼ばれ、Google のネットワークのエッジにあり、クライアントの近くに配置されています。マルチクラスタ Ingress は、プレミアム ティアで外部アプリケーション ロードバランサを作成します。これらのロードバランサは、エニーキャストを使用してアドバタイズされたグローバル外部 IP アドレスを使用します。リクエストは、GFE と、クライアントに最も近いクラスタによって処理されます。インターネット トラフィックは最も近い Google PoP に向かい、Google バックボーンを使用して GKE クラスタに到達します。この負荷分散構成では、クライアントから GFE へのレイテンシは低くなります。また、クライアントに最も近いリージョンで GKE クラスタを実行することで、GKE クラスタと GFE の処理の間のレイテンシを短くすることもできます。
Google ロードバランサは、HTTP 接続と HTTPS 接続をエッジで終端させることにより、トラフィックがデータセンターやリージョンに入る前に、バックエンドの可用性を判別して、ルーティングする場所を決定します。これにより、トラフィックは、バックエンドの健全性と容量を考慮しながら、クライアントからバックエンドへの最も効率的なパスをたどることができます。
マルチクラスタ Ingress は、ネットワーク エンドポイント グループ(NEG)を使用して外部 HTTP(S) ロードバランサをプログラミングする Ingress コントローラです。デベロッパーが MultiClusterIngress
リソースを作成する際には、GKE によって Compute Engine のロードバランサ リソースがデプロイされ、クラスタ間でバックエンドとして適切な Pod が構成されます。NEG は、Google ロードバランサが正常なバックエンドの適切なセットを使用できるように、Pod のエンドポイントを動的にトラッキングするために使用されます。
GKE でアプリケーションをクラスタ間でデプロイすると、マルチクラスタ Ingress によって、クラスタ内で発生している以下のイベントとロードバランサが同期されているかが確認されます。
- 適切に一致するラベルで Deployment が作成される。
- Pod のプロセスが停止し、ヘルスチェックに失敗する。
- クラスタがバックエンドのプールから削除される。
マルチクラスタ Ingress によってロードバランサが更新され、Kubernetes リソースの環境と目的の状態が維持されます。
マルチクラスタ Ingress のアーキテクチャ
マルチクラスタ Ingress は、集中型 Kubernetes API サーバーを使用して複数のクラスタに Ingress をデプロイします。この一元化された API サーバーは、構成クラスタと呼ばれます。任意の GKE クラスタを構成クラスタとして使用できます。構成クラスタでは、MultiClusterIngress
と MultiClusterService
の 2 つのカスタム リソースタイプが使用されます。これらのリソースを構成クラスタにデプロイすることで、マルチクラスタ Ingress コントローラによって、複数のクラスタ全体にロードバランサがデプロイされます。
マルチクラスタ Ingress は、次のコンセプトとコンポーネントから構成されます。
マルチクラスタ Ingress コントローラ - グローバルに分散されたコントロール プレーンであり、クラスタの外部でサービスとして実行されます。これにより、コントローラのライフサイクルとオペレーションを GKE クラスタから分離できます。
構成クラスタ -
MultiClusterIngress
リソースとMultiClusterService
リソースがデプロイされている Google Cloud で実行される選択された GKE クラスタです。これは、マルチクラスタ リソースを一元的に管理する場所になります。マルチクラスタ リソースが単一の論理 API 内に存在し、そこからアクセスできるようになるため、すべてのクラスタにわたる整合性の維持が実現されます。Ingress コントローラによって、構成クラスタがモニタリングされ、ロード バランシング インフラストラクチャが調整されます。フリートを使用すると、GKE クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になり、マルチクラスタ Ingress をはじめとするマルチクラスタ機能を利用できるようになります。フリートの利点と作成方法について詳しくは、フリート管理のドキュメントをご覧ください。1 つのクラスタがメンバーになれるフリートは 1 つだけです。
メンバー クラスタ - フリートに登録されたクラスタは、メンバー クラスタと呼ばれます。フリートのメンバー クラスタは、マルチクラスタ Ingress が認識しているすべてのバックエンドで構成されます。Google Kubernetes Engine クラスタ管理ビューは、登録されているすべてのクラスタの状態を表示するセキュアなコンソールを提供します。
デプロイのワークフロー
以下の手順は、複数のクラスタ間のマルチクラスタ Ingress を使用するための大まかなワークフローを示しています。
選択したプロジェクトのフリートに GKE クラスタを登録します。
GKE クラスタを中央構成クラスタとして構成します。このクラスタは、専用のコントロール プレーンにすることも、他のワークロードを実行することもできます。
アプリケーションを実行する GKE クラスタにアプリケーションをデプロイします。
1 つ以上の
MultiClusterService
リソースをラベルとクラスタが一致する構成クラスタにデプロイして、指定した Service のバックエンドと見なされるクラスタ、名前空間、Pod を選択します。これにより、Compute Engine で NEG が作成され、サービス エンドポイントの登録と管理が開始されます。ロードバランサのバックエンドとして 1 つ以上の
MultiClusterService
リソースを参照する構成クラスタにMultiClusterIngress
リソースをデプロイします。これにより、Compute Engine の外部ロードバランサ リソースがデプロイされ、単一のロードバランサ VIP を介して、エンドポイントがクラスタ間で公開されます。
Ingress のコンセプト
マルチクラスタ Ingress は、集中型 Kubernetes API サーバーを使用して複数のクラスタに Ingress をデプロイします。以下のセクションでは、マルチクラスタ Ingress リソースモデル、Ingress のデプロイ方法、高可用性のネットワーク コントロール プレーンの管理の重要なコンセプトについて説明します。
MultiClusterService リソース
MultiClusterService
は、マルチクラスタ Ingress で使用されるカスタム リソースで、クラスタ間でのサービスの共有を表します。MultiClusterService
リソースによって、Service リソースと同様に Pod が選択されますが、MultiClusterService
はラベルとクラスタも選択できます。MultiClusterService
によって選択されるクラスタのプールは、メンバー クラスタと呼ばれます。フリートに登録されているクラスタはすべてメンバー クラスタです。
MultiClusterService
は構成クラスタ内にのみ存在し、ClusterIP、LoadBalancer、NodePort Service のようにはルーティングしません。代わりに、マルチクラスタ Ingress コントローラが 1 つの分散リソースを参照できるようにします。
次のサンプル マニフェストでは、foo
という名前のアプリケーションの MultiClusterService
を記述しています。
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: foo
namespace: blue
spec:
template:
spec:
selector:
app: foo
ports:
- name: web
protocol: TCP
port: 80
targetPort: 80
このマニフェストは、セレクタ app:
foo
を使用して、すべてのメンバー クラスタに Service をデプロイします。そのクラスタに app: foo
Pod が存在する場合、それらの Pod IP アドレスは MultiClusterIngress
のバックエンドとして追加されます。
次の mci-zone1-svc-j726y6p1lilewtu7
は、ターゲット クラスタのいずれかで生成された派生 Service です。この Service は、このクラスタ内の指定されたラベルセレクタに一致するすべての Pod の Pod エンドポイントをトラッキングする NEG を作成します。派生 Service と NEG は、すべての MultiClusterService
のすべてのターゲット クラスタに存在するようになります(クラスタ セレクタを使用する場合を除く)。ターゲット クラスタに一致する Pod が存在しない場合、Service と NEG は空になります。派生 Service は MultiClusterService
によって完全に管理されます。ユーザーが直接管理することはありません。
apiVersion: v1
kind: Service
metadata:
annotations:
cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
name: mci-zone1-svc-j726y6p1lilewtu7
namespace: blue
spec:
selector:
app: foo
ports:
- name: web
protocol: TCP
port: 80
targetPort: 80
派生 Service に関する注意事項は次のとおりです。
- マルチクラスタ Ingress のバックエンドとしてのエンドポイントの論理グループとして機能します。
- 特定のクラスタとアプリケーションに対する NEG のライフサイクルを管理します。
- ヘッドレス Service として作成されます。
Selector
フィールドとPorts
フィールドだけが、MultiClusterService
から派生 Service に引き継がれます。 - Ingress コントローラによってライフサイクルが管理されます。
MultiClusterIngress リソース
MultiClusterIngress
リソースは、多くの点でコア Ingress リソースと同様に動作します。いずれにも、ホスト、パス、プロトコルの終端、バックエンドの定義に同じ仕様が使用されます。
次のマニフェストでは、HTTP ホストヘッダーに応じてトラフィックを foo
バックエンドと bar
バックエンドに転送する MultiClusterIngress
を記述しています。
apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
name: foobar-ingress
namespace: blue
spec:
template:
spec:
backend:
serviceName: default-backend
servicePort: 80
rules:
- host: foo.example.com
backend:
serviceName: foo
servicePort: 80
- host: bar.example.com
backend:
serviceName: bar
servicePort: 80
この MultiClusterIngress
リソースは、foo
と bar
という MultiClusterService
リソースにトラフィックを送信することで、foo.example.com
と bar.example.com
の仮想 IP アドレスへのトラフィックを一致させています。この MultiClusterIngress
には、その他のすべてのトラフィックを一致させるデフォルトのバックエンドがあります。トラフィックはデフォルトのバックエンド MultiClusterService
に送信されます。
次の図では、Ingress からクラスタにトラフィックがどのように流れるかを示します。
この図には、gke-us
と gke-eu
の 2 つのクラスタがあります。両方のクラスタ間で、foo.example.com
から app:foo
というラベルの Pod にトラフィックが送信されます。両方のクラスタ間で、bar.example.com
から app:bar
というラベルの Pod にトラフィックが送信されます。
クラスタ全体の Ingress リソース
構成クラスタは、MultiClusterIngress
リソースと MultiClusterService
リソースを持つことができる唯一のクラスタです。MultiClusterService
ラベルセレクタに一致する Pod がある各ターゲット クラスタにも、対応する派生 Service がスケジュールされます。MultiClusterService
でクラスタが明示的に選択されていない場合は、対応する派生 Service はそのクラスタには作成されません。
Namespace の同一性
Namespace の同一性は、Kubernetes クラスタのプロパティであり、Namespace はクラスタをまたがって拡張され、同じ Namespace と見なされます。
次の図では、Namespace の blue
は GKE クラスタ gke-cfg
、gke-eu
、gke-us
にまたがっています。Namespace の同一性により、Namespace の blue
がすべてのクラスタで同一であるとみなされます。つまり、あるユーザーはすべてのクラスタの blue
Namespace のリソースに対して同じ権限を持つことになります。また、Namespace の同一性は、Namespace blue
の複数のクラスタで同じ名前の Service リソースが同じサービスとみなされることも意味します。
Gateway は、Service を 3 つのクラスタにまたがるエンドポイントの単一のプールとして扱います。ルートと MultiClusterIngress
リソースは、同じ Namespace 内の Service にのみルーティングできるため、フリート内のすべてのクラスタ間で構成に整合性のあるマルチテナンシーを実現できます。フリートを使用すると、構成を変更することなくリソースをクラスタ間でデプロイまたは移動できるため、高度なポータビリティを実現できます。同じフリートの Namespace にデプロイすると、クラスタ間で一貫性を維持できます。
Namespace の同一性には、次の設計原則を考慮してください。
- クラスタ間で異なる目的の Namespace に同じ名前を付けない。
- Namespace の予約は、Namespace の割り当てによって明示的に行うか、フリート内のチームやクラスタに対して帯域外ポリシーを介して暗黙的に行う。
- クラスタ間で同じ目的の Namespace は必ず同じ名前にする。
- クラスタ全体の Namespace に対するユーザー権限は、不正アクセスを防ぐために厳しく管理する。
- 通常のアプリケーションのデプロイには、デフォルトの Namespace や、「prod」や「dev」などの汎用的な Namespace を使用しない。ユーザーが誤ってデフォルトの Namespace にリソースをデプロイし、Namespace のセグメンテーションの指針に違反してしまうことがありますが、このような違反は容易に発生します。
- 特定のチームまたはユーザー グループがリソースをデプロイする必要がある場合は、クラスタ間で同じ Namespace を作成する必要があります。
構成クラスタの設計
マルチクラスタ Ingress 構成クラスタは、MultiClusterIngress
と MultiClusterService
のリソースをホストする単一の GKE クラスタで、ターゲット GKE クラスタ全体で Ingress の単一のコントロール ポイントとして機能します。マルチクラスタ Ingress を有効にする場合は、構成クラスタを選択します。任意の GKE クラスタを構成クラスタとして選択できます。また、構成クラスタはいつでも変更が可能です。
構成クラスタの可用性
構成クラスタは一元的に管理する場所であるため、構成クラスタ API を使用できない場合、マルチクラスタ Ingress リソースの作成または更新ができなくなります。ロードバランサとロードバランサによって処理されるトラフィックに対しては、構成クラスタの停止による影響はありません。しかし、MultiClusterIngress
リソースと MultiClusterService
リソースの変更に対しては、構成クラスタが再び使用可能になるまで、コントローラによる調整は行われません。
構成クラスタには、次の設計原則を考慮してください。
- 構成クラスタは、可用性が高くなるように選択する必要があります。リージョン クラスタは、ゾーンクラスタよりも優先されます。
- マルチクラスタ Ingress を有効にする場合、構成クラスタが専用のクラスタである必要はありません。構成クラスタは、管理ワークロードやアプリケーション ワークロードをホストできますが、ホストされたアプリケーションが構成クラスタの API サーバーの可用性に影響を与えないようにする必要があります。構成クラスタは、
MultiClusterService
リソースのバックエンドをホストするターゲット クラスタにできますが、追加の予防措置が必要な場合は、クラスタ選択でバックエンドとして除外することもできます。 - 構成クラスタには、ターゲット クラスタのバックエンドで使用されるすべての Namespace が必要です。
MultiClusterService
リソースはクラスタ間で同じ Namespace 内の Pod のみを参照できるため、Namespace が構成クラスタ内に存在する必要があります。 - ユーザーが複数のクラスタに Ingress をデプロイする場合、
MultiClusterIngress
リソースとMultiClusterService
リソースをデプロイするために、構成クラスタへのアクセスが可能である必要があります。ただし、ユーザーがアクセスできるのは、使用権限のある Namespace のみです。
構成クラスタの選択と移行
マルチクラスタ Ingress を有効にする場合は、構成クラスタを選択する必要があります。フリートの任意のメンバー クラスタを構成クラスタとして選択できます。構成クラスタはいつでも更新できますが、中断を発生させないように注意してください。Ingress コントローラは、構成クラスタ内に存在するすべてのリソースを調整します。現在のクラスタから次のクラスタに移行する場合、MultiClusterIngress
と MultiClusterService
のリソースは同じにする必要があります。リソースが同一でない場合は、構成クラスタの更新後に Compute Engine ロードバランサが更新または破棄される可能性があります。
次の図は、一元化された CI / CD システムにより、MultiClusterIngress
リソースと MultiClusterService
リソースが構成クラスタ(gke-us
)とバックアップ クラスタ(gke-eu
)の GKE API サーバーに常に適用されます。これにより、2 つのクラスタ間でリソースは同じになります。MultiClusterIngress
リソースと MultiClusterService
リソースが同一であるため、緊急のダウンタイムや計画的なダウンタイムの際に、いつでも構成クラスタを変更できます。
クラスタの選択
MultiClusterService
リソースはクラスタ間で選択できます。デフォルトで、コントローラはターゲット クラスタごとに派生 Service をスケジュールします。派生 Service がすべてのターゲット クラスタで必要ない場合は、MultiClusterService
マニフェストの spec.clusters
フィールドを使用して、クラスタのリストを定義できます。
次の操作が必要な場合は、クラスタのリストを定義することをおすすめします。
- 構成クラスタを分離して、
MultiClusterService
リソースが構成クラスタ全体で選択されないようにする。 - アプリケーション移行のために、クラスタ全体のトラフィックを制御する。
- クラスタのサブセットにのみ存在するアプリケーション バックエンドにルーティングする。
- 異なるクラスタに存在するバックエンドへのルーティングに単一の HTTP(S) 仮想 IP アドレスを使用する。
名前の競合を防ぐため、同じフリートで同じリージョン内のメンバー クラスタには、一意の名前を付ける必要があります。
クラスタの選択を構成する方法については、マルチクラスタ Ingress の設定をご覧ください。
次のマニフェストでは、europe-west1-c/gke-eu
と asia-northeast1-a/gke-asia
を参照する clusters
フィールドを持つ MultiClusterService
を記述しています。
apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
name: foo
namespace: blue
spec:
template:
spec:
selector:
app: foo
ports:
- name: web
protocol: TCP
port: 80
targetPort: 80
clusters:
- link: "europe-west1-c/gke-eu"
- link: "asia-northeast1-a/gke-asia-1"
このマニフェストは、gke-asia
クラスタと gke-eu
クラスタに一致するラベルを持つ Pod を MultiClusterIngress
のバックエンドとして含めることができることを指定しています。他のクラスタは、app: foo
ラベルの Pod がある場合でも除外されます。
次の図は、前述のマニフェストを使用した MultiClusterService
構成の例を示しています。
この図には、gke-eu
、gke-asia-1
、gke-asia-2
の 3 つのクラスタがあります。gke-asia-2
クラスタは、一致するラベルを持つ Pod があっても、マニフェストの spec.clusters
リストに含まれていないため、バックエンドとして含まれません。クラスタは、メンテナンスやその他のオペレーションのトラフィックを受信しません。
次のステップ
- マルチクラスタ Ingress を設定する方法を確認する。
- マルチクラスタ Gateway のデプロイについて確認する。
- マルチクラスタ Ingress のデプロイについて確認する。
- 外部ロード バランシング用のマルチクラスタ Ingress を実装する。