MultiClusterIngress is a Kubernetes custom resource for exposing an application across multiple Anthos GKE clusters. It works with a Google-hosted controller that programs an external HTTP(S) load balancer. A single public address can serve clusters in different regions, allowing traffic to reach an available deployment without changing the application’s IP address or domain name. section 7.2.1 section 10.2.1
The deployment separates configuration from traffic routing:
- Designate one fleet member as the config cluster. Store the MultiClusterIngress and MultiClusterService objects there for the Google-managed controller to read. section 7.2.1
- Use MultiClusterService to identify the service and participating clusters; use MultiClusterIngress to define the external routing rules and their service backends. section 10.2.1
- The controller programs Google’s external HTTP(S) load balancer using network endpoint groups (NEGs). Routing accounts for service or Pod availability across fleet members. section 7.2.1 section 10.2.1
Expose a service in two regions
A MultiClusterService example selects an app on clusters in europe-west1-c and asia-northeast1-a. In the same namespace, a MultiClusterIngress rule maps foo.example.com to that service on port 80. The illustrated manifest is a configuration example, not a ready-to-apply file: its displayed MultiClusterIngress apiVersion contains an apparent typo, and the excerpt is incomplete. section 10.2.1
Choose this pattern when one service needs regional proximity, multicluster availability, or a stable public address during cluster migration. Health checking and traffic failover help keep the address useful when a deployment becomes unavailable. Keep the clusters and their service configurations aligned with the intended fleet-wide routing rules. section 7.2.1 section 10.2.1
View the multicluster diagram to locate the shared Ingress path relative to the GKE clusters. section 10.2.1
