Build a Custom Scenario on Krkn

Implement the Plugin

Mon, 01 Jan 0001 00:00:00 +0000

Starting point: complete the workspace setup. Result: a concrete plugin class that Krkn can discover and execute.

Read the prepared behavior

Open $KRKN_DEV_PLUGIN_DIR/dev_demo_scenario_plugin.py. Its DevDemoScenarioPlugin class already implements execute_demo(scenario, lib_telemetry). The method:

Reads the YAML file identified by scenario.
Requires wait to be an integer from 0 to 60, and namespace to be a nonempty string. A YAML boolean is not accepted as an integer.
Sleeps for the requested duration.
Obtains the Kubernetes helper from lib_telemetry and checks namespace existence with list_namespaces().
Lists pods with list_pods(namespace) and logs a distinctive banner.
Returns 0 on success and 1 on a missing namespace or another failure.

The input file is intentionally small:

Package and Test the Image

Mon, 01 Jan 0001 00:00:00 +0000

Starting point: the plugin methods are implemented. Result: a locally tested image that clients can discover through its labels.

Build the custom Krkn base

Dockerfile.base overlays the local Python package on the published runtime:

FROM quay.io/krkn-chaos/krkn:latest

COPY --chown=krkn:krkn __init__.py \
 /home/krkn/kraken/krkn/scenario_plugins/dev_demo/__init__.py
COPY --chown=krkn:krkn dev_demo_scenario_plugin.py \
 /home/krkn/kraken/krkn/scenario_plugins/dev_demo/dev_demo_scenario_plugin.py

podman build \
 -f "$KRKN_DEV_PLUGIN_DIR/Dockerfile.base" \
 -t "$KRKN_BASE_IMAGE" \
 "$KRKN_DEV_PLUGIN_DIR"

Tip: Dockerfile path and build context are different

-f selects the Dockerfile; the final argument selects the directory available to its COPY instructions. -t assigns a local image name. Keeping both paths absolute makes this command work from any directory. Nothing is pushed to a registry at this stage.

This build context is the plugin repository. Using Krkn’s upstream container Dockerfile unchanged would clone Krkn from GitHub during the build and omit the local plugin. If you change the core engine or krkn-lib, build a runtime that includes those changes explicitly.

Publish and Run with Krkn Operator

Mon, 01 Jan 0001 00:00:00 +0000

Starting point: the scenario image passes its local tests. Result: the operator discovers the image, renders its two inputs, and runs it against a target you have already registered.

The management cluster hosts the registry, operator, and scenario Pods. The target’s kubeconfig is mounted into each scenario Pod. You do not need to place the private registry on the target or configure the target’s runtime to pull this scenario image.

One registry, two client configurations. Select the diagram to view it at full size.

Troubleshooting the Demo

Mon, 01 Jan 0001 00:00:00 +0000

First determine whether the scenario was discovered, whether its image was pulled, and whether its process started. These are separate checkpoints. Kubernetes events explain scheduling and pull failures; container logs explain startup and plugin failures.

The scenario is visible, but the pull attempts HTTPS

Typical event:

http: server gave HTTP response to HTTPS client

The operator’s registry client successfully used HTTP to list metadata. Kubelet then asked containerd to pull the image, and containerd defaulted to HTTPS. Krknctl’s insecure setting does not configure the node runtime.