Flip through the following overview of how workspaces organize your services across Kubernetes clusters and namespaces.
Think of all the apps in your service mesh. 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 Mesh 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 Mesh 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 Mesh resources like policies to control how traffic works across resources, too.
Taking it a step further, you can even share your services across workspaces. You control such sharing by configuring the
exportTo fields in the Gloo Mesh 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 the next section, Workspaces as configuration boundaries.
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.