Configuring multi-cluster Services
1. Configuring multi-cluster Services
While a multicluster service shares similarities with regular Kubernetes services, it operates differently. Instead of directly routing traffic, an MCS acts as a central definition for a service that spans multiple clusters. This allows the multicluster gateway to manage traffic across these clusters using a single unified resource. An MCS selects pods using labels and clusters. When selecting a cluster, MCS chooses from clusters registered to the fleet called member clusters. After MCS has selected a target cluster, it generates a derived service. Then the derived service creates an NEG, unless cluster selectors are implemented. The NEG tracks POD endpoints for all pods that match the specified label selector in the cluster. If there are no matching pods in the target cluster, the service in NEG will be empty. In this example, the MCS deploys a derived service in all member clusters with the selector app foo. If app foo pods exist in that cluster, then those POD IPs will be added as backends for the multicluster gateway. Note that the MCS is acting as the blueprint for the matching clusters to create a derived service from. To enable MCS, the first step is to enable the required APIs-- MCS, Fleet Hub, Resource Manager, Cloud Service Mesh and Cloud DNS. Next, use the gcloud container fleet. Multi-cluster-services enable command to enable the MCS feature for your project's fleet. Then use the gcloud container fleet memberships register command to register your GKE clusters to the fleet. It's recommended that you use Workload Identity Federation for GKE. Use the gcloud projects add IAM policy binding command to grant the required Identity and Access Management, IAM, permissions for MCS importer. Finally, ensure that each cluster in the fleet has a namespace to share services in. Let's explore derived services. Derived services are logical groupings of endpoints, and they're fully managed by MCS. They're used to manage the NEG lifecycle and can serve as backends for multicluster gateways, a cross-cluster Ingress resource. Derived services are created as headless services. The MCS controller manages their lifecycle using only the selector and ports fields from the original MCS definition. While MCS typically schedules derived services on all target clusters, you can explicitly select specific clusters for deployment. This allows you to control where your service instances run. There are many use cases where you may want to apply Ingress rules to specific clusters, isolating the config cluster to prevent MCSs from selecting across them, controlling traffic between clusters in a blue-green fashion for app migration, routing to application backends that only exist in a subset of clusters, using a single L7 VIP for host-path routing to backends that live on different clusters. To select clusters for your MCS, use the Clusters field, specifying each cluster as region/zone/name. Ensure unique cluster names within the same region and fleet to avoid conflicts. In this example, the MCS foo has a clusters field that references europe-west1-c/gke-eu and asia-northeast1-a/gke-asia. Pods with matching labels in the GKE Asia and GKE EU clusters can be included as backends for a given multicluster gateway. This will exclude the GKE US cluster from Ingress, even if it has pods with the app foo label. This configuration is useful for onboarding or migrating to new clusters and controlling traffic independently of pod deployment.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.