What if you want to share services across workspaces? For example, maybe you want your gateway in Team A’s workspace to route traffic to a frontend service in Team B’s workspace, but not to Team C’s backend services.

You can share resources across workspaces by configuring the workspace settings and the selectors on your services. You have to configure the settings for both workspaces, which help to make sure that you don’t export resources by mistake.

Export to and import from settings

Make sure that your importing and exporting settings match across your workspaces.

  • exportTo must be set in your workspace for each workspace that you want to export resources to.
  • importFrom must be set in the other workspace, and match your workspace that you export from.

You can select your workspaces by using labels and names.

Labels: Use Kubernetes labels to select workspaces for importing or exporting. Each workspace must have the matching label. For example, you might use labels such as team: frontend, app: bookinfo, or env: prod. By using labels, any workspaces that are subsequently added are also selected.

Names: If you want more fine-grained control, you can select workspaces by name. The following types of matching are supported.

  • Exact match, such as name: frontend for a workspace named frontend.
  • Simple regex, such as name: frontend* for any workspaces with names that begin with frontend.

Labels and names together: For more fine-grained control, you can combine labels and names together.

Select resources to share across workspaces

After setting up the workspaces to import from and export to, you can narrow sharing to a particular resource. The following kinds of resources are supported:

  • ApiDoc, a Gloo custom resource that represents the schema of an API that is served by a destination (Kubernetes service or Gloo external service).
  • CloudProvider, a Gloo custom resource that defines the details of a cloud provider where resources like serverless functions exist.
  • ExternalService, a Gloo custom resource for services that run outside the cluster environment, such as in on-prem virtual machines (VMs).
  • RouteTable, a Gloo custom resource that defines routes to the destinations of your apps.
  • Service, a Kubernetes service that typically exposes an app workload like a deployment.
  • VirtualDestination, a Gloo custom resource for services in other clusters.

You can select resources by label, name, namespace, or cluster. For more information, see the API docs.

After importing a resource, Gloo generates subsequent resources like Istio translations in each namespace of the workspace. This way, you can use the imported resources just as other resources in your workspace.

Example scenarios for importing and exporting

For more information about how importing and exporting work, review the following figure, tabbed description, and example configuration file.

Figure: Importing and exporting resources across workspaces.
Figure: Importing and exporting resources across workspaces.
Figure: Importing and exporting resources across workspaces.
Figure: Importing and exporting resources across workspaces.

The Ops team’s workspace selects the ingress gateway and Gloo add-on resources like rate limiting and external auth. Their workspace settings resource is configured as follows:

  • Exports the Gloo add-on services and virtual destinations for rate limiting and external auth to any workspace. This way, any future workspaces can also use these Gloo features.
  • Imports the Web team’s frontend app resources so that the ingress gateway can route to the frontend.
  • Does not import the Backend API team because the ingress gateway does not need to route to those backend apps.
  • Disables federation, because Gloo virtual destinations are the preferred way to enable multicluster routing, if needed.
  • Enables service isolation so that resources are secured without additional policy configuration.

The Web team’s workspace has the frontend apps that run the website. Their workspace settings resource is configured as follows:

  • Imports the Backend API team’s backend apps. This way, the frontend website can use the backend services.
  • Imports the Ops team’s add-on apps, as well as the gateway.
  • Exports to the Ops team so that the gateway can route to the frontend app.
  • Disables federation, because Gloo virtual destinations are the preferred way to enable multicluster routing, if needed.
  • Enables service isolation so that resources are secured without additional policy configuration.

The Backend API team’s workspace has the backend apps that the frontend website needs. Their workspace settings resource is configured as follows:

  • Imports the Ops team’s add-on apps so that the backend services can use Gloo features such as rate limiting.
  • Does not import the Ops team’s gateway app because the backend services do no need to be exposed via ingress.
  • Exports to the Web team so that the frontend app can use the backend APIs.
  • Disables federation, because Gloo virtual destinations are the preferred way to enable multicluster routing, if needed.
  • Disables service isolation. Instead, the Backend API team uses Gloo access policies for more fine-grained access control.

Example YAML configuration

The following GitHub Gist example configures the settings for three workspaces. You create workspace settings resources in the workload cluster of your choice, as long as that cluster is part of the workspace. For more information, see the API docs.

