sigs.k8s.io/gateway-api@v1.0.0/site-src/faq.md (about)

     1  # Frequently Asked Questions (FAQ)
     2  
     3  *   **Q: How can I get involved with Gateway API?<br>**
     4      A: The [community](/contributing/community) page keeps track of how to get
     5      involved with the project.
     6  
     7  *   **Q: Will Gateway API replace the Ingress API?<br>**
     8      A: No. The Ingress API is GA since Kubernetes 1.19. There are no
     9      plans to deprecate this API and we expect most Ingress controllers
    10      to support it indefinitely.
    11  
    12  *   **Q: What are the differences between Ingress and Gateway API?<br>**
    13      A: Ingress primarily targets exposing HTTP applications with a
    14      simple, declarative syntax. Gateway API exposes a more general API
    15      for proxying that can be used for more protocols than just HTTP,
    16      and models more infrastructure components to provide better
    17      deployment and management options for cluster operators.
    18  
    19      For more information, see the [Migrating from Ingress](https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/) guide.
    20  
    21  *   **Q: Will there be a default controller implementation (in this repo)?<br>**
    22      A: There is no current plan to have an "official" or "default"
    23      implementation. You will see the controller code in this repo be
    24      used for testing the support libraries.
    25  
    26  *   **Q: How can I expose custom capabilities through Gateway API?<br>**
    27      A: There are a few mechanisms available
    28      for extending the API with implementation-specific capabilities:
    29  
    30      * The [Policy Attachment](https://gateway-api.sigs.k8s.io/reference/policy-attachment/)
    31        model allows you to decorate Gateway API objects with implementation-specific CRDs. A
    32        policy or configuration object could match the Gateway API object either
    33        by name or by using an explicit object reference.
    34  
    35      * Use implementation-specific values for string fields in Gateway API resources.
    36  
    37      * As a last resort, use implementation-specific annotations on Gateway API objects.
    38  
    39      * Use API-defined extension points. Some Gateway
    40        API objects have explicit [extension points](/concepts/api-overview#extension-points)
    41        for implementations to use.
    42  
    43  *  **Q: Where can I find Gateway API releases?<br>**
    44      A: Gateway API releases are tags of the [Github repository][1].
    45      The [Github releases][2] page shows all the releases.
    46  
    47  * **Q: How should I think about alpha API versions?<br>**
    48      A: Similar to upstream Kubernetes, alpha API versions indicate that resources
    49      are still experimental in nature and may either be removed or changed in
    50      breaking ways in future releases of Gateway API.
    51  
    52      See the [Versioning](https://gateway-api.sigs.k8s.io/concepts/versioning/) documentation for more info.
    53  
    54  * **Q: Which Kubernetes versions are supported?<br>**
    55      A: See our policy on [Supported Version](https://gateway-api.sigs.k8s.io/concepts/versioning/#supported-versions)
    56  
    57  * **Q: Is SSL Passthrough supported?<br>**
    58      A: SSL Passthrough (wherein a Gateway routes traffic with the [Transport
    59      Layer Security (TLS)][tls] encryption _intact_ to a backend service instead of
    60      terminating it) is supported by [TLSRoutes][tlsroute]. See the
    61      [TLS Guide][tlsguide] for more details about passthrough and other TLS
    62      configurations.
    63  
    64  * **Q: What's the difference between Gateway API and an API Gateway?<br>**
    65      A: An API Gateway is a general concept that describes anything that exposes
    66      capabilities of a backend service, while providing extra capabilities for
    67      traffic routing and manipulation, such as load balancing, request and response
    68      transformation, and sometimes more advanced features like authentication and
    69      authorization, rate limiting, and circuit breaking.
    70  
    71      Gateway API is an interface, or set of resources, that model service networking
    72      in Kubernetes. One of the main resources is a `Gateway`, which declares the
    73      Gateway type (or class) to instantiate and its configuration. As a Gateway
    74      Provider, you can implement the Gateway API to model Kubernetes service
    75      networking in an expressive, extensible, and role-oriented way.
    76  
    77      Most Gateway API implementations are API Gateways to some extent, but not all
    78      API Gateways are Gateway API implementations.
    79  
    80  * **Q: Is Gateway API a standard for API Management?<br>**
    81      A: No. API Management is a much broader concept than what Gateway API aims to
    82      be, or what an API Gateway is intended to provide. An API Gateway can be an
    83      essential part of an API Management solution. Gateway API can be seen as a
    84      way to standardize on that aspect of API Management.
    85  
    86  [1]: https://github.com/kubernetes-sigs/gateway-api
    87  [2]: https://github.com/kubernetes-sigs/gateway-api/releases
    88  [tls]:https://en.wikipedia.org/wiki/Transport_Layer_Security
    89  [tlsroute]:/concepts/api-overview#tlsroute
    90  [tlsguide]:/guides/tls