Profiles

Profiles are named presets that expand into fully-formed configuration at Katalog load time. The runtime never sees a profile name — by the time a Deployment is created, the profile has already been replaced by concrete values.

deployments:
  - name: "{{ .metadata.name }}"
    image: "{{ .spec.image }}"
    resources:
      profile: medium       # cpu:250m/1, memory:256Mi/1Gi
    securityContext:
      profile: restricted   # allowPrivilegeEscalation:false, runAsNonRoot:true, drop:ALL
    probes:
      liveness:
        type: http
        path: /healthz
        profile: standard   # initialDelay:15s, period:20s, failureThreshold:3

Three lines. No resource arithmetic. No security context boilerplate. No probe timing lookup.

The five profile kinds

Resource profiles

resources.profile on any Deployment, StatefulSet, Job, or CronJob.

Named presets for CPU and memory requests/limits. Pick the shape that matches your workload; skip the capacity planning for individual fields.

Try it:

ork init --pack use-cases
cd profiles/01-resource
ork run
kubectl apply -f ../cr.yaml

Security profiles

securityContext.profile (container) and podSecurity.profile (pod).

Named presets for Kubernetes security contexts. restricted matches the Kubernetes restricted Pod Security Standard. hardened adds a read-only root filesystem and runs as a non-root, non-privileged user.

Try it:

cd profiles/02-security
ork run
kubectl apply -f ../cr.yaml

Probe profiles

probes.liveness.profile, probes.readiness.profile, probes.startup.profile.

Named timing presets for Kubernetes probes. slow-start is designed specifically for startup probes on JVM apps and databases — 30 failures × 10s period = 5-minute startup window before Kubernetes gives up.

Try it:

cd profiles/03-probes
ork run
kubectl apply -f ../cr.yaml

Rolling update profiles

rollingUpdate.profile on any Deployment.

Named presets for maxSurge and maxUnavailable. safe ensures zero capacity drop during rollouts. blue-green doubles capacity temporarily for the cleanest cutover.

Try it:

cd profiles/04-rolling-update
ork run
kubectl apply -f ../cr.yaml
# Then trigger a rollout:
kubectl patch service my-service --type=merge -p '{"spec":{"image":"nginx:1.26"}}'

PDB profiles

pdb.behavior.profile on any PodDisruptionBudget.

Named presets for voluntary disruption limits. zero-downtime prevents any pod from being evicted. rolling allows exactly one at a time. relaxed allows 25%.

Try it:

cd profiles/05-pdb
ork run
kubectl apply -f ../cr.yaml

Autoscale profiles

autoscale.profile on a CRD entry.

Named presets for Orkestra’s declarative autoscaler — expands into trigger thresholds, scale-up/down policies, intervals, and cooldowns. The autoscale profile is distinct from the others: it configures the operatorBox runtime, not child Kubernetes resources.

Try it:

ork init --pack advanced
cd 12-autoscale
ork run

Profiles vs explicit fields

Profiles and explicit field declarations are mutually exclusive — you can use one or the other, not both on the same resource.

# Profile — one word, expands to full config
resources:
  profile: medium

# Explicit — full control, no expansion
resources:
  requests:
    cpu: "250m"
    memory: "256Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

Use profiles when the preset matches your workload. Use explicit fields when you need values the presets don’t cover.

Try it

ork init --pack use-cases
cd profiles

Next → Reconcile Pipeline