Import and export resources across workspaces

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 link

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 link

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.

Federated resources link

Gloo Platform federates Gloo and Kubernetes resources so that services can communicate with each other across clusters within the workspace. For example, you might have a frontend service in cluster 1 that needs to get data from a backend service in cluster 2. You can use Gloo to enable communication via federation with a virtual destination resource. Then, Gloo duplicates the service and translates any needed Istio resources so that the services communicate with each other via the Istio east-west gateway.

You can configure federation with several Gloo custom resources. If you export the resource to another workspace, the resource is also federated within that workspace.

Virtual destination link

Gloo virtual destinations are the preferred way to set up multicluster routing. When you create a virtual destination, Gloo automatically federates the resource in each namespace within the workspace, even across clusters. This way, you get intelligent, locality-aware multicluster routing for the services that the virtual destination selects. You can also attach Gloo policies to virtual destinations, such as to secure and shift traffic.

Federation is automatically enabled when you create this resource or import the resource into your workspace.

For more information, see Multicluster routing with virtual destinations.

External services link

External services are similar to virtual destinations, except that the backing services are external to your Gloo Platform environment. When you create an external service, Gloo automatically federates the resource in each namespace within the workspace, even across clusters. This way, you get intelligent, locality-aware multicluster routing for the services or external endpoints that the external service selects. You can also attach Gloo policies to external services, such as to secure and shift traffic.

Federation is automatically enabled when you create this resource or import the resource into your workspace.

For more information, see Routing to external services.

Route tables link

With route tables, you can group several routes together so that you can more easily control routing behavior. When you create a route table, Gloo automatically federates the resource in each namespace within the workspace, even across clusters. This way, you get consistent ingress control for the routes that the route table selects. You can also attach Gloo policies to the routes in the route table, such as to secure and shift traffic.

Federation is automatically enabled when you create this resource or import the resource into your workspace.

Example scenarios for importing and exporting link

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

Example YAML configuration link

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.