Dependent resources determined at runtime?

[simon-geard]

A brief outline of a problem discussed in Discord — I'm building an operator to assist in porting a legacy application to Kubernetes. For the purposes of this conversation, the key features are a) one pod representing a centralised configuration server, and b) a set number of application pods determined entirely by the custom resource spec.

It's the latter part I'm asking about here. In all of the examples I've seen, the set of dependent resources is hardcoded, or at least, known in the reconciler constructor... one deployment, one service, one ingress, etc. This is not the case for me — the set of pods can only be determined by looking at an instance of the custom resource spec to see what's required. I'm also unable to use replica-sets for scaling, because even if two pods are otherwise identical, they need a unique identity registered in the config server.

Any advice?

(And yes, I know this is ugly architecture, but fixing it is a longer-term effort).

[metacosm]

Closing this as duplicate of #1182. Please re-open if you believe this is incorrect…

[csviri]

Ahh, sorry
I though this is a generic question not in context of dependent resources, that is why I told @simon-geard to create an issue. Yes in dependent resource it is yet to be supported. Will be in the next release. There are already samples on next, but the api and the implementation might change (probably will).

[simon-geard]

Ok, looking at the code changes in the linked issue, that's primarily aimed at build-your-own replica-set? A variable number of pods which are intended to be interchangeable, but which need to vary slightly, e.g. passing an identifier as an environment variable?

If so, that would probably be sufficient for my needs... it certainly addresses the primary issue, i.e. the inability to scale the application. Being able to dynamically define multiple groups — e.g 3 copies of pod A, 4 copies of pod B — would be handy, but it's not something I actually need... it's more about anticipating uses...

[csviri]

Ok, looking at the code changes in the linked issue, that's primarily aimed at build-your-own replica-set? A variable number of pods which are intended to be interchangeable, but which need to vary slightly,

The idea here is create a variable number of resources based on primary. any resource, even external, not Kubernetes scoped. If you need just pods, probably it is better to use replica set.

e.g. passing an identifier as an environment variable?

This use case is analogical, it's not based on primary, but still dynamic in sense, that it would need code changed (in terms of dependent resources to do ), so the bulk is the way to go here.

If so, that would probably be sufficient for my needs... it certainly addresses the primary issue, i.e. the inability to scale the application. Being able to dynamically define multiple groups — e.g 3 copies of pod A, 4 copies of pod B — would be handy, but it's not something I actually need... it's more about anticipating uses...

Each group would be in this case a separate bulk resource.

Note that this feature is not released yet, and might undergo API changes.

[simon-geard]

The idea here is create a variable number of resources based on primary. any resource, even external, not Kubernetes scoped. If you need just pods, probably it is better to use replica set.

I'd love to just use replica set — it would make things much easier. But the best way to describe my use case is that I have a pool of (e.g.) 5 slots registered in central configuration... so I can start up to 5 pods, and each one must be told which of the 5 slots it should use.

The bulk resources seem to be an ideal answer to this, going by how the ConfigMapDeleterBulkDependentResource example stores the index value on the config map it creates... I can do something similar to map the index to a slot name, and pass it to a pod.

Note that this feature is not released yet, and might undergo API changes.

Yes, that's fine... I'm still a long way off needing a production version of this, being very much at the research stage.

It also belatedly occurs to me that in the short term, I can probably fake it acceptably for testing. While the current SDK doesn't permit arbitrary scaling or dynamic creation of dependent resources, is there anything stopping me adding (e.g) 5 DR instances to the workflow, and using conditions to allow between 0 and 5 to be reconciled based on the primary resource spec?

Obviously it means there's a hard cap on scaling, but that's okay for now — we wouldn't want more than 2 'replicas' for development work, just the minimum for finding problems.