Skip to content

quickstart-direct.md

Latest commit

 

History

History
79 lines (60 loc) · 2.84 KB

quickstart-direct.md

File metadata and controls

79 lines (60 loc) · 2.84 KB
Raw

Direct Apply Quickstart

This quickstart uses the direct public-preview profile. Kapro generates raw Kubernetes YAML plus a kubernetes-apply SubstrateClass, typed KubernetesApplyConfig, and Substrate. No OCI registry, Flux install, or Argo CD install is required for the generated repo shape.

The built-in direct runtime updates the generated Deployment image through the Kubernetes API. It is intentionally narrow for 0.6.0: bootstrap applies the initial raw manifests, and Kapro owns promotion-time image changes and convergence observation.

Workload Constraints

The direct profile is deliberately boring in the first public preview. It supports generated Deployment workloads by patching the image on a named container and waiting for updated, ready, and available replicas. The generated repo records the target Deployment and container through delivery parameters.

StatefulSets, DaemonSets, Jobs, CronJobs, custom workload CRDs, generic server-side apply of arbitrary object sets, and Helm release-state ownership are not direct-runtime features in this profile yet. Use Argo CD, Flux, OCI pull delivery, or a custom substrate when those systems already own the richer rollout behavior.

Prerequisites:

  • Kapro operator installed with the default public-preview controllers.
  • kapro built from main.
  • A cluster where the Kapro operator can use the Kubernetes API for direct apply.

For a local preview install:

helm upgrade --install kapro "$KAPRO_CHART" \
  --namespace kapro-system \
  --create-namespace

Generate a direct profile repo:

kapro create direct ./promotion-repo --name checkout
cd promotion-repo

The generated repo contains:

  • substrates/direct.yaml with SubstrateClass, KubernetesApplyConfig, and Substrate;
  • apps/checkout/ raw Kubernetes manifests;
  • clusters/, deliveryunits/, fleets/, plans/, and promotions/ Kapro objects.

Apply the generated repo:

kubectl apply -f substrates/direct.yaml
kubectl wait --for=condition=Ready substrate/direct --timeout=90s
kubectl apply --recursive -f apps -f clusters -f deliveryunits -f plans -f fleets -f promotions
kubectl get substrateclass kubernetes-apply -o yaml
kubectl get substrate direct -o yaml
kubectl get deliveryunits.kapro.io,fleets.kapro.io,plans.kapro.io,promotions.kapro.io,promotionruns.runtime.kapro.io,targets.runtime.kapro.io

Promote a new image:

kapro promote checkout --version ghcr.io/example/checkout:0.2.0
kapro diag checkout-ghcr-io-example-checkout-0-2-0

For the checked-in example generated by the same command shape, use examples/01-quickstarts/01-direct/.

Helm stays a render input for this profile: render charts to Kubernetes manifests before direct apply. A dedicated helm-upgrade substrate is separate future work because Helm release-state ownership has different rollback and hook semantics.