Gloo Edge invites developers to extend Gloo Edge’s functionality and adapt to new use cases via the addition of plugins.
Gloo Edge’s plugin based architecture makes it easy to extend functionality in a variety of areas:
- Gloo Edge’s API: extensible through the use of Protocol Buffers along with Solo-Kit
- Service Discovery Plugins: automatically discover service endpoints from catalogs such as Kubernetes and Consul
- Function Discovery Plugins: annotate services with information discovered by polling services directly (such as OpenAPI endpoints and gRPC methods).
- Routing Plugins: customize what happens to requests when they match a route or virtual host
- Upstream Plugins: customize what happens to requests when they are routed to a service
- Operators for Configuration: Gloo Edge exposes its intermediate language for proxy configuration via the Proxy Custom Resource, allowing operators to leverage Gloo Edge for multiple use cases. With the optional Gloo Edge GraphQL module, you can set up API gateway and GraphQL server functionality for your apps, without running in the same process (or even the same container) as Gloo Edge.
Gloo Edge API Concepts
v1.Proxies provide the routing configuration which Gloo Edge will translate and apply to Envoy.
v1.Upstreams describe routable destinations for Gloo Edge.
Proxies represent a unified configuration to be applied to one or more instances of a proxy. You can think of the proxy of as tree like such:
proxy ├─ bind-address │ ├── domain-set │ │ ├── /route │ │ ├── /route │ │ ├── /route │ │ └── tls-config │ └── domain-set │ ├── /route │ ├── /route │ ├── /route │ └── tls-config └─ bind-address ├── domain-set │ ├── /route │ ├── /route │ ├── /route │ └── tls-config └── domain-set ├── /route ├── /route ├── /route └── tls-config
A single proxy CRD contains all the configuration necessary to be applied to an instance of Envoy. In the Gloo Edge system, Proxies are treated as an intermediary representation of config, while user-facing config is imported from simpler, more opinionated resources such as the gateway.solo.io.VirtualService or Kubernetes Ingress objects.
For this reason, a standard Gloo Edge deployment contains one or more controllers which programmatically generate and write these CRDs to provide simpler, use-case specific APIs such as API Gateway and Ingress. You can extend these capabilities even more with Gloo Edge modules, such as Gloo Edge GraphQL. This optional module is an advanced controller which creates routing configuration for Gloo Edge from GraphQL Schemas.
Click here for a tutorial providing a simple example utilizing this lower-level Proxy API. This tutorial will walk you through building a Kubernetes controller to automatically configure Gloo Edge without any user interaction](example-proxy-controller.go).
Upstreams represent destinations for routing requests in Gloo Edge. Routes in Gloo Edge specify one or more Upstreams (by name) as their destination. Upstreams have a
typewhich is provided in their
upstreamSpecfield. Each type of upstream corresponds to an Upstream Plugin, which tells Gloo Edge how to translate upstreams of that type to Envoy clusters. When a route is declared for an upstream, Gloo Edge invokes the corresponding plugin for that type
This Section includes the following developer guides:
Building External Auth Plugins: Guidelines and best practices for developing and configuring Go plugins to extend Gloo Edge's ext auth server
Note: the Controller tutorial does not require modifying any Gloo Edge code.