"Legacy" Ingress Support

shaneutt commented 9 months ago

Problem Statement

The KGO is intended to be Gateway API first to configure ingress networking routes as well as managing the configuration and life.

While it would be more ideal to avoid support for the classic Ingress from an engineering and maintenance standpoint, we already have lots of established users that are using Ingress and don't have an impetus to transition to Gateway API yet.

So we need to "meet users where they are" to some degree here, and expect that there will be a demand for Ingress support for at least 2 more years (until Q1 2026, effectively) if not longer. The purpose of this issue is to decide on our overall strategy for this classic/legacy Ingress support, and then depending on what we decide spin off sub-tasks for it to act on that.

Proposed Solution

@mlavacca @pmalek @mflendrich @synthe102 and myself discussed this in the bi-weekly KGO sync at some length, and currently have two potential strategies.

Proposal 1 - D.I.Y. Documentation Only Approach

The KGO tried to go in an API design direction of layered APIs for composibility (e.g. DataPlanes and ControlPlanes are base level and Gateways and GatewayConfigurations are a composability layer on top). This actually works out pretty decently in that a user can already just use Ingress today if they're willing to manually create and manage a DataPlane and ControlPlane directly, to mimic what the helm chart may have previously done for them.

So effectively this proposal would be to just document how to "do it yourself" with the currently available APIs.

Pros:

low upfront development cost
possibly a bit easier for someone using helm to transition to?

Cons:

not seamless, some extra work
potentially slows the long-term (years) move away from Ingress, and might increase technical debt (e.g. we're locked in on ControlPlane/DataPlane in their current form for a lot of users)
potentially more support engagements, as this changes fundamentally how they deploy and manage their Gateways

Proposal 2 - Ingress Support Automation with Gateway API

This proposal is to effectively have IngressClass and Ingress automatically map to Gateway API resources, with the KGO managing that mapping, such as to support the separate APIs but in hopes of eventually unifying the machinery behind those APIs.

Pros:

a little more seamless for Ingress users
may reduce technical debt and maintenance burden by letting us remove old code (e.g. Ingress just converts to Gateway API, and then we use the unified Gateway API machinery)

Cons:

higher upfront development costs
potentially more support engagements, as they will have to learn GatewayConfiguration for modifications.

Additional Information

One unfortunate downside is that we don't really have a way to "meet them where they are" with Helm. They have to learn something new for the configuration management of their Gateways.

@mheap we particularly need your thoughts and considerations on the subject to make a decision about which proposal seems best to you (or if you have more proposals).

Acceptance Criteria

[ ] we provide a documented method by which classic Ingress users can use the KGO with Ingress
[ ] we provide some capable alternative for managing the configuration and lifecycle of Gateways (and KICs) over their current Helm methods

pmalek commented 9 months ago

Some more comments on proposal 2:

The down side is that users might be surprised that Gateway API resources would be created for them in a response to their Ingress/IngressClass objects.

The up side is: if they ever want to migrate (apart from using https://github.com/kubernetes-sigs/ingress2gateway) their migrated resources would already be in place (well somewhat but those could most certainly be used as a reference).

mlavacca commented 9 months ago

One unfortunate downside is that we don't really have a way to "meet them where they are" with Helm. They have to learn something new for the configuration management of their Gateways.

To help users using KGO, we could provide a tool to convert a values.yaml file to a manifest with Gateway + GatewayConfiguration objects.

This way the user can create the exact replica of what they already have deployed as a standalone KIC instance to a KGO managed gateway.

mheap commented 9 months ago

Strong preference for Proposal 1 from me. As a user I'd be confused if things started happening in response to IngressClass definitions existing.

We should optimise for moving people to Gateway API CRDs, step by step. That includes supporting a mixture of Ingress and Gateway API being processed by the same KIC instance (which is the case today)

Kong / gateway-operator