WIP: Add iterators to resourceGraphDefinition to allow dynamic creation of multiple similar resources

[VladRico]

Hi there !
Here's a "for loop" implementation related to #17
tested on kubernetes v1.31.2

Overview

it adds a iterators to the schema:

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: loop
spec:
  schema:
    apiVersion: v1alpha1
    kind: Loop
    spec:
      name: "string | required=true"
      hostIP: "string | required=true"
      # Use custom type 
      ports: "[]port | required=true"
    # Define port type
    types:
      port:
        name: string | required
        protocol: string | default="TCP"
        port: integer | required
    # new iterators feature
    iterators:
      - name: deploymentContainerPorts
        iterator: item
        input: schema.spec.ports
        render:
          - containerPort: ${item.port}
            name: ${item.name}
            protocol: ${item.protocol}
            hostIP: ${schema.spec.hostIP}

  resources:
    - id: deployment
      template:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: ${schema.spec.name}
        spec:
          replicas: 1
          selector:
            matchLabels:
              type: ${schema.spec.name}-feature
          template:
            metadata:
              labels:
                type: ${schema.spec.name}-feature
            spec:
              containers:
                - name: dev
                  image: nginx
                  ports:
                    ${iterators.deploymentContainerPorts}
---

Used with an instance like:

apiVersion: kro.run/v1alpha1
kind: Loop
metadata:
  name: loop-example
spec:
  name: dev-loop
  hostIP: "10.13.37.1"
  ports:
    - name: http
      protocol: TCP
      port: 8080
    - name: https
      protocol: TCP
      port: 443

It produces this result:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dev-loop
spec:
  replicas: 1
  selector:
    matchLabels:
      type: dev-loop-feature
  template:
    metadata:
      labels:
        type: dev-loop-feature
    spec:
      containers:
        - name: dev
          image: nginx
          ports:
            - containerPort: 8080
              name: http
              protocol: TCP
              hostIP: "10.13.37.1"
            - containerPort: 443
              name: https
              protocol: TCP
              hostIP: "10.13.37.1"

You can find in examples/iterators/* the 3 files used above.
As it is just an implementation idea, I haven't checked whether this opens any security flaws. I'm thinking about various injection from the instance, something like that for example, even if it's not really the same thing.

Notes

As this is a fairly complex feature, because it can be implemented in so many different ways, I'm not really sure that it matches what maintainers have in mind.

I have a real need for this kind of feature, that's why I tried to meet requirements based on what peoples said in #17
Feel free to suggest changes if you like the implementation, or close it if it's too far away from what you have in mind

Thanks for you time working on this project !

[handicraftsman]

Feature wise looks interesting (haven't checked the code), but it is missing an important piece: what if I want to request e.g. several instances of Postgres, where each of them is created by instantiating a custom resource? (like in zalando operator)

As a note, I am not checking the code here, because I am both not a part of kro community and I am not a Go developer.

[VladRico]

@handicraftsman I'm sorry but I didn't fully understand your point. Could you please provide an example of the result wanted ?

[handicraftsman]

Basically, I would love to have an iterator expand into multiple items in resources array.
For example, I might want to have multiple Services created, with different policies applied to each of them.

For example, one Service would be accessible from the Internet, whereas the other service would only be reachable through a VPN, and used for management purposes.

Since I mentioned management purposes, here's an example: in Java there's JMX, which allows connecting to a Java app remotely, and issuing one or more commands there. I know there are better ways to do so, but this is just a theoretical example.

Or, for example, we are working with a similar case in production, but instead of exposing JMX API, our services expose a separate API for managing the system through an internal console. This also allows resolving support cases for us, allowing for manual administrative actions that are only available under VPN.

[VladRico]

Sorry for the late answer. Ok I may have understand your requirement @handicraftsman and I also have this needs. I'll try to implement the feature but I can't promise anything

[matthchr]

There are multiple efforts in flight on this topic, and I think the consensus is that we should have a design first before we land on an implementation. @a-hilaly is leading that effort - can you engage with him and work together?

Marking this donotmerge in the meantime.

[k8s-triage-robot]

Unknown CLA label state. Rechecking for CLA labels.

Send feedback to sig-contributor-experience at kubernetes/community.

/check-cla
/easycla

[linux-foundation-easycla]

• ❌ - login: @VladRico / name: Vlad Rico . The commit (3d4f9ba, 01cc902, 3c8372b, 3f82e8e) is not authorized under a signed CLA. Please click here to be authorized. For further assistance with EasyCLA, please submit a support request ticket.

[k8s-ci-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[a-hilaly]

Hey @VladRico ! Thank you so much for taking a stab on this, i'm currently in the process of writing a design doc on collections (or iterators as you're calling it :) ) - and would love to get your feedback/comments on it. Happy to collaborate with you to get this one out!

/close

[k8s-ci-robot]

@a-hilaly: Closed this PR.

In response to this:

Hey @VladRico ! Thank you so much for taking a stab on this, i'm currently in the process of writing a design doc on collections (or iterators as you're calling it :) ) - and would love to get your feedback/comments on it. Happy to collaborate with you to get this one out!

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[VladRico]

Hey @a-hilaly !
Feel free to ping me when you release the design doc on collections. I'm not sure my feedback is worth something as I'm not actually a skilled dev ^^'
I'll be very busy the next month but I may have some free time near the end of October

[a-hilaly]

@VladRico I recently opened #679 your feedback would be highly valuable! let's incorporate any ideas you had in mind. I'm also planning on having an implementation plan, and you're welcome to pick a workstream if you're interrested!