Kelly O’Briant
Products and Technology

Posit Connect 2023.05.0: Easily deploy R and Python content in Kubernetes

2023-06-08
Text: Product Release, Posit Connect 2023.05.0, Easily deploy R and Python content in Kubernetes. The Posit Connect logo is underneath.

Off-Host Content Execution with Kubernetes

Posit Connect now supports off-host execution on Kubernetes. This allows organizations to host applications, models, reports, and other data products with advanced process isolation and resource utilization controls. Publishers do not need to change how they deploy and manage content on Connect. This execution mode is best suited for teams that are already heavily invested in using Kubernetes and who have a motivating use case for content-level containerization. Please note that this feature requires an Enterprise license for Posit Connect.

Jump to the new features:

What is off-host execution?

Many organizations already run Posit Connect in a container without the help of off-host execution. In this scenario, Connect is placed in a long-running container and managed as it would be in a more traditional server-based environment. This accomplishes product-level containerization, but it does not achieve content-level containerization, meaning all of the data science content (applications, dashboards, documents, APIs) utilizes local processes running on the same host as the Connect server process.  

A diagram showing the differences between local content execution with product-level containerization, and off-host content execution with content-level containerization.

Content-level containerization in Connect requires off-host execution. In this new configuration, when Connect launches a process to prepare a build environment, render a document, or run an interactive application, it uses a Kubernetes container instead of a local process. These jobs are external to the container that is running Connect. Connect respects content Runtime settings, 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. Perhaps most notably, Connect does all of this without requiring Publishers to change how they deploy and manage content. Connect still supports all of the simple publishing workflows you use today: push-button, git-backed, CLI-driven, and scripted/API-driven.

 

Why would you want this? 

The decision to leverage container-based infrastructure has the potential to ease the management of resource constraints and server costs, maximize process isolation, and simplify the maintenance of R and Python environments and system dependencies. Many organizations can also experience an overall increase in administrative burden when moving to Kubernetes due to added overhead and complexity, so it’s important to have a strong reason for switching architectures.

From our perspective, local content execution is still a great option for most organizations. Off-host content execution enables containerization at the content level and opens the door to a number of interesting customization possibilities. If you view any of these new features as game-changers, off-host execution for Connect on Kubernetes is worth evaluating.

We always recommend meeting with the Posit Solutions Engineering team before making a big architecture and infrastructure change. If you’re an existing customer, reach out to your Customer Success representative to set up one of these calls. If you’re just evaluating our products, email us at sales@posit.co and someone can assist you.

 

Content-Level Execution Environments

In designing off-host execution, our goal was to keep the Connect Publisher experience as simple as possible. Publishers don’t need to learn how to build and manage containers, maintain Dockerfiles, or change how they deploy content to Connect today. By default, the most appropriate execution environment for your content is selected automatically by Connect, using the configurable version matching rules and the set of images made available by an administrator. Advanced Publishers can target a specific image for their deployments or change the default execution environment after content is deployed.

Execution environments can be shared across content items. When content is first deployed, Connect uses an image to create a build container to install R and Python packages required by your content. Subsequently, each time your content needs to run, that same image is used to create a container for content execution.

See a more detailed version of the architecture described here.

This image can be selected in three ways:

  1. A manifest can specify an image by setting the environment.image field. 
  2. Choose a default image in the Connect dashboard (shown below).
  3. Let Connect determine which execution environment is most appropriate for your content via a version-matching algorithm.


Set a default execution environment window

Specify the execution environment for a content item in the Access settings pane.


Administrators can create, update, or remove execution environments used by Publishers and Connect. It’s easy to get started by using the set of basic images (Ubuntu 22.04 LTS) created by Posit, but you can also create and use your own custom images.


Edit environment box in Connect

Administrators can find these tools in the new Environments dashboard tab after upgrading.


Learn more about Content Execution Environments in the Posit Connect Admin Guide.

 

Content-Level Kubernetes Service Account Management

Kubernetes service accounts provide identity for Kubernetes workloads and facilitate fine-grained access control against the Kubernetes API or other external resources. Many organizations use service accounts to restrict or facilitate access to data sources that get used in content published to Connect. If multiple teams within your organization are publishing in the same Connect environment, configuring service accounts for each group can be a useful data governance mechanism. 

For example, a Kubernetes configuration can restrict access to a particular S3 bucket by service account. To successfully access this bucket, a content job launched by Connect will require an identity that is configured with permissions to access that S3 bucket. Kubernetes service accounts are the mechanism that provides this type of workflow identity.

Starting with this release, Posit Connect supports the configuration of service accounts at the content level. This means that a service account can be set for a particular piece of content that overrides any globally-defined service account.

Connect administrators can set content-level service accounts through the dashboard or the content API. Connect publishers can view the configured service account for a particular piece of content, but cannot modify it.

Learn more about Kubernetes Service Accounts in the Posit Connect Admin Guide and the Posit Connect User Guide.

 

Content-Level CPU & RAM Configuration

One of the most common features our beta testers asked for was the ability to set resource requests and limits with content-level granularity. Administrators in particular wanted to be able to configure the expected minimum and maximum resource usage that individual content processes need so they can be efficiently scheduled to nodes. 

This edition of Connect includes new Runtime/Scheduler configuration options for setting global defaults and upper limits on content-level values:

  • MemoryRequest, MemoryLimit, MaxMemoryRequest, MaxMemoryLimit
  • CPURequest, CPULimit, MaxCPURequest, MaxCPULimit

as well as content-level settings that can be managed by both Publishers and Administrators in the Connect dashboard or via the Server API:

  • Initial Number of CPUs Number of CPU units requested for your process. This indicates the minimum amount of CPU your content needs to render or execute, and is used by Kubernetes to determine which node should run your content. Fractional values are allowed. 0 indicates that no request should be made.
  • Max Number of CPUs Limits the number of CPU units your process is allowed to use. Fractional values are allowed. 0 indicates no limit (this may be disabled by your administrator). Processes that use more CPU than allowed are throttled.
  • Initial RAM Requested Amount of RAM (in GiB) requested for your process. This indicates the minimum amount of RAM your content needs to render or execute, and is used by Kubernetes to determine which node should run your content. 0 indicates that no request should be made.
  • Max RAM Limits the amount of RAM (in GiB) your process is allowed to use. 0 indicates no limit (this can be disabled by your administrator). Processes that use more RAM than allowed are terminated.

We recommend configuring memory and CPU limits only after observing the typical usage patterns of content on your server. When a process is terminated due to exceeding the allowed RAM, it is terminated by the operating system, and the error message will depend on the specific OS, language, packages, and user code involved. Therefore, it is not possible to give a list of possible error codes, or for Posit Connect to detect that this is the reason for termination. If you are unfamiliar with how Kubernetes uses requests and limits, we recommend starting with this resource: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/.

Learn more about CPU & RAM Configurations in the Posit Connect User Guide.

 

Getting Started

The requirements for off-host execution on Connect are: 

Posit Connect’s documentation and installation guide for off-host execution can be found here. If you’re interested in learning more about Posit Connect with off-host execution, the best way to get started is to have an architecture review call with our Solutions Engineering team. Reach out to your Customer Success Representative or contact us at sales@posit.co to get in touch.

Tags: kubernetes Posit Connect