A Brief Primer of Kubernetes Gateway API
The Kubernetes Gateway API streamlines networking in Kubernetes clusters through resources such as Gateway, HTTPRoute, TCPRoute, and TLSRoute, offering a uniform approach for defining and overseeing external access, routing, and traffic management. However, this article will focus primarily on the role of controllers in this context.
The Crucial Role of Controllers
Similar to Ingresses, deploying a controller is necessary when working with Gateway API resources. However, it’s important to note that controllers essentially dictate the capabilities available for use with the Gateway API. You can stay informed about the current implementation status by checking here.
Let’s delve into the nuances with some examples:
As of the time of writing this article, Google’s Gateway exclusively supports HTTPRoute, limiting the versatility of Kubernetes Gateway API. This restricted support hinders seamless cross-environment utilization, as each vendor tends to have its own approach. The desire for resource portability across environments becomes evident, particularly when considering scenarios like implementing an authentication flow. If you’re unable to handle it directly in your code or if Ingress, managed by the Ingress-NGINX Controller, is already used, the need for broader compatibility becomes apparent.
You can effortlessly implement the aforementioned flow in your Kubernetes cluster with just a few annotations and deployments, sparing yourself the need to rediscover the entire process.
# Referance: https://kubernetes.github.io/ingress-nginx/examples/auth/oauth-external-auth/
...
metadata:
name: application
annotations:
nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"
...We’re essentially reaping the benefits of matured fruits, but this poses a challenge for users accustomed to Ingress and its ready-made solutions.
Fortunately, various controllers address the drawbacks associated with the Gateway API. These controllers offer a more customized approach to expanding your traffic flow, with their capabilities limited only by the efforts and creativity of their implementers.
For example, Cilium currently implements the Gateway API using Envoy. It sounds like it could be extend the flow through Envoy configurations but there’s a caveat — when defining a Gateway API resource, Cilium generates a CiliumEnvoyConfig. Yet, the current state does not support extending this Envoy Config. A ticket has been raised, and you can track its progress here.
In my exploration of controllers, Envoy Gateway stands out prominently, offering an extensive array of functionalities that surpasses what I’ve seen in others. Particularly noteworthy is the Envoy Gateway Extensions Design, granting the capability to extend Envoy Gateway independently of the official release schedule — making it arguably the most pragmatic controller in my experience.
To support our example of implementing an authentication flow, I must mentioned that they’ve introduced a custom resource named SecurityPolicy. Real-world implementations of this, like JWT Authentication and OIDC Authentication, can be examined for further insight. Should these options prove insufficient, EnvoyProxy steps in, providing the flexibility to customize virtually anything to suit your specific needs.
Istio is another significant player in this domain, offering a Gateway solution tailored for multi-cluster use cases. For hands-on exploration, you can refer to their documentation here. While I haven’t personally tested it, its relevance depends on how well it aligns with the specific requirements of your use case.
Your insights matter! Feel free to share your thoughts, and kindly point out any aspects I might have overlooked in this article. Your feedback is greatly appreciated.
