How to reconcile a global application based on all crd instances (similar to a ingress controller)

[0xxFF]

I’m working on a controller that needs to reconcile a single global service based on all instances of a custom resource, not just one at a time. The design is conceptually similar to an Ingress controller:

• An Ingress controller looks at all Ingress resources in the cluster.
• It then computes a desired global state (e.g., a load balancer config, a reverse proxy config, etc.).
• Finally, it applies changes based on the aggregate of all CRD instances, not a single one.

Even though I’m not writing an actual ingress controller, the reconciliation pattern is very close to that.

Would JOSDK be suitable for implementing a controller that works in this global/aggregated reconciliation style?
Or is JOSDK more focused on one-resource-at-a-time reconciliation (typical operator pattern), meaning I’d have to build a lot of aggregation logic outside of it?
For example, it always expects a primary resource, but if I make the Ingress that primary resource, it will reconcile every Ingress individually.

Ideally, my controller would also manage the Ingress deployment itself, so users just have to install my controller and are ready to go.
One issue that comes to mind is, for example, if my Ingress deployment consists of 1 Deployment and 2 Services. Now, if I update my operator and it only requires 1 Deployment and 1 Service, is there a way to automatically "garbage collect" the extra Service?

[csviri]

Would JOSDK be suitable for implementing a controller that works in this global/aggregated reconciliation style?

yes, you can implement a controller where the primary resource is not the Ingress, but just a custom resource for which you might just have one instance (or a very limited number with different spec, to test some features / configurations). And would watch all the Ingress resources with an InformerEventSource on the cluster, so the reconciliation would be triggered also by any change on those ingresses.

Or is JOSDK more focused on one-resource-at-a-time reconciliation (typical operator pattern), meaning I’d have to build a lot of aggregation logic outside of it?

Not, especially the low level API is absoutely generic.

Ideally, my controller would also manage the Ingress deployment itself, so users just have to install my controller and are ready to go.

you can have multiple controllers registered as seen some of the samples

One issue that comes to mind is, for example, if my Ingress deployment consists of 1 Deployment and 2 Services. Now, if I update my operator and it only requires 1 Deployment and 1 Service, is there a way to automatically "garbage collect" the extra Service?

No, you have to implement it yourself, but that should be almost trivial.
There is an issue to support this for dependent resources/workflows but not implemented yet, and not planned for close future:
#2267

[0xxFF]

Hi, thanks for your reply.
Regarding the low-level API, do you mean the Fabric8 API, or is there a lower-level API within JOSDK?
Also, is it possible to have a "singleton" primary resource that isn’t actually installed as a CRD inside the Kubernetes cluster?

[csviri]

I mean JOSDK "low level", maybe base level api or some other name would be nicer. Basically without dependent resources.

It is possible to watch resources, either custom resources or k8s built in resources. But there has to be a primary Kubernetes resource.

[0xxFF]

Thank you for the clarification. Its not exactly the answer I was hoping for, but it answers my question.
I will close the issue.