## File: README.md

The most widely deployed gateway in Kubernetes for microservices

## About kgateway 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](https://gateway-api.sigs.k8s.io/) for [Envoy](https://github.com/envoyproxy/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 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](https://www.envoyproxy.io) and programmed with the [Gateway API](https://gateway-api.sigs.k8s.io/), 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](https://github.com/agentgateway/agentgateway) repo, enabling a singular focus for kgateway to be a stable, robust, and battle-tested API Gateway powered by Envoy. ### History The project was launched in 2018 as **Gloo** by Solo.io and has been [production-ready since 2019](https://www.solo.io/blog/announcing-gloo-1-0-a-production-ready-envoy-based-api-gateway). 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](https://github.com/kgateway-dev/kgateway/issues/10363) for more information about the transition from Gloo to kgateway. ## Get involved - [Join us on our Slack channel](https://kgateway.dev/slack/) - [Check out the docs](https://kgateway.dev/docs) - [Read the kgateway blog](https://kgateway.dev/blog/) - [Learn more about the community](https://github.com/kgateway-dev/community) - [Watch a video on our YouTube channel](https://www.youtube.com/@kgateway-dev) - Follow us on [X](https://x.com/kgatewaydev), [Bluesky](https://bsky.app/profile/kgateway.dev), [Mastodon](https://mastodon.social/@kgateway) or [LinkedIn](https://www.linkedin.com/company/kgateway/) ## Contributing to kgateway Please refer to [devel/contributing/README.md](/devel/contributing/README.md) as a starting point for contributing to the project. ## Releasing kgateway Please refer to [devel/contributing/releasing.md](devel/contributing/releasing.md) as a starting point for understanding releases of the project. ## Security See our [SECURITY.md](SECURITY.md) file for details. ## Thanks 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](https://www.envoyproxy.io) and [agentgateway](https://github.com/agentgateway/agentgateway), the two data planes upon which we build our dual control plane architecture. ## Contributors Thanks to all contributors who are helping to make kgateway better! ## Star History --- --- ## File: api/README.md # APIs for kgateway This directory contains Go types for kgateway APIs & custom resources. ## Adding a new API / CRD 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](/api/v1alpha1/kgateway/gateway_parameters_types.go) as an example: - Define a struct for the resource (containing the metadata fields, `Spec`, and `Status`). Follow the [API guidelines](#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](/hack/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](/install/helm/kgateway-crds/templates) - RBAC roles are generated in [install/helm/kgateway/templates/role.yaml](/install/helm/kgateway/templates/role.yaml) - Updates the [api/applyconfiguration](/api/applyconfiguration), [pkg/generated](/pkg/generated) and [pkg/client](/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](/pkg/apiclient/types.go). 5. Register the CRD for tests, in both places: - `filterObjects` in [pkg/apiclient/fake/fake.go](/pkg/apiclient/fake/fake.go) - `AllCRDs` in [test/testutils/crd.go](/test/testutils/crd.go) ## API guidelines - 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 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 ``, 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 # Developing kgateway Find tools and information to help you develop the kgateway project. * [architecture](./architecture): Descriptions about high-level design and implementation of kgateway. * [contributing](./contributing): Information to help you contribute to the project, such as how to open issues, review pull requests, and generate code. * [debugging](./debugging): Information on how to run/debug the kgateway controller. * [testing](./testing): Descriptions on how the tests work and how to use them. Other resources: * [Kgateway product documentation](https://kgateway.dev/docs/)