Webinar Recap – Gloo 1.3 Overview: Developer Portal and enhancements in performance, usability, and more
A few weeks ago we released version 1.3 of Gloo open source and enterprise – our next generation API Gateway and Kubernetes Ingress Controller built with Envoy Proxy. Gloo allows you to connect, secure, control and extend any application API — monolith, microservices and serverless across multiple clouds and on-prem. This week, Rick Ducott gave a talk and demo on the 1.3 release.
This release focused on new features and enhancements to improve both the developer and operator experience along with improvements to system performance, stability, usability, and troubleshooting.
We are especially thankful to the community for their feedback and contribution to this release including @sandromlp, @mrManner, @iridian-ks, @emaincourt, @kdelorey, @snuggie12, @via-jordan-sokolic, @dmurawsky, @thebsdbox, and @stevendanna for their PRs — if I forgot yours, please DM me and I’ll update. If you’re interested in getting involved, check out the repo on GitHub.
Enjoy the replay and register for our upcoming webinar on May 28th to dig into multi-cluster Kubernetes and service mesh patterns.
Watch the replay here
Highlights from the Q&A
Does Gloo work with Istio or is it a replacement for it?
This is a very common question we get when discussing Gloo as an API gateway as both Gloo and Istio use Envoy as the underlying proxy technology but in different ways. To start, Gloo and Istio are complimentary in an environment as they handle different types of application traffic. Gloo is responsible for what’s called “north/south” or traffic that enters into or exits a cluster. Istio, or service mesh more generally, is responsible for “east/west” or the communication between the services within the cluster. Watch a demo showing Gloo and Istio integrated together here.
How does the Gloo developer portal work with OpenAPI/Swagger?
Yes we support both OpenAPI and Swagger today. For OpenAPI, the tutorial in docs shows an admin workflow using OpenAPI documents to publish the API and to display some of the properties like the display name and the description. You can find the details and tutorial here in docs.
There were many questions related to what kind of Authentication is supported in Gloo including: JWT, API Keys, OIDC, Azure AD, and LDAP.
Instead of answering each one individually, we’re grouping into one to address Auth in the Gloo system and in the developer portal. Gloo supports a number of auth options at the system level from: basic, custom auth server, OIDC, API Key, JWT, Open Policy Agent, custom auth server, and auth plugins. The custom auth and plugin model provide the ability to extend Gloo to any auth system you like. You can also chain auth together to do both user and system auth in a flow. Gloo Enterprise provides these external auth integrations are available out of the both and open source users can manually configure auth by deploying your own service and configuring Gloo’s control plane to use it to secure your virtual services. Read more about auth in Gloo and try the tutorials here.
We have more coming soon in the Gloo developer portal related to expanding the auth capabilities so stay tuned. Currently the admin UI provides a workflow to create users and groups who can access the portal and supports API keys for authentication. Try the auth workflow here.
Is it possible to make Gloo to listen on port 80 & 443 in non-cloud Kubernetes deployment?
Yes, Gloo is configurable to listen to non-default ports. In the Gloo architecture, there is a proxy object that shows you which bind ports the system is using. You can customize this by looking at the gateway CRD, which is what controls the Envoy listener. This can be changed by editing or adding new gateway CRDs. Note that there should be one gateway CRD configured per port. Read more about this in the traffic management docs.
Does the Gloo developer portal support interfaces other than REST? Could you publish gRPC or GraphQL APIs?
Download the presentation