MeshMultiZoneService

The MeshMultiZoneService resource represents a group of MeshServices in a multizone deployment. While MeshService represents a service in a specific zone, MeshMultiZoneService can help us work around this boundary.

MeshMultiZoneService is assigned zone-agnostic hostnames and can load balance the traffic to multiple MeshServices. For example, MeshService named redis in zone east accessible through redis.svc.east.mesh.local and redis in zone west accessible through redis.svc.west.mesh.local can be aggregated into one MeshMultiZoneService accessible through redis.mzsvc.mesh.local. This way, clients don’t need to pick redis from a specific zone or be updated if another redis is added in yet another zone.

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 which is then synced to all zones. To group services, you need to select them by their labels. Each MeshService has a set of labels, some of them are placed automatically like

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

A basic example follows to illustrate the structure:

apiVersion: kuma.io/v1alpha1
kind: MeshMultiZoneService
metadata:
  name: redis
  namespace: kuma-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

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.

Hostnames and VIPs

HostnameGenerator can be used to assign hostnames.

Kuma 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 MeshMultiZoneService in the global control plane GUI.

Ports

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

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

Load balancing

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 MeshLoadBalancingStrategy, by targeting MeshMultiZoneService in to section.