How to Migrate Built-in Blueprints to User-Managed Blueprints

Veeam Kasten includes three built-in blueprints for Kubernetes data services which are created on-demand at runtime. These blueprints have been deprecated and will be removed in a future release.

This guide replaces a built-in blueprint with an equivalent user-managed Blueprint custom resource. A user-managed blueprint gives you full visibility into and control over the backup and restore logic. You can inspect, edit, and debug it with standard Kasten tooling.

Built-in Blueprints and Deprecation Alert

Kasten includes the following built-in blueprints. Each page in the Kanister blueprints repository holds the equivalent user-managed blueprint.

Built-in Blueprint	Trigger	Equivalent Blueprint
K8ssandra	A CassandraDatacenter custom resource in a protected namespace	k8ssandra
Crunchy PGO	A PostgresCluster custom resource in a protected namespace	crunchy-pgo
RDS PostgreSQL	A ConfigMap with the kanister.kasten.io/rds: rds-postgres annotation	aws-rds-postgres

Kasten detects resources that a built-in blueprint protects. It then raises a deprecation warning in the dashboard Alert Messages panel. The alert names the built-in blueprint and links to its equivalent in the Kanister blueprints repository. The alert returns on the next policy run until you migrate the resource.

note

This guide mirrors the knowledge base article KB4956.

Prerequisites

• Hold kubectl access with permission to create Blueprint and BlueprintBinding custom resources.
• Identify the built-in blueprint from the trigger in the preceding table.
• For K8ssandra and Crunchy PGO, hold permission to update the Kasten Helm release.

Migration Procedure

The following steps apply to all three blueprints. Notes mark the differences between them.

1. Open the matching blueprint page in the Kanister blueprints repository and download the blueprint YAML file. The repository holds the current supported version.

2. Add the blueprint to the Kasten namespace (default kasten-io). Apply the file with kubectl.

   $ kubectl --namespace=kasten-io apply --filename=<blueprint>.yaml

   As an alternative, paste the YAML into the dashboard. On the Blueprints page, click Add Blueprint, then Validate and Save.

   Kasten discovers blueprints only in its own namespace. For the full schema, see Blueprint Schema.

3. Bind the blueprint to the application.

   • K8ssandra and Crunchy PGO: Create a BlueprintBinding that selects the resource type. The binding covers current and future resources of that type. As an alternative, add the kanister.kasten.io/blueprint annotation to each resource.
   • RDS PostgreSQL: Create a BlueprintBinding that selects ConfigMaps by a label or annotation that you control. The binding matches ConfigMaps across all namespaces. Do not select on the kanister.kasten.io/rds annotation, because step 4 removes it. As an alternative, add the kanister.kasten.io/blueprint annotation to each ConfigMap.

   To assign the annotation from the dashboard, open the Blueprints page and use Configure Blueprints. A BlueprintBinding takes priority over an annotation when both match the same resource.

4. Disable the built-in blueprint.

   • K8ssandra and Crunchy PGO: Set kanister.managedDataServicesBlueprintsEnabled to false in the Helm values and upgrade the release.

     kanister:
       managedDataServicesBlueprintsEnabled: false

     This value applies to every K8ssandra and Crunchy PGO application in the cluster. Confirm that each one has a user-managed blueprint before you upgrade. Kasten does not delete the built-in Blueprint custom resource (k10-k8ssandra-bp-<version> or k10-pgo-bp-<version>). You can delete it manually after you confirm the new blueprint works.

   • RDS PostgreSQL: Remove the kanister.kasten.io/rds annotation from the ConfigMap. No Helm change is needed. The built-in blueprint stops running after you remove the annotation.

     $ kubectl --namespace=<app-namespace> annotate configmap <name> \
         kanister.kasten.io/rds-

5. Run a backup to confirm Kasten uses the new blueprint. On the Policies page, click Run Once for the application policy. As an alternative, click Run Once on the Policy View page.

Verification

1. Watch ActionSet custom resources (actionsets.cr.kanister.io) in the Kasten namespace during the backup. Kasten deletes each ActionSet when its run completes.

   $ kubectl --namespace=kasten-io get actionsets.cr.kanister.io --watch

2. While an ActionSet exists, confirm that its blueprint reference names the new blueprint, not the built-in one.

3. Confirm that the restore point holds the artifacts the new blueprint produces.

4. Run a test restore in a non-production namespace before you rely on the new blueprint.

---

For the action names Kasten calls, see Reserved Action Names and Timeouts. For the binding schema, see BlueprintBindings.