Light Dark Auto

Multi-Tenant Operation

Greymatter Version

  • v1.8.0

Multi-Tenant service meshes can be set up, however they require some planning by mesh admins. This is due to how greymatter's control plane operates outside of Kubernetes namespace bounds. Specifically, greymatter mesh configs are not namespace scoped but the pods it is making network connections to are. This can lead to collisions if not properly managed.

For example, Team 1 and Team 2 both use Redis as a database. Since pods are namespace scoped these could both be stood up in separate namespaces and be named redis. However, if this convention bleeds into mesh configs then greymatter's service discovery would identify these two pods as two instances that belong to the same cluster object. This would result in traffic being sent to either pod instead of their intended destinations.

Changes Required

To overcome this obstacle a couple changes need to take place. In this section we use greymatter init and make note of where a naming scheme must be followed to easily allow for multi-tenant meshes. These changes could also be accomplished in helm-chart templates that abstract both deployments and stateful sets.

Manifests

The XDS_CLUSTER environment variable of a sidecar should be of the form <namespace>-<name>. Additionally, if your manifest sets a greymatter.io/cluster this should be set to <namespace>-<name> as well. The operator will respect any labels specified and will not override them.

CUE

When using the greymatter init command to create a new service, <service>.cue service name should be of the form <namespace>-<name>. This matches the XDS_CLUSTER value:

greymatter init service --type=http --package=myProject --dir greymatter mynamespace-backend

This service would be available through the the application edge node.

Best Practices

  • Use application edge nodes to segment applications and their backing services.
  • For services that are to be utilised across teams, admin teams should note and publish their XDS_CLUSTER values (<namespace>-<name>) so other teams can create their own routes to the desired service.
  • Implement RBAC filters on listener objects of services that will be utilized by multiple teams.