Runtime Provisioner

This reference describes the Runtime Provisioner, the two jobs it does for Platform Manager, and the pages that document installing, configuring and upgrading it.

Type

Reference

Goal

Find the Runtime Provisioner page that covers the concept, procedure or setting you need.

Audience

Platform Operators and architects who run KSML applications or Kafka Connect log reading on an Axual installation.

When to use

Use this guide as the entry point to the Runtime Provisioner documentation.

Contents

The sections below cover each area of the component:

What the Runtime Provisioner does

The Runtime Provisioner is a REST service that Platform Manager calls to run workloads on Kubernetes on behalf of Self-Service users. It does two jobs: it deploys and manages KSML applications, and it reads the logs of Kafka Connect worker pods so Self-Service can show them.

One Provisioner serves many tenants. Each Instance that enables KSML points at a Provisioner by URL, so several Instances can share one deployment. Both jobs can run in the same Provisioner, or it can serve Kafka Connect logs only, with KSML provisioning switched off.

Up to version 0.7.0 the component was called the KSML Provisioner. Version 0.8.0 renamed it, along with its chart, image and Kubernetes resources, because it no longer serves KSML alone. See How to Upgrade the KSML Provisioner to Runtime Provisioner 0.8.0 for what the rename changes.

How KSML provisioning works

KSML explains what KSML is and how its parts fit together. The Provisioner’s share is the deployment.

When a user starts a KSML application in Self-Service, Platform Manager sends the request to the Provisioner configured for that Instance. The Provisioner pulls the KSML Helm chart from the configured OCI registry, generates a values.yaml from the requested configuration, and installs the chart into the Kubernetes cluster it runs in. Stopping the application reverses this.

Two constraints follow from that design:

  • The Provisioner deploys only into the Kubernetes cluster it runs in. A KSML application on another cluster needs a Provisioner of its own.

  • It pulls charts from OCI-compatible registries only, so a Nexus registry is not supported.

The Provisioner also has a Docker mode, which runs KSML applications as containers on the local Docker daemon instead of installing charts. The Runtime Provisioner 0.8.0 Readme describes it.

How Kafka Connect log reading works

Kafka Connect log reading, added in 0.8.0, lets Self-Service show the logs of a tenant’s Kafka Connect workers without giving the user access to Kubernetes. The Provisioner finds the worker pods in the namespaces it is configured to read and streams their logs back to Platform Manager.

Those namespaces are also the tenancy boundary. The chart grants read access only to the namespaces it lists, so the Provisioner can’t read anything outside them. Tenants that must not see each other’s logs need separate namespaces, or separate Provisioners. See How to Enable Kafka Connect Log Reading for the procedure.

Installation and operation

These pages cover the Provisioner from first install to upgrade, in the order an operator meets them:

Component details

The pages below document the Provisioner’s settings, chart and release history: