API concepts
The Gloo API helps you set up and manage API gateways to control traffic to your apps.
Core concepts
Before diving into how the Gloo API is organized and designed, flip through the following core concepts.
You might have heard a lot of talk about the “modernization” of monolithic apps to microservices. For example, your team might write all of your applications as a single unit, or “monolithic” app. Deploying the app is simple, as long as you knew the app requirements and your environment. Securing the app is also simple, because you typically control a single ingress and egress point.
As your team adds more features, however, your monolithic app can become slower and harder to update and scale. Additionally, you duplicate a lot of business logic for management features like connectivity, security, reliability, and observability, into each monolithic app.
You can develop faster if you split up the larger app into smaller apps whose services can be consumed by other services on-demand. This microservice approach gives your teams more autonomy and flexibility, but adds a level of management complexity. Open source projects, such as Kubernetes and Istio, help solve the microservice management problem.
Kubernetes is a platform that helps you manage containerized applications at scale. You start with Nodes, which might be bare metal, virtual machines (VMs), or other types of computing hosts. Then, you group the nodes together into a Kubernetes cluster. Finally, you use Kubernetes API objects to run your containerized apps in the cluster.
Usually, you configure Kubernetes API objects with YAML files that conform to various schemas. For example, you can package a container in several different types of workload objects, the smallest of which is a Pod. Another common object is a Kubernetes Service, which exposes the container of a particular workload object. A service makes the app available to other apps within the cluster, or more publicly outside the cluster on a specific port or load balancer.
Resources are organized into namespaces for isolation. Often, users can configure resources only within the namespaces that they have access to. You might also set rules for compute resource consumption by namespace.
Although Kubernetes ships with some very powerful primitives, you can also extend the platform with custom resource definitions (CRDs). After installing CRDs, you can use Kubernetes-native API and CLI tooling to manage those custom resources. For example, Gloo installs CRDs so that you can create and manage Gloo resources such as workspaces.
Envoy is an open source proxy. The proxy, or API gateway, is a server that handles requests to and responses from your apps. You can put a lot of the business logic that you used to have in a monolithic app into the proxy. Then, all your microservices can share this logic by using the same proxy.
The Envoy proxy supports Layer 4 transport and Layer 7 application data of the OSI model. Envoy has many capabilities to make your application traffic more performant, extensible, observable, and secure. For example, Envoy can get real-time configuration updates through the xDS API. These updates do not require a proxy restart. You can adjust available routes and policies without downtime.
As you can tell, application networking can become quite complicated! You have to know a lot about Kubernetes, Envoy, and Istio. If you want more than one cluster, such as for high availability, keeping everything in sync becomes even harder. Gloo simplifies managing your app traffic across clusters by introducing its own custom resources (CRs).
For more information, see the following resources.
- Learn more about Gloo benefits in the Benefits page.
- Configure each custom resource in the API reference documentation.
Use Gloo workspaces to organize Kubernetes and Gloo Gateway resources for multiple teams. Workspaces allow for multitenancy and serve as a boundary for team resources across Kubernetes namespaces and clusters. To get started, 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.
Gloo Gateway can help you by organizing your namespaces into Workspaces. You can share resources across workspaces by configuring the workspace settings to import and export. To prevent unintentional sharing, both workspace settings must have a matching import-export setup. You can even select particular resources to import or export, such as with Kubernetes labels, names, or namespaces. Your developers do not have to worry about exposing their apps. They deploy the app in their own namespace, and refer to the services they need to use, even if the service is in another namespace or workspace. As long as the appropriate Gloo Gateway CRs are in an imported workspace, Gloo Gateway takes care of the rest.
These CRs might be networking or policy resources that manage traffic within the workspace. These capabilities make it easier for you to onboard teams and increase consistency in your multitenant environment. With workspaces, you also can more easily control access to your services through consistent security policies.
For more information, see the following resources.
API groups
The v2 API is organized into groups. Review the following table and diagram for a brief overview of the groups of APIs.
You can learn more about specific APIs in the API reference documentation.
| API group | API endpoint | Description |
|---|---|---|
| Admin | admin.gloo.solo.io/v2 |
The v2 API introduces a new set of admin APIs, including Workspaces. Use these APIs to configure how your team uses your Gloo environment across clusters. For example, use workspaces as team boundaries across Kubernetes clusters and namespaces. Decide which workspaces can import and reuse resources from other workspaces. Set up the ability to deploy extra servers for rate limiting or external auth. Then, you can delegate administration so that each team only accesses what they need to. |
| API management | apimanagement.gloo.solo.io |
Use the API management group to manage configuration for your own APIs, such as through the GraphQL or Gloo Portal integrations. For example, you can create an API doc resource to define your API schema. Then, you might create a GraphQL resolver map to define your GraphQL resolver servers, or create a portal resource to define a developer portal. |
| Infrastructure | infrastructure.gloo.solo.io/v2 |
Use the infrastructure APIs to configure interaction between resources in your Gloo Platform setup and resources in your cloud infrastructure provider. For example, you can create a cloud provider custom resource to define the AWS region, account, and IAM roles that you want Gloo Gateway to use to access AWS Lambda functions. |
| Networking | networking.gloo.solo.io/v2 |
Use the networking APIs to set up connectivity across services. For example, you can create virtual gateways that use route tables with the host domains of your services. You can even route to services outside a Kubernetes cluster with external destinations. For example, you might have an app in a bare metal or virtual machine. Your networking resources reside in your workspaces for more control over your services. |
| Policy | *.policy.gloo.solo.io/v2 |
Apply policies to routes or destinations within your workspace for more granular control. The policies help you control resilience, security, observability, traffic, and more. Any service in the workspace can reuse the policies you want. You can even export policies to other workspaces, making policies consistent across teams. |
| Other APIs | common.gloo.solo.io, core.solo.io, and more |
Other Gloo API groups are defined only for internal use or for building components of the main API groups. These other API groups do not define Gloo custom resources that you can create. |
Using Gloo API v2
- Install Gloo Gateway to at least version 2.1.
- Review the API groups of objects that you can create with API v2.
- When you create the custom resources, make sure to specify the API v2 endpoint in the configuration files. For example, you can create a global workspace with the following configuration.
apiVersion: admin.gloo.solo.io/v2 kind: Workspace metadata: annotations: cluster.solo.io/cluster: "" name: anything namespace: gloo-mesh spec: workloadClusters: - name: '*' namespaces: - name: '*' - Develop a labelling strategy for your resources. The Gloo API relies on selectors to choose objects. For example, labels select the policies to apply to resources like virtual destinations. For more information about labels and selectors, see the Kubernetes documentation.
Creating Gloo custom resources
Review the following guidance for creating Gloo custom resources.
What Gloo resources can I create?
After installing Gloo in your cluster, you can list available custom resources with the following command.
kubectl api-resources -o wide | grep solo
To learn more about each resource, review the API reference docs.
How do I create Gloo resources?
Create a configuration file, typically in YAML format. To help build your files, the docs provide many copiable examples. Then, review the API reference docs for more in-depth information on specific settings.
Where should I create Gloo resources?
With Gloo, you can set up multitenant workspaces that reflect how you organize your team. Very few custom resources are required to be created in particular cluster or namespace. However, you might prefer to create some custom resources together for simplicity.
Simple multicluster setup: Create all your Gloo resources in the management cluster. This way, your workload clusters are reserved for your apps, and all of the networking configuration is stored on the same management cluster. You can still set up multiple workspaces to keep each team's configuration separate from each other.
How can I share Gloo resources across workspaces and clusters?
To share resources, you set up importing and exporting at the workspace level. Review the following table to learn how where you create a resource restricts how you can share the resource. For more information, see Import and export resources across workspaces.
| Where you want the resource available | Where to create the resource |
|---|---|
| Only to resources in the same workspace | Any namespace in the workspace. Include a virtual destination for multicluster workspaces. Do not export the workspace to other workspaces. |
| Only to resources in the same workspace on the same cluster | Any namespace in the cluster in the workspace. Do not include a virtual destination. Do not export the workspace to other workspaces. |
| To resources in other workspaces | Anywhere in your workspace. Make sure that your workspace exports to the other workspaces. The other workspaces also must import your workspace. Consider adding labels to share workspace resources more scalably. |
How can I apply policies to my app network traffic?
Policies might apply to the following resources:
- Destinations: Destinations determine where incoming requests are routed to. A destination can be a Kubernetes Service, a Gloo VirtualDestination in a multicluster setup, or a Gloo ExternalService custom resource that you use to reach endpoints that are outside your service mesh.
- Listeners: Listeners are the virtual gateways and ports that a gateway workload listens for incoming traffic on. You must apply a listener policy to a Gloo VirtualGateway custom resource, not the gateway workload directly.
- Route: Routes define how to match an incoming request, and what actions you want to perform on a matched request. For example, you can decide to forward the request to a destination in the service mesh, directly respond to the request without forwarding, or manipulate and redirect requests. Routes are defined in a Gloo RouteTable custom resource.
- Workloads: A workload represents the app that responds to incoming request. For example, you can have Kubernetes workloads such as Deployments or StatefulSets. Or, you can use an Istio WorkloadEntry that might run in a bare metal or virtual machine outside your Kubernetes cluster.
You can apply the policies by using Kubernetes labels and selectors that match the route table, virtual destination, or workload. Remember, all of these resources must be in the same workspace for the policy to apply the resource. To see what resources a policy might select, check the Kubernetes labels such as with the following commands.
kubectl get <KIND> <RESOURCE> -n <NAMESPACE> -l <KEY=VALUE>
kubectl get all -A -l env=prod
Some policies support selecting multiple kinds of resources, such as both destinations and routes. When you have multiple selectors, you might wonder how the selectors impact each other. For more information, refer to each policy guide:
Custom resource translation
After installing and registering clusters with Gloo, certain Kubernetes and Istio resources are automatically discovered and translated as custom resources in Gloo. Going forward, you can configure Gloo custom resources to automatically create the Istio resources that are needed to manage your Gloo environment.
Translated resources follow a naming convention of <first-31-chars>-<32-char-hash-of-full-string> and are 63 characters or less. This convention is used because Kubernetes labels can only be up to 63 characters long, and translated names are sometimes used in labels.
The following figure outlines how Gloo custom resources are translated into Istio resources.
Note that many translations depend on fields that you configure in a Gloo resource. For example, a policy might create only a DestinationRule, or both a DestinationRule and VirtualService, depending on how you configure the policy. Additionally, multiple Gloo resources can configure the same or different Istio resources, depending on what you specify.
Next Steps
With a firm grounding in the core API concepts, you're ready to learn more about Gloo's architecture or dive into the Getting Started guide.