embeddedfiles

README

NGINX Kubernetes Gateway

NGINX Kubernetes Gateway is an open-source project that provides an implementation of the Gateway API using NGINX as the data plane. The goal of this project is to implement the core Gateway APIs -- Gateway, GatewayClass, HTTPRoute, TCPRoute, TLSRoute, and UDPRoute -- to configure an HTTP or TCP/UDP load balancer, reverse-proxy, or API gateway for applications running on Kubernetes. NGINX Kubernetes Gateway is currently under development and supports a subset of the Gateway API.

For a list of supported Gateway API resources and features, see the Gateway API Compatibility doc.

Warning: This project is actively in development (beta feature state) and should not be deployed in a production environment. All APIs, SDKs, designs, and packages are subject to change.

Learn about our design principles and architecture.

Getting Started

1. Quick Start on a kind cluster.
2. Install NGINX Kubernetes Gateway.
3. Build an NGINX Kubernetes Gateway container image from source or use a pre-built image available on GitHub Container Registry.
4. Deploy various examples.

NGINX Kubernetes Gateway Releases

We publish NGINX Kubernetes Gateway releases on GitHub. See our releases page.

The latest release is 0.5.0.

The edge version is useful for experimenting with new features that are not yet published in a release. To use, choose the edge version built from the latest commit from the main branch.

To use NGINX Kubernetes Gateway, you need to have access to:

• An NGINX Kubernetes Gateway image.
• Installation manifests.
• Documentation and examples.

It is important that the versions of those things above match.

The table below summarizes the options regarding the images, manifests, documentation and examples and gives your links to the correct versions:

Version	Description	Image	Installation Manifests	Documentation and Examples
Latest release	For experimental use	Use the 0.5.0 image from GitHub	Manifests.	Documentation. Examples.
Edge	For experimental use and latest features	Use the edge image from GitHub	Manifests.	Documentation. Examples.

Technical Specifications

The following table lists the software versions NGINX Kubernetes Gateway supports.

NGINX Kubernetes Gateway	Gateway API	Kubernetes	NGINX OSS
Edge	0.7.1	1.21+	1.25.x *
0.5.0	0.7.1	1.21+	1.25.x *
0.4.0	0.7.1	1.21+	1.25.x *
0.3.0	0.6.2	1.21+	1.23.x *
0.2.0	0.5.1	1.21+	1.21.x *
0.1.0	0.5.0	1.19+	1.21.3

*the installation manifests use the minor version of NGINX container image (e.g. 1.25) and the patch version is not specified. This means that the latest available patch version is used.

SBOM (Software Bill of Materials)

We generate SBOMs for the binaries and the Docker image.

Binaries

The SBOMs for the binaries are available in the releases page. The SBOMs are generated using syft and are available in SPDX format.

Docker Images

The SBOM for the Docker image is available in the GitHub Container repository. The SBOM is generated using syft and stored as an attestation in the image manifest.

For example to retrieve the SBOM for linux/amd64 and analyze it using grype you can run the following command:

$ docker buildx imagetools inspect ghcr.io/nginxinc/nginx-kubernetes-gateway:edge --format '{{ json (index .SBOM "linux/amd64").SPDX }}' | grype

Contacts

We’d like to hear your feedback! If you experience issues with our Gateway Controller, please open a bug in GitHub. If you have any suggestions or enhancement requests, please open an idea on GitHub discussions. You can contact us directly via kubernetes@nginx.com or on the NGINX Community Slack in the #nginx-kubernetes-gateway channel.

Contributing

Please read our Contributing guide if you'd like to contribute to the project.

Support

NGINX Kubernetes Gateway is not covered by any support contract.

Documentation

Index

• Variables

Variables

var StaticModeDeploymentYAML []byte

StaticModeDeploymentYAML contains the YAML manifest of the Deployment resource for the static mode.

We put this in the root of the repo because goembed doesn't support relative/absolute paths and symlinks, and we want to keep the manifests in the deploy/manifests directory.