Going All-in on Gateway API - Replacing Ingresses and Enhancing a Service Mesh

Anyone who has used the Ingress resource in Kubernetes for any length of time knows that it is lacking in flexibility and, as a result, has resulted in just about every ingress-related project creating their own bespoke resource types or complex set of needed annotations. Gateway API is the community’s answer to alleviating this pain. It aims to do this by being “generic, expressive, and role-oriented.” Its resource model focuses on 3 separate personas and the Kubernetes resources that they are expected to manage: the infrastructure provider, the cluster operator, and the application developer. The Ingress is specifically focused on HTTP/HTTPS traffic and, as a result, requires custom extensions to work with other types of traffic. Conversely, Gateway API works for both layer 4 and layer 7 traffic and has out-of-the-box support for gRPC, HTTP/HTTPS, TCP, and UDP traffic along with support for TLS traffic where only the SNI information is used. It also takes things a step further and applies the same standardization logic, and resource types, to traffic traversing a service mesh.

This talk will dive into my experiences utilizing it with Traefik for north/south traffic instead of Ingress and IngressRoute resources and with Linkerd to enhance visibility and flexibility of the east/west traffic traversing the service mesh.