File: README.md Copy Chapter

The most widely deployed gateway in Kubernetes for microservices

About kgateway Copy Chapter

Kgateway is the most mature and widely deployed gateway in the market today. Built on open source and open standards, kgateway is a resilient and performance-oriented control plane that implements the Kubernetes Gateway API for Envoy.

With a control plane that scales from lightweight microgateway deployments between services to massively parallel centralized gateways handling billions of API calls, kgateway brings omni-directional API connectivity to any cloud and any environment.

Use Cases Copy Section

Kgateway is designed for:

• Next-Gen API Gateway: Expose APIs and apply policies like authentication, authorization and rate limiting in one place. Powered by Envoy and programmed with the Gateway API, kgateway is a world-leading Cloud Native API Gateway.

• Hybrid Application Migration: Route to backends implemented as microservices, serverless functions or legacy apps. Gradually migrate from legacy code while maintaining existing systems.

• Complex Tenancy Environments: Multiple personas and teams can work with kgateway to express their APIs, with concepts like route delegation and composable policies.

Kgateway is feature-rich, fast, and flexible. It excels in function-level routing, supports legacy apps, microservices and serverless, offers robust discovery capabilities, integrates seamlessly with open-source projects, and is designed to support hybrid applications with various technologies, architectures, protocols, and clouds.

[!IMPORTANT]
Kgateway previously acted as a control plane for the agentgateway dataplane to enable several AI and agentic features.
Starting with version 2.3.0, the control plane for agentgateway has been migrated to the agentgateway repo, enabling a singular focus for kgateway to be a stable, robust, and battle-tested API Gateway powered by Envoy.

History Copy Section

The project was launched in 2018 as Gloo by Solo.io and has been production-ready since 2019. Since then, it has steadily evolved to become the most trusted and feature-rich API gateway for Kubernetes, processing billions of API requests for many of the world's biggest companies. Please see the migration plan for more information about the transition from Gloo to kgateway.

Get involved Copy Chapter

• Join us on our Slack channel
• Check out the docs
• Read the kgateway blog
• Learn more about the community
• Watch a video on our YouTube channel
• Follow us on X, Bluesky, Mastodon or LinkedIn

Contributing to kgateway Copy Chapter

Please refer to devel/contributing/README.md as a starting point for contributing to the project.

Releasing kgateway Copy Chapter

Please refer to devel/contributing/releasing.md as a starting point for understanding releases of the project.

Security Copy Chapter

See our SECURITY.md file for details.

Thanks Copy Chapter

Kgateway would not be possible without the valuable open source work of projects in the community. We would like to extend a special thank-you to Envoy and agentgateway, the two data planes upon which we build our dual control plane architecture.

Contributors Copy Chapter

Thanks to all contributors who are helping to make kgateway better!

Star History Copy Chapter

File: api/README.md Copy Chapter

APIs for kgateway

This directory contains Go types for kgateway APIs & custom resources.

Adding a new API / CRD Copy Chapter

These are the steps required to add a new CRD to be used in the Kubernetes Gateway integration:

1. If creating a new API version (e.g. v1, v2alpha1), create a new directory for the version and create a doc.go file with the // +kubebuilder:object:generate=true annotation, so that Go types in that directory will be converted into CRDs when codegen is run.
   • The groupName marker specifies the API group name for the generated CRD.
   • RBAC rules are defined via the +kubebuilder:rbac annotation (note: this annotation should not belong to the type, but rather the file or package).
2. Create a _types.go file in the API version directory. Following gateway_parameters_types.go as an example:
   • Define a struct for the resource (containing the metadata fields, Spec, and Status). Follow the API guidelines below.
   • Define a struct for the resource list (containing the metadata fields and Items)
3. Run codegen via make generated-code -B. This will invoke the controller-gen command specified in generate.go, which should result in the following:
   • A zz_generated.deepcopy.go file is created in the same directory as the Go types.
   • A zz_generated.register.go file is created in the same directory as the Go types, to help with registering the Go types with the scheme.
   • CRDs are generated in the CRD helm chart template dir: install/helm/kgateway-crds/templates
   • RBAC roles are generated in install/helm/kgateway/templates/role.yaml
   • Updates the api/applyconfiguration, pkg/generated and pkg/client folders with kube clients. These are used in plugin initialization and the fake client is used in tests.
4. Register the CRD with the client in pkg/apiclient/types.go.
5. Register the CRD for tests, in both places:
   • filterObjects in pkg/apiclient/fake/fake.go
   • AllCRDs in test/testutils/crd.go

API guidelines Copy Chapter

• Include documentation as well as any appropriate json and kubebuilder annotations on all fields.
• Document the default value for each field, if applicable.
• For optional fields:
  • Use the +optional marker.
  • Use the omitempty json struct tag.
  • Use pointer types (e.g. *string), unless the type has a nil zero value (e.g. slices/maps). An exception is if the field has a default value (+kubebuilder:default=...); then it it acceptable to use a non-pointer type.
• For required fields:
  • Use the +required marker.
  • Required fields MUST NOT set the omitempty json struct tag.
• Avoid using slices with pointers (e.g. use []string instead of []*string). See: https://github.com/kubernetes/code-generator/issues/166
• For time duration fields, use the metav1.Duration type and use CEL validation rules to ensure it is within the correct range.
• For constraints across a group of fields, use +kubebuilder:validation:AtLeastOneOf or +kubebuilder:validation:ExactlyOneOf rather than hand-written CEL.

Replicating Gateway API policies in TrafficPolicy API Copy Section

Gateway API policies may be replicated as a part of the TrafficPolicy API to enable policy attachment at different levels in the config hierarchy, such as at the Gateway, Gateway's listener, or route level. The following guidelines should be considered when doing so:

• When the Gateway API types are considered sufficient to meet the requirements, they can be embedded as is in the TrafficPolicy API. TrafficPolicy's cors is an example where the Gateway API type HTTPCORSFilter is embedded directly.
• When embedding the Gateway API type, it is important to consider whether the type is marked as <gateway:experimental>, as experimental types may introduce breaking changes and should be noted similarly in the TrafficPolicy API. It is discouraged to embed experimental types in the TrafficPolicy API. However, if there is a breaking change in the Gateway API type, it is recommended to replicate the previous version of that type into the TrafficPolicy API and not propagate the breaking change to the TrafficPolicy API.
• When the Gateway API types are not sufficient and a more advanced API is required, a new type should be created in the TrafficPolicy API instead of embedding the Gateway API type. TrafficPolicy's retry and timeouts are examples that define new types instead of reusing the HTTPRouteRetry and HTTPRouteTimeouts types from the Gateway API.

File: devel/README.md Copy Chapter

Developing kgateway

Find tools and information to help you develop the kgateway project.

• architecture: Descriptions about high-level design and implementation of kgateway.
• contributing: Information to help you contribute to the project, such as how to open issues, review pull requests, and generate code.
• debugging: Information on how to run/debug the kgateway controller.
• testing: Descriptions on how the tests work and how to use them.

Other resources:

• Kgateway product documentation