RenkuLab deployments are complex to manage, they require administrators to manage multiple services as Postgres, Keycloak and Gitlab on top of Renkulab itself. At the moment, to give users access to another set of compute resources, we have to deploy an entire new Renku instance with all of these services.
We want to be able to provide additional, elastic resources provisioned from potentially other cloud providers from a central instance, with a minimal set of services required in the “satellite” resource.
As the Renkulab.io admin I want to give access to the users of the platform to different compute resources to run their sessions on.
Some of the resources might be located in different data centers, geographical regions. clusters or cloud provider with respect to where the Renku core services are running.
We can assume that Kubernetes is managing the remote clusters, thus we need an agent that we (the Renkulab.io admins) can install and manage on the remote clusters, that can connect to Renkulab.io and expose the resources on that cluster.
We can also assume that we are the owners of all the connected clusters.
(3 weeks for an exploration, not shipping code)
(6 weeks for production code)
The main cluster has a Kubeconfig file that allows it to access the remote cluster that maps to a specific service account with only the required permissions.
When resource pools are created in the admin panel of Renkulab, an optional field for which cluster the resource pool belongs too should also be added. When a user session is launched within a resource pool that belongs to an external cluster, Amalthea will know to use the Kubeconfig that belongs to that cluster to setup the connection.
The external cluster must be able to provide: