Psudo Ingress Controller

[kfox1111]

Are there any plans to support running ingress2gateway as a controller that watches for ingress objects and uploads the result as gateway objects directly to the cluster? This would help smooth out the transition to the gateway api?

[LiorLieberman]

That is a very interesting direction to go. @mlavacca also talked with me about it 3 months back.

My few concerns/thoughts are:

• The current ingress2gateway tool is operating as "Best Effort". And it is very much depends on the support level or the conversion logic the provider (an implementation) added. In this case, the controller can not just auto apply the gateway objects, a human intervention is needed to confirm and add the missing parts.

• Ideally we want users to move to use Gateway API and discourage using Ingress. Developing a controller that watches for Ingress resources, convert them, and apply to the cluster might: a) Discourage people from learning/moving to apply Gateway API resources (as the controller does the job for them) b) Causes a situation where the stored objects (lets say in git) are ingresses, but in the cluster there are other objects c) Requires vast development and collaborative maintenance from different implementations.

That said, those are just initial thoughts. I am definitely up to be convinced otherwise.

[kfox1111]

Yeah, I can understand the concern around such functionality slowing down adoption of the Gateway API, but in my case, I think it might help speed it up by breaking the deadlock around it.

An example situation...

Some cluster admins have been running ingress-nginx for a very long time. It does not currently have gateway api support, and seems unlikely to get support any time soon.

There are Gateway API only implementations such as envoy gateway that may be desirable to switch to.

There are also a ton of existing helm charts that currently only support the ingress api. It is difficult to get them to add the new apis unless there are enough users asking for support.

In environments like this, ingress2gateway as a controller can bridge the gap. Allow cluster admins to adopt a native gateway api only controller but have a bridge to support all the existing charts. Then the helm chart users have an easier path to request from the helm chart devs, "We'd like official gateway support for the chart. The software does work with the gateway api as we're already using it." The users have a harder time doing that when the clusters they are running on doesn't have support yet. The chart devs have an easier time adopting the gateway api if someone else has already ensured it works, and know more and more end clusters are gateway api enabled.

ingress2controller as a standalone command works well for static manifests, but not as well for helm based deployments. Especially when pipelines are involved.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten