Kuma Star

Careful!

You are browsing documentation for a version of Kuma that is not the latest release.

Looking for even older versions? Learn more.

MeshService

This resource is experimental. In Kubernetes, to take advantage of the automatic generation described below, you need to set both control plane configuration variables KUMA_EXPERIMENTAL_SKIP_PERSISTED_VIPS and KUMA_EXPERIMENTAL_GENERATE_MESH_SERVICES to "true" on the zone control planes that use MeshServices.

MeshService is a new resource that represents what was previously expressed by the Dataplane tag kuma.io/service. Kubernetes users should think about it as the analog of a Kubernetes Service.

A basic example follows to illustrate the structure:

apiVersion: kuma.io/v1alpha1
kind: MeshService
metadata:
  name: redis
  namespace: kuma-demo
  labels:
    team: db-operators
    kuma.io/mesh: default
spec:
  selector:
    dataplaneTags:
      app: redis
      k8s.kuma.io/namespace: kuma-demo
  ports:
  - port: 6739
    targetPort: 6739
    appProtocol: tcp
  - name: some-port
    port: 16739
    targetPort: target-port-from-container
    appProtocol: tcp

The MeshService represents a destination for traffic from elsewhere in the mesh. It defines which Dataplane 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.

Zone types

How users interact with MeshServices will depend on the type of zone.

Kubernetes

On Kubernetes, Service already provides a number of the features provided by MeshService. For this reason, Kuma generates MeshServices from Services and:

  • reuses VIPs in the form of cluster IPs
  • uses Kubernetes DNS names

You need to set the kuma.io/mesh label on any Services from which a MeshService should be generated.

In the vast majority of cases, Kubernetes users do not create MeshServices.

Universal

In universal zones, MeshServices need to be created manually for now. A strategy of automatically generating MeshService objects from Dataplanes is planned for the future.

Hostnames

Because of various shortcomings, the existing VirtualOutbound does not work with MeshService and is planned for phasing out. A new HostnameGenerator resource was introduced to manage hostnames for MeshServices.

Ports

The ports field lists the ports exposed by the Dataplanes that the MeshService matches. targetPort can refer to a port directly or by the name of the Dataplane port.

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