GKEを単一クラスタで使うだけなら、まずはクラスタ、Node、Pod、Service、Ingressの関係を押さえれば全体像を追えます。一方で、複数のGKEクラスタを使う構成になると、クラスタ群をどうまとめるか、クラスタ間でServiceをどう見つけるか、通信制御をどうそろえるかといった論点が増えます。その文脈で、Fleet、マルチクラスタGKE、MCS（Multi-cluster Services）、Cloud Service Meshのような言葉が出てきます。
この記事では、『GKE概要まとめ』と『KubernetesのService・Ingressの関係とPodへの通信経路』を前提に、複数GKEクラスタ構成で出てくるFleet、マルチクラスタGKE、MCSの関係を整理します。
- FleetがMCSなどの対象範囲を決める理由
- マルチクラスタGKEとGKE regional clusterの違い
- MCSが通常のKubernetes Serviceをどう拡張するのか
- MCSとCloud Service Meshの役割の違い
複数クラスタ構成におけるFleet・マルチクラスタGKE・MCSの立ち位置
最初に、3つの言葉を同じ種類の機能として並べないことが大切です。Fleetは管理単位、マルチクラスタGKEは構成、MCSは同じFleetに登録されたクラスタ群で使うGKE機能です。
| 用語 | 何を指すか | 答える問い |
|---|---|---|
| Fleet | GKEクラスタをGoogle Cloud上でまとめる管理単位 | どのクラスタ群を同じ管理対象として扱うか |
| マルチクラスタGKE | 複数のGKEクラスタでワークロードを運用する構成 | なぜクラスタを複数に分けるか |
| MCS | 同じFleetに登録されたクラスタ間でKubernetes Serviceを使えるようにするGKE機能 | 他クラスタのServiceをどう見つけるか |
関係を図にすると次のようになります。全体像では、マルチクラスタGKE、Fleet、MCSを同じ箱として並べず、構成、管理単位、機能として分けて見ます。
flowchart TB
subgraph Multi["マルチクラスタGKE（複数のGKEクラスタで運用する構成）"]
subgraph Fleet["Fleet（クラスタ群をまとめる管理単位）"]
ClusterA["GKEクラスタ A"]
ClusterB["GKEクラスタ B"]
end
end
MCS["MCS（GKE機能）"]
MCS -. "同じFleetのクラスタ間で使う" .-> Fleet
図では、複数のGKEクラスタで運用する構成をマルチクラスタGKE、そのクラスタ群をまとめる管理単位をFleetとして分けています。MCSはFleetそのものではなく、同じFleetに登録されたクラスタ間でKubernetes Serviceを見つけられるようにするGKE機能です。
FleetはGKEクラスタをまとめる管理単位
Fleetは、Google Cloud上でGKEクラスタなどのKubernetesクラスタを論理的にまとめる管理単位です。複数クラスタ専用の機能ではなく、単一のGKEクラスタでもFleetに属することがあります。
ただし、Fleetの意味が大きくなるのは複数クラスタを扱うときです。クラスタを個別に管理すると、namespace、Service、認証、通信制御、ポリシーの扱いがクラスタごとに分かれます。Fleetは、これらのクラスタをGoogle Cloud上で同じ管理対象として扱うための土台になります。
複数クラスタの設定同期やポリシー管理まで含めた運用統制は『GKEのConfig Sync・Policy Controller・Config Connectorの使い分けまとめ』で扱っています。
一方で、クラスタを同じFleetに入れるだけで、他クラスタのServiceを自動的に呼び出せるようになるわけではありません。Fleetは対象範囲をそろえる土台であり、その範囲内でServiceを見つけられるようにするにはMCSのような機能を使います。
flowchart TB
subgraph Single["単一クラスタでもFleetは使われる"]
subgraph FleetA["Fleet"]
One["GKEクラスタ"]
end
end
subgraph Multi["複数クラスタでFleetの意味が大きくなる"]
subgraph FleetB["Fleet"]
A["GKEクラスタ A"]
B["GKEクラスタ B"]
end
end
Fleetを理解するときに重要なのがsamenessです。samenessは、同じ名前のnamespace、Service、identityを、Fleetを対象範囲にする機能の中で同じものとして扱う考え方です。
たとえば、複数クラスタに同じnamespace名とService名がある場合、それらを同じServiceとして扱う機能があります。MCSやCloud Service Meshは、この考え方と相性がよい一方で、名前の衝突や管理責任の混在には注意が必要です。
flowchart TB
subgraph Fleet["Fleet"]
subgraph ClusterA["GKEクラスタ A"]
NamespaceA["namespace: app"]
ServiceA["Service: backend"]
NamespaceA --> ServiceA
end
subgraph ClusterB["GKEクラスタ B"]
NamespaceB["namespace: app"]
ServiceB["Service: backend"]
NamespaceB --> ServiceB
end
end
ServiceA -. "同じnamespace名とService名" .- ServiceB
この図では、クラスタAとクラスタBに同じ namespace: app と Service: backend があります。backend は例としてのService名です。MCSやCloud Service Meshのような機能では、このような名前のそろい方を前提に、クラスタをまたいだServiceの発見や通信制御を扱います。
つまりFleetは、「クラスタを増やすための機能」ではなく、複数クラスタを同じ管理文脈に置くための単位です。
マルチクラスタGKEは複数のGKEクラスタで運用する構成
マルチクラスタGKEは、複数のGKEクラスタを使ってワークロードを運用する構成です。GKEとは別のサービス名というより、GKEを複数クラスタで使う設計パターンとして捉えると分かりやすくなります。
ここで大事なのは、クラスタが複数あるかどうかです。regionやzoneの数だけで判断するのではなく、GKEクラスタそのものが複数あるかを見ます。
まず、GKEクラスタ構成をクラスタ数で分けると次のようになります。
| 分類 | クラスタ数 | 具体例 | 主な目的 |
|---|---|---|---|
| 単一クラスタ | 1つ | GKE regional cluster | 1つのregion内のzone障害に備える |
| マルチクラスタGKE | 複数 | 複数region GKE | region障害に備える |
マルチクラスタGKEの代表例は、regionごとにGKEクラスタを作る複数region GKEです。たとえば、東京regionと大阪regionにそれぞれGKEクラスタを置く構成は、クラスタが複数あるためマルチクラスタGKEです。
一方で、GKE regional clusterは名前にregionalと付くため複数regionの構成に見えやすいですが、実際には1つのGKEクラスタを1つのregion内の複数zoneに分散する構成です。クラスタ数は1つなので、マルチクラスタGKEではありません。
Compute側の可用性設計は『Compute可用性設計: GCPのRegional MIG・GKE regional cluster・複数region backendで考える』で扱っています。
マルチクラスタGKEにする理由は、上記の可用性も含めて複数あります。
- region障害に備えたい（可用性）
- 本番、検証、開発の環境を分けたい（環境分離）
- チームや事業領域ごとに運用責任を分けたい（運用分離）
- セキュリティ境界や変更影響の範囲を分けたい（セキュリティ）
- 既存クラスタから新しいクラスタへ段階的に移行したい（移行）
クラスタを複数にすると、アプリをどこに配置するかだけでなく、クラスタ間でServiceをどう見つけるか、クラスタ間通信をどう制御するか、複数クラスタをどう同じ管理単位で扱うかが問題になります。そこでFleet、MCS、Cloud Service Meshのような機能が関係します。
MCSはServiceをクラスタ間で発見する仕組み
MCSは、同じFleetに登録された複数GKEクラスタ間でKubernetes Serviceを発見し、呼び出せるようにするGKEの機能です。
MCSを使うには、対象のGKEクラスタが同じFleetに登録されている必要があります。FleetはMCSの対象範囲を決める単位です。ただし、FleetだけでServiceのクラスタ間呼び出しができるわけではありません。MCSが、そのFleet内のクラスタ間でServiceExportやServiceImportを構成します。
MCSの目的は、クラスタを分けたまま、他クラスタのKubernetes Serviceを安定した名前で呼び出せるようにすることです。たとえば、クラスタBのfrontend Podから、クラスタAのbackend Serviceを呼び出したい場面を考えます。
通常のKubernetes Serviceは、同じクラスタ内のPod群への安定した宛先です。これは、同じクラスタ内でfrontend Podがbackend Serviceを呼び出すようなアプリ間通信でも使われます。呼び出し元のPodは、相手PodのIPを直接知らなくてもService名でアクセスできます。ただし、通常のServiceの範囲は基本的に同じクラスタ内です。そのため、クラスタBのfrontend Podから見ると、クラスタAのbackend Serviceはそのままでは見つけられません。
MCSは、この「通常のServiceは同じクラスタ内で閉じる」という範囲を、同じFleetに登録されたクラスタ間へ広げます。
通常のServiceとMCSの関係は次の通りです。ServiceはKubernetesリソースそのものですが、MCSはServiceを複数クラスタから使えるようにするGKE機能です。
| 仕組み | 何を表すか | 何をするか |
|---|---|---|
| Kubernetes Service | Pod群への安定した宛先を作るKubernetesリソース | 同じクラスタ内のPod群へ振り分ける |
| MCS | Serviceを複数クラスタから使えるようにするGKE機能 | ServiceExportやServiceImportを構成し、他クラスタからServiceを見つけられるようにする |
MCSの正式名称であるMulti-cluster ServicesのServicesは、単一クラスタの説明で出てきたKubernetes Serviceを土台にしています。ただし、MCSはServiceそのものではありません。Serviceをクラスタ間で見つけられるようにする制御面の機能です。
この目的を実現するために、MCSではServiceExportとServiceImportを使います。
- ServiceExport
- 他クラスタから呼び出せるようにしたいServiceと同じnamespace・名前で作るリソース
- ServiceImport
- MCSによって他クラスタ側に作られる、importされたServiceを表すリソース
たとえば、クラスタAのbackend ServiceをクラスタBから呼び出せるようにする場合は次のようになります。これは役割の例であり、クラスタAだけが特別な種類のクラスタという意味ではありません。
flowchart TB
subgraph Fleet["同じFleet"]
subgraph ClusterA["GKEクラスタ A"]
Service["backend Service"]
Export["ServiceExport"]
Export -.-> Service
end
subgraph ClusterB["GKEクラスタ B"]
Import["ServiceImport"]
Dns["backend.app.svc.clusterset.local"]
end
MCS["MCS"]
Export -.-> MCS
MCS -.-> Import
MCS -.-> Dns
end
この図では、クラスタAでbackend Serviceに対応するServiceExportを作っています。MCSはそれをもとに、クラスタB側にServiceImportとDNS名を用意します。これにより、クラスタBのfrontend Podは、クラスタA側のbackend Serviceを安定した名前で見つけられるようになります。
ここで扱っているのは、外部ユーザーからのIngressアクセスではなく、クラスタB内のfrontend PodがクラスタA側のbackend Serviceを呼び出す通信です。アクセスの向きは次のようになります。
flowchart TB
subgraph ClusterB["GKEクラスタ B"]
Client["frontend Pod"]
Dns["backend.app.svc.clusterset.local"]
end
subgraph ClusterA["GKEクラスタ A"]
Pods["backend Pod群"]
end
Client --> Dns
Dns --> Pods
MCS自体やServiceImportにリクエストがまず届くわけではありません。ServiceImportは、importされたServiceを表すリソースです。MCSは制御面の機能として、exportされたServiceごとにCloud DNSのゾーンやレコードを構成します。また、クラスタ間でPodが通信できるようにFirewall rulesを構成し、エンドポイントとヘルス状態の管理にTraffic Director control planeを使います。
MCSにはいくつか前提があります。たとえば、ServiceをexportできるのはGoogle Cloud上のVPC-native GKEクラスタです。VPC-native GKEクラスタとは、PodやServiceのIPアドレスをVPCネットワークと統合して扱うGKEのネットワーク方式です。また、クラスタ間の接続は同じVPCネットワーク、VPC Network Peering、Shared VPCなど、通信できるネットワーク構成に依存します。
MCSの中心は、他クラスタのKubernetes Serviceをどう見つけるかです。MCSは、アプリケーション間通信の暗号化、リトライ、タイムアウト、トラフィック分割まで一括で解決する仕組みではありません。
MCSとCloud Service Meshは役割が違う
MCSとCloud Service Meshは、どちらも複数クラスタ構成で出てくるため混ざりやすいですが、扱う問題が違います。
| 仕組み | 主な役割 | 扱う問題 |
|---|---|---|
| MCS | Serviceをクラスタ間で発見・呼び出し可能にする | 他クラスタのServiceをどう見つけるか |
| Cloud Service Mesh | アプリケーション間通信を制御する | 暗号化、リトライ、タイムアウト、トラフィック分割、可観測性をどうそろえるか |
MCSは、Kubernetes Serviceの考え方をクラスタ間に広げる機能です。Cloud Service Meshは、Serviceへ届くかどうかだけでなく、アプリケーション間通信そのものを制御する層です。
複数クラスタをCloud Service Meshの対象にする構成は、Cloud Service Meshのドキュメントではmulti-cluster meshと呼ばれます。この話は『Service Meshで解決するマイクロサービス間通信の課題』で扱っています。
まとめ
- Fleetは、GKEクラスタをGoogle Cloud上でまとめる管理単位
- Fleetは複数クラスタ専用ではないが、MCSやCloud Service Meshなどの対象範囲を決める土台になる
- マルチクラスタGKEは、複数のGKEクラスタでワークロードを運用する構成
- GKE regional clusterは1つのクラスタなので、マルチクラスタGKEではない
- 複数region GKEは、マルチクラスタGKEの代表例
- MCSは、同じFleetに登録された複数GKEクラスタ間でServiceを発見・呼び出し可能にする仕組み
- MCSはKubernetes Serviceをクラスタ間で見つける話で、Cloud Service Meshはアプリケーション間通信の制御の話