This project is in the process of being donated to the CNCF and is not affiliated with the Kubernetes project.

Frequently asked questions

What is K8sGateway?

K8sGateway is an open source, cloud-native Layer 7 proxy that is based on Envoy. The K8sGateway project implements gateway routing by using Kubernetes Gateway API resources.

Why would I want to use K8sGateway?

The K8sGateway project was built to support the difficult challenges of monolith to microservice migration, which includes being able to connect multiple types of compute resources, such as virtual machines (VMs) and on-premises monolithic apps with cloud-native, Kubernetes-based apps.

Other use cases K8sGateway can solve include the following:

  • Kubernetes cluster ingress with a custom K8sGateway API as well as native support for the Kubernetes Gateway API.
  • API gateway functionality for services that run outside Kubernetes
  • Routing, resiliency, and security capabilities for enhanced traffic management

What’s the difference between K8sGateway and Envoy?

The Envoy proxy is a data-plane component with powerful routing, observability, and resilience capabilities. However, Envoy can be difficult to operationalize and complex to configure.

The K8sGateway project comes with a simple yet powerful control plane for managing Envoy as an edge ingress, API Gateway, or service proxy. The K8sGateway control plane is built on a plugin model that enables extension and customization depending on your environment. This flexibility lets K8sGateway adapt both to the fast pace of development in the open source Envoy community, as well as to the unique needs of differing operational environments.

The K8sGateway includes the following capabilities beyond open source Envoy:

  • A flexible control plane with extensibility in mind
  • More ergonomic, domain-specific APIs to drive Envoy configuration
  • Function-level routing that goes beyond routing to a host:port for clusters, including routing to a Swagger/OpenAPI spec endpoint, gRPC function, cloud provider function such as AWS Lambda, and more
  • Transformation of request/response via a super-fast C++ templating filter built on Inja
  • Envoy filters to call AWS Lambda directly, handling the complex security handshaking
  • Discovery of services running in a hybrid platform such as of virtual machines (VMs), containers, infrastructure as code (IaC), function as a service (FaaS), and so on

What license is K8sGateway under?

The K8sGateway project uses Apache License 2.0.

What is the project roadmap?

The K8sGateway project organizes issues into milestones for release. For more details, see the GitHub project.

What is the version support policy?

The K8sGateway project supports one n latest version.

The main branch of the k8sgateway Git repository is for feature work under development, and is not stable.

Where is the changelog?

The changelog is part of each GitHub release.

Is there enterprise software that is based on K8sGateway?

Why are there some references to Gloo in this project?

The K8sGateway project was initially created as an open source project under the solo-io GitHub organization and maintained as part of Solo.io’s Gloo product family. While the open source project is transferred to the K8sGateway organization, some of the references have not been cleaned up yet. Such references might include resource names, Helm chart values, image repositories, or other hardcoded elements. The maintainers are currently working on removing Solo.io and Gloo branding from this project. If you notice any issues, feel free to contact the K8sGateway team on Slack or open an issue in the K8sGateway GitHub repo.

Can I use K8sGateway in a service mesh?

Yes, you can install K8sGateway in a service mesh environment, such as Istio.

The K8sGateway project is not a service mesh, but can be deployed complementary to a service mesh like Istio. Istio solves the challenges of service-to-service communication by controlling requests as they flow through the system. K8sGateway can be deployed at the edge of the service-mesh boundary, between service meshes, or within the mesh to add the following capabilities:

  • Mutual TLS (mTLS) encryption of traffic between the gateway and services
  • Transformation of request/response to decouple backend APIs from frontend
  • Function routing such as AWS Lambda
  • Request/response caching
  • Unified discovery services of infrastructure like Kubernetes, Consul, Vault, AWS EC2
  • Unified discovery services of functions like REST/OAS spec, gRPC reflection, SOAP/WSDL, WebSockets, Cloud Functions, AWS Lambda

For an example, see the Istio integration guide.