-
-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Gateway API #81
Comments
I haven't explored the Gateway API too much myself, but the reason for converting the operator from targeting the ingress to the service was that you can do anything you could by pointing to the ingress and more with a service. Same thing goes for the Gateway API, at the end, all of them end in a service, which is where you can point the tunnel to directly, since the Unless you are suggesting to make an ingress/gateway controller out of |
Yeah, I'm suggesting a gateway controller to allow configuring Needing additional CRDs for routing should be avoidable. Here's a quick mapping that might be possible:
A new CRD (eg TunnelPolicy) would be required to handle credentials etc, but policy attachment might simplify this overall. A TunnelPolicy could be applied to multiple gateways, so config would be reusable between tunnels (I have a lot of duplicated config with the current ClusterTunnels/Tunnels). Ongoing use of a gateway would only need the various routes, and those come with extra functionality. Eg HTTPRoutes could allow easier implementation of TCP/UDP routes are still experimental though, and the API as a whole only reached beta recently. So maybe not something for the short term. I've just had great experiences with the API on other platforms, and it's worked really well for other flexible routing platforms. |
Ahh, so instead of a TunnelBinding, use one of the Gateway API's CRDs. That is a good way if everything that Cloudflare supports can be mapped neatly without abusing the Gateway API's meaning of the fields. I would have to look into this a bit more. Thanks for the idea! I will keep this as an enhancement for now. |
Gateway classes support a lot more than what cloudflared needs to be concerned with. GAPI just creates a service of type LoadBalancer, which you can point the daemon/operator to. This feature feels like it's asking too much of cloudflared. |
@dudo GAPI doesn't require a LoadBalancer, and its core functionality seems like a good match for cloudflare-operator at first glance. particularly since cloudflare-operator originally used ingress annotations, and seemingly moved to CRDs for extensibility (#51) which is a GAPI design goal. With Cloudflare adding more tunnel features (eg path-based routing), the existing CRDs might be difficult to maintain, vs GAPI where these concepts are standardised |
I've been hitting too many reconciliation bugs with this operator recently, so I'm going to try implementing GAPI separately with remote tunnel config. aiming for tunnel/hostname/service/path reconciliation first, since |
My Gateway controller has been stable for around 6 months. I haven't implemented policy attachment or non-HTTP protocols yet though |
Has there been any discussions on implementing support for the k8s beta Gateway API? The API should be flexible enough to implement most Tunnel capabilities, and uses built-in resources so new users can easily onboard/offboard (eg ingress2gateway).
Not sure whether this project would be the best fit, or a separate project from scratch. As I imagine this design as a gateway controller implementation, rather than an operator.
The text was updated successfully, but these errors were encountered: