Webinar Recap – What’s New in Gloo 1.4
Gloo is a next generation API gateway and Kubernetes Ingress controller built with Envoy Proxy to manage and secure traffic to a diverse range of backend services like monoliths, microservices and serverless applications. Recently we released version 1.4 for both Gloo open source and enterprise versions; and this webinar provides an overview of the new functionality and demos. Scroll down to view the recording, download the presentation and read the Q&A.
The latest release of Gloo includes many new features and enhancements including:
- Improvements to system scalability
- Expanded support for Kubernetes Ingress
- Support for the latest Istio 1.6 release
- Security enhancements
- User experience enhancements for Dev and Ops
- Additional options for configuring Gloo
Watch the replay here
Highlights from the Q&A
Can I use glooctl 1.4.5 with Gloo 1.3? Is it ok to upgrade glooctl before upgrading the control plane? Is there a recommended order to upgrade the components?
The upgrades are independent of each other so there isn’t a specific order in which you must upgrade the components of your Gloo environment. The recommendation is to prep a Helm values file or a combination of Helm and Kustomize with upgrade and rollback commands to maintain the versioning of the environment. By default, glooctl will use the latest stable version of Gloo enterprise and open source, which is helpful for when you’re doing the install.
Gloo is a control plane and Istio also has a control plane, how do they work together if at all?
The Gloo control plane is to manage the envoy proxies at the edge for handling the north/south (ingress) traffic while the Istio control control plane is handling the east/west traffic through all the sidecar proxies and Gloo is complementary to Istio in this scenario. Istio also ships with an ingress gateway where Gloo can be used as a replacement for it and provides a broader feature set to support routing to services both inside and outside of the service mesh.
You can check out how Gloo and Istio integrate in this video and in the tutorial in docs.
I see that Gloo can support multiple Envoy proxies, what does this mean for how I can scale the API gateway? Horizontally and nothing else? Or something different?
Gloo is designed as a stateless system where the data plane and control plane are separate — this is specifically so they can be scaled independently of each other while the configurations can be dynamically updated to any number of proxies that have been deployed to the environment. Learn more about the architecture and its impact to scalability here.
Installing a WebAssembly (wasm) module looked relatively easy in the demo, what is the workflow like to update the wasm module?
We’ve spent a lot of time building the tooling to enable a developer workflow that looks and feels very similar to a standard Docker flow. Using the wasme CLI tool and WebAssembly Hub, you will increment the tags for your module, push it to the registry, pull it and deploy to the proxy. One of the benefits of using WebAssembly to build custom filters versus natively in C++ to the Envoy code is that you don’t require a re-compile and re-start of Envoy to apply the filter — you can dynamically apply the changes to a running Envoy proxy.
Can I implement fine-grained role-based-access-control (RBAC) with Open Policy Agent? How does that hook into Gloo? Is there a way to externalize the RBAC rules for maintenance and ‘import’ them, in an automated way
Open Policy Agent (OPA) is a really powerful language and it runs directly inside of our built in xAuth server. All you need to do is define a config map of your enforcement rules and Gloo will load it into memory and run it in the external Auth server in the Envoy filter chain. We have a guide with an example in our docs and a demo video here.
What is the best advice for HA in terms of the gateways? The default install only sets up one gateway each for http and https.
Gloo is quite flexible in how it can be deployed and can support a wide range of HA scenarios. This really depends on the architecture of your specific application; whether it is deployed to a single region, many different regions or replicated globally and how many replicas of the application exist for each instance. We’ve spent a lot of time with our customers in helping them design the Gloo environment to fit the HA requirements they have versus prescribing a specific way to always implement HA. If you’d like to get guidance on the approach, request a meeting here.
Download the presentation
Learn more
- About Gloo open source and enterprise
- Request a trial of Gloo Enterprise
- Attend an upcoming event
- Questions? Join the community slack
