Overview

Gloo introduces a new concept for Kubernetes-based multitenancy, the Workspace custom resource. A workspace consists of one or more Kubernetes namespaces that are in one or more clusters. Think of a workspace as the boundary of your team’s resources. To get started, you can create a workspace for each of your teams. Your teams might start with their apps in a couple Kubernetes namespaces in a single cluster. As your teams scale across namespaces and clusters, their workspaces scale with them.

Before diving in to Gloo workspace configuration, take a minute to step back and consider the question of why multitenancy matters.

Multitenancy and microservices link

Flip through the following overview of how workspaces organize your services across Kubernetes clusters and namespaces.

Think of all the apps in your cluster environment. You might have thousands. But no one person is typically responsible for all of the apps. Instead, you have different teams that own different apps, such as insurance, finance, and infrastructure teams.

Wouldn’t it be nice if you could group each team’s apps together, for consistent management? Maybe you could even share select resources across teams. You can, with Gloo workspaces.

Right now, you might use Kubernetes clusters and namespaces to isolate each team’s resources. Although this approach works, you face challenges of consistent management across namespaces and clusters.

With Gloo workspaces, you can group all your team’s resources across clusters and namespaces. Depending on your settings, your resources become available to other resources in the workspace automatically. You can create Gloo resources like policies to control how traffic works across resources, too. This way, a workspace encompasses all the services that a team, product, or business unit owns.

Taking it a step further, you can even share your services across workspaces. Both workspaces must agree to share. The source workspace decides which destination workspaces to export to, and the destination workspaces decide which source workspaces to import from. You control such sharing by configuring the importFrom and exportTo fields in the Gloo workspace settings.

You can use selectors to import all services with a certain label, or you can specify the services to import and export by name or simple regex matching. For more information, see Workspace configuration.

For example, in the following diagram:

• Sharing from Team A to the other workspaces does not work, because Team A does not export to any workspace.
• Sharing from Team B to Team A works, because Team B exports to Team A and Team A imports from Team B. However, Team B does not export to any other workspace, and does not import any workspace.
• Sharing to and from Team C to the other workspaces does not work, because no importing and exporting are set up.

Gloo Workspace solves multitenancy concerns link

Gloo workspaces provide boundaries for how Gloo, Istio, and Kubernetes resources access each other across other workspaces. These boundaries help you manage services, sharing, and security settings across all the teams, or “tenants” in your organization.

Workspaces help you solve the following multitenancy concerns.

• Service discovery: Gloo automatically discovers the services within the Kubernetes namespace and cluster that a workspace includes. By default, services within the same workspace can access other services within the same workspace, but not services in other workspaces. This way, your teams can focus on managing their own services without disrupting other teams.
• Routing: Workspaces are a logical boundary for which services can route to one another. To route to services in other workspaces, your teams must actively agree to import and export select resources across their workspaces.
• Policy enforcement: Workspaces define the scope at which a policy can impact your environment. This helps reduce the blast radius of a misconfigured policy and ensure more predictable traffic behavior.
• Security: Workspaces set a virtual boundary to protect services from traffic outside of the workspace. You must explicitly choose to allow access from other workspaces. For example, you might restrict the ingress gateway to its own workspace. Then, you might set up your other workspaces so that only the frontend exports to and imports from the gateway. The rest of your backend apps are secured by default.
• Consistent configuration: Gloo configuration applies only within the workspace. You can further centralize Gloo configuration to a single namespace in a management cluster. This way, you know exactly where your Gloo configuration is.

More resources for workspaces link

For more information about using workspaces, check out the Solo.io blog about how Gloo Mesh workspaces help multitenant teams manage their apps, by Lin Sun.