Open rikatz opened 3 years ago
I think they are gonna soon release the v1alpha2 version , we can start implementing that since there are significant changes as compared to the v1alpha1 version
@rikatz I have initiated a thread on gateway api slack about how different resources could be mapped to the existing ingress nginx resources https://kubernetes.slack.com/archives/CR0H13KGA/p1632688608134500
As https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.4.0, gateway api v1alpha2 has been released. Can we start implementing this :)
@sunlintong we are a bit overloaded with some fixes that needs to be released, but PRs are always welcome :D @tao12345666333 is working on the design of this, feel free to reach us on Slack and jump in into the design and implementation :)
Yes, I'm working on the design, and I'm expected to send out a specific design draft and task split in the near future.
Thanks for Reply, maybe I can get involved too and make it happen together :D
@tao12345666333 I am also interested in working on Gateway API implementation . Can you please include me as well while sending out the draft proposal :)
/assign
@bishtsaurabh5 sure, sorry for the long delay.
I will finish the proposal as soon as possible and send it out.
/triage accepted /priority longterm-important
@strongjz: The label(s) priority/longterm-important
cannot be applied, because the repository doesn't have them.
/priority important-longterm
one day ill have the memorized and then it will change
Is the intent to implement the Gateway in this repository or create a new one to host that code?
If a new repository is created for this purpose, this could be a good opportunity to try and differentiate the project from the NginxInc one (https://github.com/nginxinc/nginx-kubernetes-gateway) and perhaps avoid some of the confusion going around (see: https://github.com/kubernetes/ingress-nginx/issues/7554 and https://github.com/nginxinc/kubernetes-ingress/issues/1910)
Also, not sure about the current state of this endeavor, but eventually it would be nice to have a reference here : https://gateway-api.sigs.k8s.io/implementations/ so that current users of the ingress controller can again see a choice between this community one and the NginxInc one.
Thanks for your comment.
We plan implement Gateway API in this repo.
Currently we are doing some higher priority things like splitting cp and dp
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
Flagger can support sticky session if ingress-nginx support gateway api, it there a plan to support it?
Implementation of Gateway API is becoming an important choice criteria for an Ingress Controller. Most tools on the market support it in beta/preview mode. Do you have plan to support it ? Thanks !
@PierreBeucher they have mentioned, that they have it on their roadmap, however they first want to work on splitting the control- and data-plane before adding a new control-plane for the GatewayAPI
Per our talk at Kubecon Paris 2024. We will start with our implementation.
The initial release will support:
More discussion in our talk here https://www.youtube.com/watch?v=8qaU9SX-IdI
https://docs.google.com/presentation/d/1IQEmJ4FWuy9i57A11lRARdfqDtrMLuJ79mrPv8VvE94/edit?usp=sharing
Not sure if 100% applicable, but there is a bit of conversation here about Gateway API CRD / upstream complexities for helm charts: https://github.com/kubernetes-sigs/gateway-api/issues/1590.
I think it's important to consider the implications of Gateway API being outside of core k/k and the potential reality of multiple Gateway API implementations and overlap between CRDs / versions / upgrades.
I'll watch the video to see if it's been covered already, but I've been bit by this complexity that doesn't exist with Ingress (as a "batteries included" core resource vs. BYO implementation).
Not sure if 100% applicable, but there is a bit of conversation here about Gateway API CRD / upstream complexities for helm charts: https://github.com/kubernetes-sigs/gateway-api/issues/1590.
I think it's important to consider the implications of Gateway API being outside of core k/k and the potential reality of multiple Gateway API implementations and overlap between CRDs / versions / upgrades.
I'll watch the video to see if it's been covered already, but I've been bit by this complexity that doesn't exist with Ingress (as a "batteries included" core resource vs. BYO implementation).
Appreciate the word of caution. We're still working on the control plane data plane split, and then we are going full bore into this.
We need to start thinking about Gateway API (https://gateway-api.sigs.k8s.io/) in Ingress NGINX.
A good approach here would be to understand the internal controller data model (https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/types.go) and how can we reconcile Gateway API objects into the internal model.
I'm aware that probably we will need some evolution into this datamodel, but I would like to have a minimum surface change and keep some things like template generation (nginx.conf), some annotations not covered by GatewayAPI model and other stuff the way they are.
So, maybe a good first approach would be:
An alpha1 version of this would be just available to do this reconciliations. No status, no feedback to users, just turn the objects above into a structure that Ingress can understand.
Also we can look into previous arts like Contour (https://projectcontour.io/guides/gateway-api/) and HAProxy to see what lessons learned from them we can apply here :)