Get Started With Kubernetes SIG Gateway API

Background Of Kubernetes Gateway API

Today, there is no standard API Gateway interface for Kubernetes ingress controllers to implement. This means that users have to choose between different ingress controllers, each with their own unique API or annotations for ingress functions, which can lead to an inconsistent user experience.

The Kubernetes SIG Gateway API project aims to address this by providing a standard API Gateway interface for Kubernetes ingress controllers to implement.

Basic Introduction

Kubernetes SIG Gateway API is a Kubernetes sub-project focused on delivering API Gateway functionality for Kubernetes. It is the successor to the Ingress API, aims to standardize how Kubernetes Service APIs are surfaced to external proxy and gateway solutions in a vendor-neutral way.

By defining a standard API Gateway interface for Kubernetes ingress controllers to implement, it provides a consistent experience for Kubernetes users who require API Gateway functionality.

In the model of Gateway API, different O&M personnel are responsible for different parts of network operation applications, each performing their own duties, as the chart from the official website(https://gateway-api.sigs.k8s.io/) shows us:

Concept Of Kubernetes Gateway API

The Gateway API contains a set of resources that allow users to manage and configure load balancers and routers for their Kubernetes clusters, including GatewayClass, Gateway, HTTPRoute, and TCPRoute, etc. Within one specific resource, there are also more concepts, for example, in HTTPRoute, there are Matchers, Filters, and Backends, etc. These resources are used to define how traffic should be routed between external sources and services within the cluster.

In summary, the Gateway API aims to simplify and standardize the way users configure and manage networking resources in their Kubernetes clusters. More concepts for the resources defined in Gateway API, see https://gateway-api.sigs.k8s.io/concepts/api-overview/.

Gateway API conformance ensures that different implementations of the API work together as expected and enable interoperability between different networking solutions in Kubernetes. See more details about conformance statement from https://gateway-api.sigs.k8s.io/concepts/conformance/).

Gateway API uses RBAC to manage access to Gateway API resources across different namespaces, such as Secret, Service.

By using AllowRoute and ReferenceGrant policies, it grants different roles access to different resources. Through these policies, administrators can implement fine-grained resource access control and ensure that only authorized users can access sensitive resources.

Gateway API Versioning

The SIG Gateway API is still a work in progress and is currently being developed by the Kubernetes community. You can find more information about the project on the Kubernetes SIG Gateway API website: https://github.com/kubernetes-sigs/gateway-api.

Referred from: https://gateway-api.sigs.k8s.io/concepts/versioning/:

“

Gateway API provides 2 release channels: an Experimental one and a Standard one.

• The Standard release channel includes:
  • Resources that have graduated to beta
  • All fields that have graduated to standard and are no longer considered experimental
• The Experimental release channel includes everything in the Standard release channel, plus:
  • Alpha API resources
  • New fields that are considered experimental and have not yet graduated to the standard channel

”

Conclusion

Currently, there are many downstream implementations and integrations of Gateway API, including

• F5 BIG-IP(https://gateway-api.sigs.k8s.io/implementations/#big-ip-kubernetes-gateway) and
• NGINX(https://gateway-api.sigs.k8s.io/implementations/#nginx-kubernetes-gateway).

The Kubernetes SIG Gateway API project is an important development in the Kubernetes ecosystem, and it has the potential to make it easier for users to implement API Gateway functionality for Kubernetes. By providing a standard API Gateway interface, the project aims to reduce fragmentation in the Kubernetes ecosystem, and provide a consistent experience for Kubernetes users.