Start here
A guide to Runtime Conditions Profiles.
Runtime Conditions Profiles describe the external runtime integrations one workload requires. This guide starts with examples, then walks into the spec, generator, extensions, adapter, and demo.
The short version
- 1Source code uses integrations.The demo app calls an HTTP API, Redis, and S3.
- 2A generator emits a profile.The profile names requirements and environment variable names, not target values.
- 3An adapter fulfills the profile.The Kratix demo maps Conditions to Redis, S3, Secrets, ConfigMaps, and Cilium policies.
Example first
A complete profile document
Where this comes from
apiVersion: runtimeconditions.io/v1alpha1
kind: RuntimeConditionsProfile
metadata:
name: request-logger-http
workload:
uri: github.com/example/request-logger-http
version: v0.1.0
extensions:
- https://runtimeconditions.io/extensions/common-integrations:v1alpha1
- https://runtimeconditions.io/extensions/env-configuration:v1alpha1
conditions:
- name: todos-api
kind: api
interface:
type: http
spec:
format: openapi
uri: catalog://api/default/todos-api
version: 1.0.0
operations:
- method: GET
path: /todos/{id}
configuration:
env:
- property: baseUrl
name: TODOS_API_URL
- name: request-cache
kind: cache
interface:
type: key_value
engine: redis
configuration:
alternatives:
- env:
- property: url
name: REDIS_URL
- env:
- property: hostname
name: REDIS_HOST
- property: port
name: REDIS_PORT
The profile names the workload, declares the extensions needed to interpret its vocabulary, and lists runtime Conditions. It does not contain service URLs, Redis hostnames, credentials, or target-environment choices.
Read in order
First half: what the profile is
Read chapters 1-4 to understand Conditions, profile shape, generator output, and extension vocabulary.
Second half: how it gets used
Read chapters 5-7 to understand platform adapters, the working Kratix demo, and where each source file lives.