# | -------------------------------------------------------------------------------- |
# | For more information, see the Gloo Platform workspace documentation: |
# | https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prod/workspaces/about/ |
# | -------------------------------------------------------------------------------- |
# Namespaces in the management cluster
apiVersion: v1
kind: Namespace
metadata:
name: ops-team-config
---
apiVersion: v1
kind: Namespace
metadata:
name: backend-apis-team-config
---
apiVersion: v1
kind: Namespace
metadata:
name: web-team-config
---
# Workspaces in the namespaces in the management cluster
apiVersion: admin.gloo.solo.io/v2
kind: Workspace
metadata:
name: ops-team
namespace: gloo-mesh
labels:
gloo.solo.io/team: 'ops'
spec:
workloadClusters:
- name: 'mgmt'
namespaces:
- name: ops-team-config
- name: '*'
namespaces:
- name: gloo-mesh-gateways
- name: gloo-mesh-addons
---
apiVersion: admin.gloo.solo.io/v2
kind: Workspace
metadata:
name: web-team
namespace: gloo-mesh
labels:
gloo.solo.io/team: 'web'
spec:
workloadClusters:
- name: 'mgmt'
namespaces:
- name: web-team-config
- name: '*'
namespaces:
- name: web-ui
---
apiVersion: admin.gloo.solo.io/v2
kind: Workspace
metadata:
name: backend-apis-team
namespace: gloo-mesh
labels:
gloo.solo.io/team: 'backend-apis'
spec:
workloadClusters:
- name: 'mgmt'
namespaces:
- name: backend-apis-team-config
- name: '*'
namespaces:
- name: backend-apis
---
# Workspace settings for each workspace
apiVersion: admin.gloo.solo.io/v2
kind: WorkspaceSettings
metadata:
name: ops-team
namespace: ops-team-config
spec:
importFrom: # import from the Web team so the gateway can route to these imported resources
- workspaces:
- name: web-team
exportTo: # export to any workspace that wants to use Gloo Platform add-ons such as rate limiting and external auth
- workspaces:
- name: "*"
resources:
- kind: SERVICE
namespace: gloo-mesh-addons
- kind: VIRTUAL_DESTINATION
namespace: gloo-mesh-addons
options:
federation: # disabled because VirtualDestinations are the preferred way to set up multi-cluster routing
enabled: false
eastWestGateways: # default east-west gateway routing
- selector:
labels:
istio: eastwestgateway
serviceIsolation: # enable service isolation and Istio Sidecar resource
enabled: true
trimProxyConfig: true
---
apiVersion: admin.gloo.solo.io/v2
kind: WorkspaceSettings
metadata:
name: web-team
namespace: web-team-config
spec:
importFrom:
- workspaces:
- name: backend-apis-team # import from the Backend APIs team so the web frontend can use these imported resources
- workspaces:
- name: ops-team # import Gloo Platform add-ons such as rate limiting and external auth and the gateway
exportTo:
- workspaces:
- name: ops-team # export frontend web services to the Ops team to enable routing to the frontend web services from the gateway
options:
eastWestGateways: # default east-west gateway routing
- selector:
labels:
istio: eastwestgateway
federation: # disabled because VirtualDestinations are the preferred way to set up multi-cluster routing
enabled: false
serviceIsolation: # enable service isolation and Istio Sidecar resource
enabled: true
trimProxyConfig: true
---
apiVersion: admin.gloo.solo.io/v2
kind: WorkspaceSettings
metadata:
name: backend-apis-team
namespace: backend-apis-team-config
spec:
exportTo:
- workspaces:
- name: web-team # export services to the Web team so the frontend web services can use the backend API services
importFrom:
- workspaces:
- name: ops-team # import Gloo Platform add-ons such as rate limiting and external auth
options:
eastWestGateways: # default east-west gateway routing
- selector:
labels:
istio: eastwestgateway
federation: # disabled because VirtualDestinations are the preferred way to set up multi-cluster routing
enabled: false
serviceIsolation: # disabled service isolation to use AccessPolicies instead to control fine-grained access
enabled: false
trimProxyConfig: false
view raw gloo-workspace.yaml hosted with ❤ by GitHub