tao12345666333 opened a new issue #644:
URL: https://github.com/apache/apisix-ingress-controller/issues/644


   Gateway API is an open source project managed by the SIG-NETWORK
   community. It's is a collection of resources that model service networking 
   in Kubernetes. These resources - `GatewayClass`,`Gateway`, `HTTPRoute`, 
   `TCPRoute`, `Service`, etc - aim to evolve Kubernetes service networking 
through 
   expressive, extensible, and role-oriented interfaces that are implemented by 
   many vendors and have broad industry support. 
   
   
   The following design goals drive the concepts of the Gateway API. These 
   demonstrate how Gateway aims to improve upon current standards like Ingress.
   
   
   - **Role-oriented** - Gateway is composed of API resources which model 
   organizational roles that use and configure Kubernetes service networking. 
   - **Portable** - This isn't an improvement but rather something
   that should stay the same. Just as Ingress is a universal specification with
   [numerous 
implementations](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/),
   Gateway API is designed to be a portable specification supported by many
   implementations.
   - **Expressive** - Gateway API resources support core functionality for 
things 
   like header-based matching, traffic weighting, and other capabilities that 
   were only possible in Ingress through custom annotations.
   - **Extensible** - Gateway API allows for custom resources to be linked at 
   various layers of the API. This makes granular customization possible at the
   appropriate places within the API structure.
   
   Some other notable capabilities include:
   
   - **GatewayClasses** - GatewayClasses formalize types of load balancing 
   implementations. These classes make it easy and explicit for users to 
   understand what kind of capabilities are available via the Kubernetes 
resource 
   model.
   - **Shared Gateways and cross-Namespace support** - They allow the sharing of
   load balancers and VIPs by permitting independent Route resources to bind to
   the same Gateway. This allows teams (even across Namespaces) to share
   infrastructure safely without direct coordination.
   - **Typed Routes and typed backends** - The Gateway API supports typed Route 
   resources and also different types of backends. This allows the API to be 
   flexible in supporting various protocols (like HTTP and gRPC) and
   various backend targets (like Kubernetes Services, storage buckets, or
   functions). 
   
   docs here: https://gateway-api.sigs.k8s.io/
   
   I think we should add support for Gateway API. To accomplish this, the 
following steps are required:
   
   * TBD


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to