☰
Navigation :

API v1 and v2 comparison

The Gloo Mesh Enterprise API is available in two versions, v1 and v2. Each version supports different custom resources that are used to simplify service mesh management in single and multicluster environments.

Diagram of Gloo Mesh workspaces

Key features

Review a quick summary of the key new features in Gloo Mesh v2.

Diagram of Gloo mesh quick start

Comparison

Compare v1 and v2 differences like API endpoint, component names, custom resources, and more.

Diagram of person-based application networking tasks

Blog

Read how Gloo Mesh v2 reimagines application networking APIs, by Lin Sun.

Key new features of Gloo Mesh API v2

Workspaces for multitenancy

Gloo introduces a new concept for Kubernetes-based multi-tenancy, 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.

With workspaces, you can more easily manage your single and multicluster environments, including the following key benefits:

For information, see Workspaces.

Enhanced installation for managed Istio and more scalable clusters

As in v1, you still install Gloo Mesh v2 in a relay server and agent architecture. This architecture is enhanced to be more highly available and scalable, including the following benefits:

For information, see Architecture.

Flexible custom resources, such as Policies

The v2 API introduces a new set of custom resources and reorganizes the APIs into admin, networking, and policy groups. Additionally, the API is designed around a set of user personas that can help you think about the responsibilities for the people on your team.

Instead of grouping entire service meshes together into a VirtualMesh as in v1, you use Workspaces. Workspaces are more flexible, because you can group together only the namespaces that you want from each service mesh. You set service isolation and federation on a per-workspace basis. You can even import and export resources across workspaces by configuring their workspace settings.

Similarly, by moving out the networking policies into separate custom resources, as opposed to the inline approach in v1 resources, you get more flexibility. For example, your operator team can configure Gloo Mesh policies. Then, your developers can use the Kubernetes selectors that they are already familiar with to pair up their routes or destinations with these policies.

For more information, see:

VM onboarding to extend the mesh outside clusters

With Gloo Mesh v2, you can add virtual machines (VMs) to your service mesh environment. This way, services in the VM can be accessed and controlled by the same policies and networking resources as in your clusters.

For more information, see Onboarding VMs.

Comparison of v1 and v2

For a point-by-point comparison of the different versions, review the following table.

You cannot use both v1 and v2 in the same Gloo Mesh environment.

Area API v1 API v2
API endpoint *.gloo.solo.io/v1 *.gloo.solo.io/v2
Component names Management server: enterprise-networking, remote cluster agent: enterprise-agent Management server: gloo-mesh-mgmt-server, remote cluster agent: gloo-mesh-agent
Where to create Gloo Mesh resources Must be in the management cluster. Some resources such as Workspaces must be created in the management cluster. Most other Gloo Mesh resources can be created in any registered cluster.
Supported version † Gloo Mesh Enterprise 1.2 and earlier. Gloo Mesh Enterprise 2.0 and later.
Custom resource differences Fewer Gloo Mesh CRs. Gloo Mesh CRs have more 1-to-many relationships with inputs and outputs such as Istio resources. New Workspace and other CRs to simplify managing your resources. Gloo Mesh CRs have more 1-to-1 relationships with inputs and outputs such as Istio resources for better reusability across north-south and east-west gateways and improved observability for easier self-service.
Controlling access to the CRDs Custom Gloo Mesh RBAC. Native Kubernetes RBAC.
Isolation and federation Configured by VirtualMesh on a mesh basis and secured via mTLS. Configured by WorkspaceSettings on a workspace basis (namespaces and clusters) and secured via mTLS.
Policy and routing differences Routes can have policies defined within the configuration. Separate configurations for east-west vs. north-south traffic policies. Policies are created separately and applied to destinations, routes, or workloads by Kubernetes selectors. Policies are more reusable and simpler for developers to consume. For example, different development teams in different workspaces can use the same retry or timeout policies. The same policy can apply to both east-west and north-south traffic.
Selectors Resources are often specified individually and in-line in other resources, making it harder to scale. For example, in a VirtualMesh, you specify cluster-1, cluster-2, etc. Resources can be specified by name or by Kubernetes selectors, for more flexible scaling. For example, you can have a workspace that automatically adds clusters with the label env: prod.
Single to multicluster transition You create a separate management cluster and register each workload cluster. Istio meshes that run in your registered workload clusters are automatically discovered. Then, you create more Gloo Mesh CRs in the management cluster for the resources you want. You still create a separate management cluster, register workloads, and get automatic Istio discovery. However, because you use Workspaces and selectors or regex names to organize resources, you can more easily scale the Workspace to all the workload clusters, which automatically creates the Gloo Mesh CRs for you.

† For the corresponding Istio and Kubernetes versions that the Gloo Mesh version supports, see Supported versions.