Overview
Before diving in to Gloo Platform workspace configuration, take a minute to step back and consider the question of why multitenancy matters.
Multitenancy and microservices
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
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 proxy 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.