RStudio Server Pro & Connect on Kubernetes

R Admins
, ,
#1

Hello all.
I am attempting to get RStudio Server Pro and Connect running on a Kubernetes cluster, as opposed to dedicated servers. I have not been able to find a shred of documentation about this setup, though I was told by an engineer that there are some customers doing it.

Is anyone else running the RStudio Team suite of products on K8s? If so, I would love to hear about your setup.

#2

This is a fantastic question, and I am excited to see how others weigh in! Typically where we advise customers to start is with docker and containerizing the products themselves.

We have guidance on running RStudio Connect in a docker container in our documentation here: https://docs.rstudio.com/connect/admin/server-management.html#server-docker

Further, we have documentation on using RStudio Server Pro with the Kubernetes Job Launcher here: https://docs.rstudio.com/rsp/integration/launcher-kubernetes/

Finally, we have example docker containers with the three products here: https://hub.docker.com/u/rstudio

(Backed by this repository) https://github.com/rstudio/rstudio-docker-products

While we do not publish example kubernetes resources that you can use to automatically deploy these assets, most of these questions will come down to how you manage infrastructure in Kubernetes. Generally, we only recommend taking on this approach if you are familiar with running infrastructure in Kubernetes. Otherwise, the complexities of running and maintaining Kubernetes makes it harder to be successful with our professional products.If you are comfortable with deploying infrastructure to Kubernetes, there are a few thoughts I would keep in mind:

  • Each product needs a privileged container (we discuss this on the rstudio-docker-products repository)
  • You would probably lean towards a service for each product
  • Containers for RStudio Connect should be expected to be long-lived and persistent - each container will house many pieces of content and likely many users.
  • Persistent storage is very important here, especially in a HA cluster. While RStudio Package Manager can use persistent storage on AWS S3, for instance, the other products require NFS. AWS EFS has shown itself to have performance/speed problems with application-based workloads and is not generally recommended for this type of infrastructure. Your mileage may vary.
  • Similarly, RStudio Package Manager and RStudio Connect require a database - we would recommend using a persistent database outside of Kubernetes.

Much of how this is done will depend on your own practices for managing and maintaining infrastructure inside of Kubernetes.

#5

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

#4

That sounds great! Definitely let us know how it goes! Hopefully that docker image at https://github.com/rstudio/rstudio-docker-products will be a good starting point!

You could use a preStop lifecycle hook, I suppose! I have never used those before! The way we did it in the example container is by trapping the "EXIT" signal. This will fire in many cases, but can miss others (i.e. SIGKILL).

It is worth noting that there are a few approaches to licensing that we talk through in that guide:

  • The standard activation process there that you are discussing
  • A "floating license" process where licensing happens through leases from a persistent server
  • For enterprise customers, we have a third licensing approach that can be helpful in some ephemeral environments as well.

All three will work inside of Kubernetes, and which you pick will again depend on your architectural and licensing goals :smile:

#3

Thanks for the input, Cole. At the moment, I am only trying to get Server Pro up and running, but was wondering if Connect and Package Manager belonged in the same pod or in separate deployments/services. Per your recommendation, I will pursue separate services.
Regarding licensing, on the Docker Hub page, there is a note about deactivating licenses before stopping the container(s). Am I correct in thinking that I'll need to add a preStop lifecycle hook for this deactivation to the pods that I'm deploying?