MeshMultiZoneService

The MeshMultiZoneService resource represents a group of MeshServices in a multi-zone deployment.

MeshMultiZoneService is assigned zone-agnostic hostnames and can load balance the traffic to multiple MeshServices. For example, a MeshService named redis in zone east accessible through redis.svc.east.mesh.local and a MeshService named redis in zone west accessible through redis.svc.west.mesh.local can be aggregated into one MeshMultiZoneService accessible through redis.mzsvc.mesh.local.

The most common use case for using MeshMultiZoneService is to group MeshServices that spawn across multiple clusters with failover to another cluster in case of unavailability in the local cluster.

Contrary to MeshService, MeshMultiZoneService is not autogenerated, it has to be defined on the global control plane.

To group services, you need to select them by their labels. Each MeshService has a set of labels. Some of them are added automatically:

• kuma.io/display-name: The original name of the MeshService from the zone where it was created.
• k8s.kuma.io/namespace: The original namespace of the MeshService from the zone where it was created.

Here’s an example of the MeshMultiZoneService configuration:

apiVersion: kuma.io/v1alpha1
kind: MeshMultiZoneService
metadata:
  name: redis
  namespace: kong-mesh-system
  labels:
    kuma.io/mesh: default
spec:
  selector:
    meshService:
      matchLabels:
        kuma.io/display-name: redis
        k8s.kuma.io/namespace: redis-system
  ports:
  - port: 6379
    appProtocol: tcp

type: MeshMultiZoneService
name: redis
mesh: default
spec:
  selector:
    meshService:
      matchLabels:
        kuma.io/display-name: redis
        k8s.kuma.io/namespace: redis-system
  ports:
  - port: 6379
    appProtocol: tcp

resource "konnect_mesh_multi_zone_service" "redis" {
  provider = konnect-beta
  type = "MeshMultiZoneService"
  name = "redis"
  spec = {
    selector = {
      mesh_service = {
        match_labels = {
          kuma.io/display-name = "redis"
          k8s.kuma.io/namespace = "redis-system"
        }
      }
    }
    ports = [
      {
        port = "6379"
        app_protocol = "tcp"
      }
    ]
  }
  labels   = {
  "kuma.io/mesh" = konnect_mesh.my_mesh.name
  }
  cp_id    = konnect_mesh_control_plane.my_meshcontrolplane.id
  mesh     = konnect_mesh.my_mesh.name
}

The MeshMultiZoneService represents a destination for traffic from elsewhere in the mesh. It defines which MeshService objects serve this traffic as well as what ports are available. It also holds information about which IPs and hostnames can be used to reach this destination.

HostnameGenerator can be used to assign hostnames.

Kong Mesh assigns each MeshMultiZoneService a unique Virtual IP. The default CIDR is 243.0.0.0/8 and can be changed by configuring a zone control plane with the KUMA_IPAM_MESH_MULTI_ZONE_SERVICE_CIDR environment variable.

Hostnames and VIPs are assigned and stored in the MeshMultiZoneService status in each zone. It means that you won’t be able to see them in the status of the MeshMultiZoneService in the global control plane GUI.

The ports field lists the ports exposed by the MeshService that the MeshMultiZoneService matches:

ports:
- name: redis-non-tls
  port: 16739
  appProtocol: tcp

If available, the local zone is always preferred when a client sends a request. Otherwise, the request is load balanced equally for each zone. You can customize this behavior with the MeshLoadBalancingStrategy policy, by targeting MeshMultiZoneService in the to section.