In February 2019, Gloo launched as an alternative to Istio for the Kubernetes Knative service. Gloo, by Solo.io, is an API gateway implemented as a Kubernetes ingress controller for Knative applications.
Knative, an open-source project created by Google, is a set of middleware components built on Kubernetes to build, deploy, and manage workloads. Knative uses a request-driven compute model, meaning that workloads, such as a web application or function-as-a-service (FaaS) back end, are run only when the application or function is invoked.
Knative depends on an ingress/gateway for routing requests to Knative Services. Initially, Istio was the only supported ingress controller. Istio is an Envoy-based service mesh that provides features such as load balancing, traffic routing, access control, and logging and metrics.
Gloo is an Envoy-based API gateway that can serve a mix of upstream service types, including monoliths, microservices, and serverless functions. Gloo's implementation as an ingress controller is intended to provide a more lightweight solution for Knative ingress.
InfoQ reached out to Solo.io founder Idit Levine to learn more about Gloo and Knative.
InfoQ: Tell me what inspired the development of Gloo and why Solo.io pursued the integration with Knative.
Idit Levine: Solo's mission is to bridge the gap between new and existing technologies to enable enterprises to adopt, operate and gain value from the latest cloud-native architecture and tools. Gloo is a "next generation" API gateway built on Envoy proxy to connect legacy monolithic apps, microservices and serverless functions together to simplify their API and present a unified entrypoint for external clients and services. We integrated Gloo with Knative to provide the needed functionality of a function routing layer and ingress without the added complexity of a full-blown service mesh. Knative recently added the "cluster ingress" abstraction, which allows the routing layer in Knative to be pluggable. Because our Gloo control plane is built with extensibility in mind, we were able to quickly and easily integrate with Knative.
InfoQ: Gloo is the first major alternative to Istio for ingress control with Knative. What should users consider when evaluating Gloo versus Itsio for their Knative implementation?
Levine: Gloo can be used as an alternative to Istio in Knative, but generally Gloo is not a direct replacement for a full service mesh. Users should consider Gloo complementary to a service mesh, and in Knative's case, Gloo can handle the routing requirements with fewer moving parts. If you are familiar with Istio, already use it for your workloads, or are comfortable running it with Knative, then you can continue to use it as is. However, Knative doesn't need a full-blown service mesh to accomplish its primary task of simply bringing traffic into a cluster and routing it to the appropriate workloads. Gloo provides the benefit of powerful ingress routing but does not provide capabilities like service-aware metric collection. When considering Gloo versus Istio for Knative serving, you should consider the tradeoff in complexity of the routing with your observability and mesh strategy.
InfoQ: How are you hoping the Gloo Knative integration will evolve? Are there any issues or features your team is planning to address in the near future?
Levine: We will stay close to the Knative community to understand their needs and how their usage of Knative evolves over time to drive the roadmap and new areas for integration. Gloo is built on Envoy and has a very flexible control plane. We will be able to quickly and easily adapt to changes in the Knative+Gloo use cases as we learn more. Get involved by filing an issue at the Gloo project, on Knative, or contact us on Twitter or our website.
Visit the Gloo installation page to get started with Gloo and learned more about Kubernetes Knative on its GitHub documentation page.