KongIngress go-kong schema dependency results in superfluous CRD fields

[mflendrich]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Usage of go-kong fields in KongIngress:

kubernetes-ingress-controller/pkg/apis/configuration/v1/kongingress_types.go

Lines 35 to 37 in 11df628

	Upstream *kong.Upstream `json:"upstream,omitempty"`
	Proxy *kong.Service `json:"proxy,omitempty"`
	Route *kong.Route `json:"route,omitempty"`

causes presence of superfluous fields that weren't there in the KIC 1.3 CRD and will at least cause confusion, if not conflicts.

Expected Behavior

Schema of KongIngress identical to that of 1.3, except for deliberately added fields

Steps To Reproduce

Observe that the KIC 2.0 KongIngress CRD has the `proxy.ca_certificates` field and the 1.3 KongIngress CRD does not.

This applies to more fields, the above is just an example.

Kong Ingress Controller version

No response

Kubernetes version

No response

Anything else?

No response

[mflendrich]

The exact difference between 1.3 and 2.0 CRDs (with 1.3 CRDs converted from v1beta1 CRD to v1 storage format for readability) is here: https://gist.github.com/mflendrich/c11ef531ba8bd53fcf45306de81cc3ca

[rainest]

If we wish to keep the current object design, where KongIngress is just a container for the underlying go-kong types, it doesn't appear there's any way to prune these--I don't see anything in the Kubebuilder annotations that can mark a field to omit from the CRD. To make the generated CRD match the handwritten CRD, we'd need to add new types that we convert into go-kong types, which would probably require a decent amount of new work and refactoring how KongIngress is applied.

The way we use KongIngress in code is a bit split. It's ostensibly a catch-all for any field we haven't provided a dedicated configuration path for, but that's only really true for upstreams, where we literally just dump the object in wholesale. For this approach, including all the fields is arguably correct, since you can in fact, for example, set created_at in your upstream section and it will show up in the generated config.

Route and service, by comparison, pull specific fields from the KongIngress and may even implement validation (which should arguably exist at the CRD level instead). This split has been a source of confusion already.

Given that we have de-facto separate types because of how routes and services actually work, I think formalizing that with actual separate KongIngressRoute, KongIngressService, and KongIngressUpstream types unless we want to make them actually track the go-kong types (i.e. we make everything like upstream and just dump everything direct into the object). The latter strategy does allow for validation if we're okay adding Kubebuilder tags inside go-kong. It does also lets you freely set fields that we might not expect you to, but I don't see a reason you shouldn't be able to set created_at if you really want to.

For now, given the work involved to do this properly, I think we copy the schema in from the existing CRD somehow. Hopefully kustomize supports patching that.