Cloud-native tooling company Solo.io has used the update of its enterprise Istio product Gloo Mesh to introduce the ecosystem to Gloo Mesh Gateway.
Gloo Mesh Gateway is described as an API gateway and Kubernetes ingress controller that governs and manages requests for services. Solo.io promises the production-ready addition to provide users with advanced rate-limiting capabilities, mechanisms for authenticating and authorising requests, multi-cluster ingress, and delegation as a way of assembling routing configurations from separate config objects.
According to its documentation, it can be configured either as a layered gateway — which allows different policies or management routines for different parts of a cluster — or a virtual one. This way the Mesh Gateway is meant to cater to both mesh and edge architectures, which are exactly the areas in which Solo.io has tried to make a name for itself.
When combining Gloo Mesh Core and the Gateway, the company now talks of Gloo Mesh Enterprise — a product looking to tempt potential customers with the functionality just mentioned and niceties such as serverless function integration, a developer portal, data loss prevention strategies, and OIDC/Oauth 2.0 flows.
Users who aren’t really in the market for a new investment piece should still take a moment to look at the open-source Gloo Mesh 1.1. Since the first major release back in March 2021, the project received a couple of new features including a guide on getting started with Gloo Mesh metrics features, a restrictive federation mode for VirtualMeshes, an option to pass –set to add extra helm values to the Gloo Mesh installation, and APIs for external CA features and service dependencies.
Enterprise users will probably find the initial integration with self-service project Gloo Portal and the extended Istio support especially interesting. The latter now covers the last five releases instead of the three it previously featured.
Other than that, the Gloo Mesh team reworked the project to capture all external address information on the destination CRD so that externally-addressable Kubernetes services can be used as ingress gateways, and give users the option to select specific destinations as ingress gateways for meshes in the same virtual mesh. Teams now also receive information about the chart subcomponent name for each subchart, and can query the state of VirtualHost, VirtualGateway, and RouteTable resources.
Command line tool meshctl learned new commands cluster configure for generating files for automated cluster interactions, cluster list for listing registered clusters, and debug report for capturing cluster information and logs into archives. Details on all the improvements are available in the release notes of the 36 betas needed to get to the 1.1 release.