This is a cache of https://docs.openshift.com/container-platform/4.16/operators/olm_v1/arch/olmv1-rukpak.html. It is a snapshot of the page at 2024-11-25T09:52:38.584+0000.
RukPak - OLM 1.0 (Technology Preview) | Operators | OpenShift Container Platform 4.16
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

Rukpak (Technology Preview)

Operator Lifecycle Manager (OLM) 1.0 uses the RukPak component and its resources to manage cloud-native content.

OLM 1.0 is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

About RukPak

RukPak is a pluggable solution for packaging and distributing cloud-native content. It supports advanced strategies for installation, updates, and policy.

RukPak provides a content ecosystem for installing artifacts on a Kubernetes cluster. In OpenShift Container Platform 4.16, RukPak supports legacy Operator Lifecycle Manager (OLM) bundles as artifacts. RukPak can then manage, scale, and upgrade these artifacts in a safe way to enable powerful cluster extensions.

RukPak, a Technology Preview component, does not support FIPS. In OpenShift Container Platform 4.16, Operator Lifecycle Manager (OLM) 1.0 depends on RukPak. As a result, RukPak and OLM 1.0 do not run on clusters with FIPS mode enabled.

At its core, RukPak is a set of controllers and the Bundledeployment API. The API is packaged as a custom resource definition (CRD) that expresses what content to install on a cluster and how to create a running deployment of the content. The controllers watch for the API.

Common terminology
Bundle

A collection of Kubernetes manifests that define content to be deployed to a cluster

Bundle image

A container image that contains a bundle within its filesystem

Bundle Git repository

A Git repository that contains a bundle within a directory

Provisioner

Controllers that install and manage content on a Kubernetes cluster

Bundle deployment

Generates deployed instances of a bundle

About provisioners

RukPak consists of a series of controllers, known as provisioners, that install and manage content on a Kubernetes cluster. A provisioner works together with a Bundledeployment object to bring content onto the cluster and install it, generating resources within the cluster.

Currently, the registry provisioner is implemented and included with RukPak. A registry bundle, or registry+v1 bundle, contains a set of static Kubernetes YAML manifests organized in the legacy Operator Lifecycle Manager (OLM) bundle format. The registry provisioner sources and unpacks registry bundles.

A provisioner is assigned a unique ID and is responsible for reconciling bundles and Bundledeployment objects with a spec.provisionerClassName field that matches that particular ID. For example, the registry provisioner is able to unpack a given registry+v1 bundle onto a cluster and then instantiate it, making the content of the bundle available in the cluster.

A provisioner places a watch on Bundledeployment resources that refer to the provisioner explicitly. For a given bundle, the provisioner unpacks the contents of the bundle onto the cluster. Then, given a Bundledeployment resource referring to that bundle, the provisioner installs the bundle contents and is responsible for managing the lifecycle of those resources.

Additional resources

Bundledeployment

In OpenShift Container Platform 4.16, the RukPak Bundledeployment indicates when a bundle should be active. This includes pivoting from older versions of an active bundle.

A Bundledeployment object changes the state of a Kubernetes cluster by installing and removing objects. It is important to verify and trust the content that is being installed and limit access, by using RBAC, to the Bundledeployment API to only those who require those permissions.

Much like pods generate instances of container images, a bundle deployment generates a deployed version of a bundle. A bundle deployment can be seen as a generalization of the pod concept.

The specifics of how a bundle deployment makes changes to a cluster based on a referenced bundle is defined by the provisioner that is configured to watch that bundle deployment.