The evolution of Ingress through the Gateway API


We have three types components. 

1. Transparent Proxies: sidecar, kube-proxy
2. Cloud LB: GCP, Azure, AWS
3. Middle Proxies: nginx, HAProxy, Envoy

Now their functionalities are overlapping 

In K8s, Ingress is simple L7 description 

Roles: 
1. Infrastructure Provider 
2. Cluster Operator / NetOps / SRE 
3. Applicatoin DEveloper 

In case of Ingress, Infrastructure Provider provides IngressClass. No role for SRE. Application Developer defines Ingress and Service

In case of Gateway API, Infrastructure Provider provides GatewayClass. It is associated with type of LB. SRE provides Gateway implementation. Application Developer defines Route and Service

We have K8s objects like

1. GatewayClass
2. Gateway provides: Exposure and access, LB
3. Route: HTTP, TCP, UDP, SNI and TLS: HTTPS, TLS
4. Service about grouping and selection 

API groups
1. Core: Must be supported
2. Extended: Feature specific. May be supported, must be portable
3. Implementation specific: Not K8s API schema. No guarantee for portability

Gateway contains route. Route can be CRD. 
Earlier we had single ingress resource. Now it splits in Gateway and Route. So there may be conflict. E.g. same host, same path in multiple routes. 

Extension Points in Alpha
1. GatewayClass parameters for LB configuration
2. Gateway.Listener have ExtensionRef to customize listener properties
3. Route: Custom filter via ExtenstionRef. Backend is more than Services, like ingress

ExtenstionRef is for CRD. 

Reference:

0 comments:

Post a Comment