Skip to content

Frequently Asked Questions (FAQ)

  • Q: How can I get involved with Gateway API?
     A: The community page keeps track of how to get involved with the project.

  • Q: Will Gateway API replace the Ingress API?
     A: No. The Ingress API is GA since Kubernetes 1.19. There are no plans to deprecate this API and we expect most Ingress controllers to support it indefinitely.

  • Q: What are the differences between Ingress and Gateway API?
     A: Ingress primarily targets exposing HTTP applications with a simple, declarative syntax. Gateway API exposes a more general API for proxying that can be used for more protocols than just HTTP, and models more infrastructure components to provide better deployment and management options for cluster operators.

  • Q: Will there be a default controller implementation (in this repo)?
     A: There is no current plan to have an "official" or "default" implementation. You will see the controller code in this repo be used for testing the support libraries.

  • Q: How can I expose custom capabilities through Gateway API?
     A: There is a lot of diversity in the networking and proxying ecosystem, and many products will have features that are not directly supported in the API. However, there are a few mechanisms available for extending the API with implementation-specific capabilities:

    • Decorate Gateway API objects with implementation-specific objects. A policy or configuration object could match the Gateway API object either by name or by using an explicit object reference.

      For example, given a Gateway object with name "inbound", creating a AccessPolicy object that also has the name "inbound" could cause an implementation to attach a specified access control policy. This is an example of matching the object by name.

    • Use implementation-specific values for string fields. In many places, the fields of Gateway API resources have the type "string". This allows an implementation to support custom values for those fields in addition to any values specified in the API.

    • Use implementation-specific annotations. For some kinds of configuration, implementations may choose to support custom annotations on Servce API objects. This approach continues a proud tradition of extending Ingress objects.

    • Use API-defined extension points. Some Service API objects have explicit extension points for implementations to use.

  • Q: Where can I find Gateway API releases?
     A: Gateway API releases are tags of the Github repository. The Github releases page shows all the releases.

  • Q: How should I think about the alpha release?
     A: The v1alpha1 release will be the first Gateway API release. As various projects begin implementing the API, and operators start using it, the working group will collect feedback and issues, which will guide what revisions are needed for the next release. It is possible that the next release will contain breaking changes.

  • Q: Which Kubernetes versions are supported?
     A: Generally, we support Kubernetes 1.16+, but certain features like AppProtocol depend on Kubernetes 1.18 (opt-in) or 1.19 (on by default). There are not any other exceptions to the 1.16+ guideline right now.

Back to top