Gloo, by, is the first alternative to Istio on Knative

Istio’s main role in Knative is to serve as an ingress technology. Gloo now joins Istio as an integrated and supported Ingress for Knative. See end of article for a quick demo.

In a nutshell, Knative exists to provide means to build and serve workloads on Kubernetes. One of the distinguishing characteristics of Knative is its serverless nature: it associates the execution of workloads to events while only consuming compute capacity when such events happen.

Knative is a technology that was initially created at Google and is now a joint, open-source collaboration with many companies such as Pivotal, Red Hat, SAP, IBM, and others.

Serving Requests with Knative

Let’s take a brief look at how requests are served with Knative and how it compares with ‘pure’ Kubernetes.

traditional workload on Kubernetes, let’s say a web application, would need a running Pod and an ingress to allow traffic to flow from and to the cluster.

Now through the lenses of Knative, let’s consider the example below: a scenario where a client wants to retrieve weather-forecast information from an application that is registered in the Knative platform but is not necessarily running. Using Knative terminology, there’s a Service that creates the necessary configurations and routes so that the Weather Forecast application can run when it’s invoked. An application in the Knative context is a combination of:

Drilling down a bit into the traffic-management part, Knative Serving has a component called Activator, which among other things, is responsible for reporting that a certain workload needs a correspondent number of Pods running to process the requests.

The beauty of this architecture is that in case the Pods responsible for running the Application are not running, the request is put on hold until traffic can be routed to that one or more Pods. This optimizes resource utilization.

In case you’re wondering, there are also features that allow you to warm up the application so that no requests are blocked. This enables you to make smart decisions based on whether or not you want to always keep a Pod running.

As mentioned earlier, once there’s a Revision (one or many Pods) to handle the request, the traffic can flow from the Ingress Gateway to your Revision. Knative Serving continues to be notified of requests coming in, in order to identify a need to scale up or down the Pods serving a Revision. That’s great!

The Istio Need

Requests may need to be routed to different Revisions of the same Configuration (read your workload specification), especially in situations where you’re concurrently running different versions of the same application. In order to do that, Knative needs an Ingress Controller that can perform the functions below loves Istio. We have invested in building a Service Mesh orchestrator and management platform called SuperGloo which is probably the easiest way to get started with Istio. On a personal level, I also admire Istio. While at Red Hat I participated in the official launch of the project and wrote about why it became so popular.

But If I make an honest evaluation of Istio’s role on Knative, this is what it feels like:

Istio brings to the table an amazing set of features, but only a few of those are utilized by Knative. As a reference, Istio currently has 48 CRDs (CustomResourceDefinition objects) and only one is mainly used by Knative, the VirtualService.

Now If your organization is also willing to adopt a Service Mesh technology, and Istio is your choice, then this pain is certainly reduced. For that, you will have to be or already are familiar with how Istio works. Now for a number of users, the added complexity may not be worth it.

Enter Gloo, a Next Gen. API Gateway, to serve as, well, a Gateway.

Gloo is a Next Generation API Gateway that meets the needs of Knative while not bringing the unneeded baggage of a full-blown Service Mesh technology, which is the case with Istio.

Built on top of Envoy, Gloo is the first official alternative to Istio for Knative.

But what does this mean in reality? When we decided to invest in this solution, one of our main goals was the sustainability of the solution. It is certainly frustrating when projects that work together suddenly stop functioning when there’s a new version, and our work to integrate was focused on mainly three areas: Ease of Use, Implementation and Continuous Integration.

Ease of Use

A key mission of as a company is to bridge the gap between advanced open source technology and the enterprises and users that consume such technology. To this extent, we have improved the installation of Knative itself when using Gloo. The whole community can immediately benefit from an easier way to experiment and be productive.

The popular glooctl command now includes a Knative option that not only installs the Gloo gateway itself but will also install Knative (!!!). During that install process, Knative gets configured with Gloo as its cluster Ingress Gateway, and it does that with a single command:

$ glooctl install knative


While this is an obvious one, we created the necessary controls and watches so that Gloo can function and report on the same or better level of capacity that Istio Ingress was functioning as. Most of this work was done on Gloo itself. On a technical level, Gloo was extended to include the ability to read and apply configuration based on the Knative ClusterIngress CRD.

Continuous Integration

We implemented and introduced specific Gloo tests into the CI test pipeline of Knative, meaning that the community would get notified and act in accordance if, for example, a change in Knative breaks the integration with Gloo, or vice-versa. This adds the much-needed peace of mind for anyone looking for an alternative to Istio on Knative, which is, at the of time writing this article, the only other alternative.

Get it now!

If you have access to a Kubernetes cluster, just download the glooctl version that best fits your operating system and start your Knative (and Gloo) journey right now. We recently added support for Windows as well. For more help, check out our Knative specific documentation and join our Slack.

Gloo can do more than basic ingress routing. Gloo was designed as a next-generation API Gateway capable of understanding function-level (HTTP1, HTTP2, gRPC, REST/OpenAPISpec, SOAP, WebSockets, Lambda/Cloud Functions) calls and can assist in your evolution from monoliths to microservices and serverless. Attend our webinar where we’ll go over how to incrementally and safely evolve your application architecture to take advantage of new capabilities to meet your business needs without having to make risky changes to your monolith.

Watch the video