Architecture Overview
Local execution
Posit Connect has traditionally executed Python, R, and other content types using local processes running on the same Linux host as the Connect server process.
This style of deployment can happen with bare-metal servers, with virtual machines, or inside a container. Connect can be deployed within Kubernetes using this model, but all of its managed processes occur within the same container.
Off-host execution
Connect can use Kubernetes to execute Python, R, and other content types. These jobs are external to the server or container that is running Connect.
In this scenario, Connect launches a job to service requests for a Shiny application. That job uses an image appropriate for that content. For our Shiny example, Connect identifies an image that contains a version of R that is compatible with the version used during development. When the job is launched, the container is augmented with a handful of required runtime components using a separate, auxiliary init-container. The use of an init-container to prepare the runtime components means that the content image does not need to be rebuilt for a particular version of Connect. For more details about the init-container, see the Runtime Init-Container section below.
Using an approach very similar to process sandboxing, Connect instructs Kubernetes to mount storage locations into the containers that run your content. These directories contain the variable data associated with your content, such as the Python and R packages, the source code for your content, and directories for rendering output. These locations are normally mounted using NFS, but can also use host mounts. This approach lets you use smaller content images and share execution environments across multiple content items.
Containerized operation
When Connect is running in off-host execution mode, the change is transparent to users. They continue to deploy, view, and interact with content the same as before. However, when Connect launches a process to prepare a build environment (installing Python and R packages), render a document, or run an interactive application, it uses a Kubernetes container instead of a local process.
Connect automatically selects a compatible execution environment from the available set of environments. See Content Execution Environments to learn about the selection process and how content execution environments are defined.
Connect respects Runtime settings as usual, but each process runs in a separate container. For example, an application with Max processes set to 3 might result in up to 3 separate Kubernetes Jobs, each running one content process. Process logs are available in the Connect dashboard as usual.
The Processes table on the Metrics pane in the Admin section of the Connect dashboard shows processes running across the cluster. However, the other charts (CPU, RAM, etc.) only report resource usage for the Connect server you are connected to.
Job launcher
Connect bundles a specific version of the Posit Job Launcher with each Connect release. Connect fully manages the lifecycle of the Launcher process. The necessary Launcher configuration files are generated by Connect at runtime.
Because Connect generates the Launcher configurations at runtime, some Launcher configurations are not exposed as Connect settings and the corresponding Launcher configuration cannot be overridden.
The following table illustrates the default values for the various Connect and Launcher configurations that have potential for conflict. When modifying any of the these settings, care must be taken to make sure that there is no conflict with another instance of the Launcher (including other instances of Connect with Launcher enabled).
| Connect config key | Connect default | Launcher default | Launcher config file | Launcher config key |
|---|---|---|---|---|
Launcher.ConfigDir |
/etc/rstudio-connect/launcher |
/etc/rstudio |
N/A | N/A |
Launcher.ScratchPath |
/var/lib/rstudio-connect-launcher |
/var/lib/rstudio-launcher |
launcher.conf |
scratch-path |
| N/A | ${Launcher.ScratchPath}/Kubernetes |
/var/lib/rstudio-launcher/Kubernetes |
launcher.kubernetes.conf |
scratch-path |
Launcher.KubernetesNamespace |
rstudio-connect |
rstudio |
launcher.kubernetes.conf |
kubernetes-namespace |
Launcher.KubernetesProfilesConfig |
${Launcher.ConfigDir}/launcher.kubernetes.profiles.conf |
/etc/rstudio/launcher.kubernetes.profiles.conf |
launcher.kubernetes.conf |
profile-config |
Runtime init-container
To make the maintenance of content images as seamless as possible for our users, Posit Connect utilizes an init-container when running content on Kubernetes. The purpose of this initialization is to copy the runtime artifacts required by Connect into your container just before your content starts to execute. This means that the image being used to execute your content does not need to contain any Connect components, and therefore it does not need to be rebuilt after an Connect upgrade.
Posit maintains an init-container image which is 1:1 with the Connect version. When a content execution Pod is created in Kubernetes, Connect also creates an EmptyDir volume (rsc-volume in the image below). This empty directory is used as a staging area for our runtime components. The init-container is then responsible for copying the runtime artifacts into the staging area so that they are also available to the content container.
