feat(api): add Konnect API group

[pmalek]

What this PR does / why we need it:

• move api/v1beta1 and api/v1alpha1 under api/gateway-operator/
• add api/konnect with v1alpha1 placeholder

Which issue this PR fixes

Part of #442

Special notes for your reviewer:

This is a breaking change in the Go API but not in YAML manifests as API group name does not change.

We do not treat the Go API currently as part of the user contract so we do not label this change as breaking.

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect significant changes

[randmonkey]

Looks like no go types for Konnect CRDs are defined in this PR but we have manifests for two CRDs. If we do not want include konnect CRDs in this PR, I think we should remove the manifests.

[mlavacca]

I thought we were going to add the new konnect CRDs in kubernetes-configuration rather than here. We agreed on putting off the migration of the existing CRDs to the new repo, but for what concerns the new CRDs, why are we splitting them up between here and kubernetes-config?

[pmalek]

I thought we were going to add the new konnect CRDs in kubernetes-configuration rather than here. We agreed on putting off the migration of the existing CRDs to the new repo, but for what concerns the new CRDs, why are we splitting them up between here and kubernetes-config?

There are 2 "types" of CRDs we're talking about here:

• Kong configuration CRDs which are already in https://github.com/Kong/kubernetes-configuration/tree/main/api/configuration (KongConsumer, KongConsumerGroup, KongPlugin etc) and those that might still end up there or are being actively worked on (KongService or KongRoute)
• Top level Konnect entity types like KonnectControlPlane. This is the type of CRDs that will land in the newly added API group.

The former make sense in both KGO and KIC context. The latter are only used by the operator and are only used in the Konnect context.

---

From what I understand @mlavacca, you're suggesting to introduce the latter also in https://github.com/Kong/kubernetes-configuration under konnect API group, leaving KGO API unchanged.

I'm wondering if there are any benefits to this approach. I'm curious about your thoughts on this. Given that we'd only use those CRDs in the operator I'm not sure there's much value in putting them outside of this repo. 🤔

[mlavacca]

I thought we were going to add the new konnect CRDs in kubernetes-configuration rather than here. We agreed on putting off the migration of the existing CRDs to the new repo, but for what concerns the new CRDs, why are we splitting them up between here and kubernetes-config?

There are 2 "types" of CRDs we're talking about here:

• Kong configuration CRDs which are already in https://github.com/Kong/kubernetes-configuration/tree/main/api/configuration (KongConsumer, KongConsumerGroup, KongPlugin etc) and those that might still end up there or are being actively worked on (KongService or KongRoute)
• Top level Konnect entity types like KonnectControlPlane. This is the type of CRDs that will land in the newly added API group.

The former make sense in both KGO and KIC context. The latter are only used by the operator and are only used in the Konnect context.

From what I understand @mlavacca, you're suggesting to introduce the latter also in https://github.com/Kong/kubernetes-configuration under konnect API group, leaving KGO API unchanged.

I'm wondering if there are any benefits to this approach. I'm curious about your thoughts on this. Given that we'd only use those CRDs in the operator I'm not sure there's much value in putting them outside of this repo. 🤔

My point is that since we are making the effort to group the CRDs in a unique place, it could make sense to treat this new place as where "Kong CRDs live". No matters if they are shared among KIC or KGO, or just used by KGO, I think that having a centralized place where our APIs live is a good approach, rather than having them scattered across multiple repositories.

Does it make sense to you?

[mlavacca]

One additional point to the discussion is there we will inevitably split the konnect CRDs between k8s-conf and kgo if we choose the approach of putting the KonnectControlPlanes here: the kubernetes configuration objects will need the konnectAPIAuthConfiguration API as it is used in their status, and to avoid circular dependencies we'll have to put such resources in the same repo. We'd end up having the Kong CRDs scattered across multiple repos, AND the same API group scattered across multiple repositories, which is something I think we really need to stay away from.

[pmalek]

One additional point to the discussion is there we will inevitably split the konnect CRDs between k8s-conf and kgo if we choose the approach of putting the KonnectControlPlanes here: the kubernetes configuration objects will need the konnectAPIAuthConfiguration API as it is used in their status, and to avoid circular dependencies we'll have to put such resources in the same repo. We'd end up having the Kong CRDs scattered across multiple repos, AND the same API group scattered across multiple repositories, which is something I think we really need to stay away from.

I was almost going to nod on this but then I realized that with the approach proposed by @czeslavo in the design doc (https://docs.google.com/document/d/1TxW2ovqPRm-w1td1e_V0CyaET4lpiEBCJ7hiYMZJqng/edit?disco=AAABS5JK2YM) we could drop the idea of having the KonnectAuthConfiguration reference in resources living within the CP because the latter would contain the auth config anyway. This way we don't need the KonnectAuthConfiguration type information.

Would you agree @mlavacca?

I guess at this point, it's a matter of where we'd prefer this CRDs to live. Let's discuss this on today's epic review.

[pmalek]

After a discussion with @mlavacca and @czeslavo we've decided that it will be better to place all new Konnect related types and CRDs into https://github.com/Kong/kubernetes-configuration.

With this, Kong/kubernetes-configuration#12 supersedes this PR.