Claims¶

A claim asks for a Camunda cluster or a management plane under the policy of an environment. The fleet manager writes claims from its create flow. This guide writes one with kubectl, so you can see what the operator creates from it.

The kinds of this guide are an alpha API in the group fleet.camunda.io/v1alpha1. Their fields can change in a later release.

Create a cluster from a claim¶

This part creates the cluster my-cluster in the namespace my-cluster-ns, with Elasticsearch that you already run as its secondary storage.

You need:

The operator installed. See Installation.
A CamundaClusterPreset small, a CamundaRelease camunda-8-9-0, and a CamundaPlatformConfig my-platform-config.
A SecondaryStorageConfig my-storage-config in the namespace my-cluster-ns. See Secondary storage.

Create an Environment that allows the preset, the release, and the option existing-secondary-storage. The parameter policy lets a claim set the name of its SecondaryStorageConfig:

apiVersion: fleet.camunda.io/v1alpha1
kind: Environment
metadata:
  name: production
spec:
  platformConfigRef: my-platform-config
  presets:
    camundaCluster:
      - small
  releases:
    allowed:
      - camunda-8-9-0
    default: camunda-8-9-0
  sections:
    secondary-storage:
      required: true
      default: existing-secondary-storage
      allowed:
        - existing-secondary-storage
  parameters:
    existing-secondary-storage:
      name:
        claimEditable: true

Put the namespace in the environment:

kubectl label namespace my-cluster-ns fleet.camunda.io/environment=production

Apply the claim. It takes the release and the platform config from the environment:

apiVersion: fleet.camunda.io/v1alpha1
kind: CamundaClusterClaim
metadata:
  name: my-cluster
  namespace: my-cluster-ns
spec:
  presetRef: small
  plugins:
    - section: secondary-storage
      registration: existing-secondary-storage
      parameters:
        name: my-storage-config

Wait until the claim is ready:
```
kubectl wait --for=condition=Ready camundaclusterclaim/my-cluster -n my-cluster-ns --timeout=30m
```
The claim is ready when its CamundaCluster is ready. That takes as long as the start of a cluster.

Read the status of the claim:

kubectl get camundaclusterclaim my-cluster -n my-cluster-ns -o yaml

status:
  environment: production
  cluster:
    name: my-cluster
  requests:
    - name: my-cluster-secondary-storage
      section: secondary-storage
      registration: existing-secondary-storage
      outputsReady: "True"
      ready: "True"

The claim created two objects. The PluginRequest my-cluster-secondary-storage asks the built-in option for the name of the SecondaryStorageConfig. The CamundaCluster my-cluster names it in spec.storageRef. Connect to the cluster as the CamundaCluster page describes.

If Ready stays False, its reason tells you what to correct. The CamundaClusterClaim page lists each reason and what to do.

Create a management plane from a claim¶

This part creates the management plane my-plane in the namespace my-plane-ns. The plane serves the clusters of the environment production. Users sign in through the identity provider of the platform config. The plane uses a database that you already have.

You need:

The Environment production of the first part, and the namespace my-plane-ns with the label fleet.camunda.io/environment=production.
A CamundaPlatformConfig my-platform-config with an OIDC identity provider. See Management plane.
A DatabaseConfig my-identity-db in the namespace my-plane-ns. See Management plane.

Add the sections of the plane to the Environment. The parameter policy lets a claim name its DatabaseConfig:

apiVersion: fleet.camunda.io/v1alpha1
kind: Environment
metadata:
  name: production
spec:
  sections:
    management-database:
      allowed:
        - existing-database-configs
  parameters:
    existing-database-configs:
      identity:
        claimEditable: true
  # ... the rest of your environment

Apply the claim. It takes the platform config from the environment. clusterSelector: {} selects every cluster in the served namespaces. Without an option of access, the claim sets the URL of Management Identity itself:

apiVersion: fleet.camunda.io/v1alpha1
kind: CamundaManagementClusterClaim
metadata:
  name: my-plane
  namespace: my-plane-ns
spec:
  environments:
    - production
  clusterSelector: {}
  management:
    identityProvider:
      oidc: {}
    identity:
      externalUrl: https://plane.example.com/identity
      admin:
        claimName: groups
        claimValue: camunda-admins
  versions:
    identity: 8.9.10
  plugins:
    - section: management-database
      registration: existing-database-configs
      parameters:
        identity: my-identity-db

Wait until the claim is ready:

kubectl wait --for=condition=Ready camundamanagementclusterclaim/my-plane -n my-plane-ns --timeout=30m

Read the status of the claim:

kubectl get camundamanagementclusterclaim my-plane -n my-plane-ns -o yaml

status:
  environment: production
  managementCluster:
    name: my-plane
  requests:
    - name: my-plane-management-database
      section: management-database
      registration: existing-database-configs
      outputsReady: "True"
      ready: "True"

The claim created the CamundaManagementCluster my-plane. It serves the clusters in the namespaces with the label fleet.camunda.io/environment=production, and its Management Identity uses my-identity-db. If Ready stays False, the CamundaManagementClusterClaim page lists each reason and what to do.

Delete a claim¶

The deletion policy of the claim decides what the plugins do with the resources that they created, such as buckets and keys. Delete deletes them. Orphan keeps them. The CamundaClusterClaim and CamundaManagementClusterClaim pages say what each claim always deletes. The steps below delete a cluster claim. For a plane claim, use camundamanagementclusterclaim and its names.

If you want to keep the resources of the plugins, set the policy Orphan before you delete the claim:

apiVersion: fleet.camunda.io/v1alpha1
kind: CamundaClusterClaim
metadata:
  name: my-cluster
  namespace: my-cluster-ns
spec:
  deletionPolicy: Orphan
  # ... the rest of your claim

Delete the claim:

kubectl delete camundaclusterclaim my-cluster -n my-cluster-ns --wait=false

Read the status of the claim while it waits for the plugins:

kubectl get camundaclusterclaim my-cluster -n my-cluster-ns -o yaml

status:
  conditions:
    - type: Ready
      status: "False"
      reason: Deleting
      message: 'The claim is deleted after these objects are gone: PluginRequest my-cluster-secondary-storage'
      observedGeneration: 2

The message names each object that the claim waits for. When the reason is NotAllowed, the claim deletes nothing. A selected registration does not support Orphan. To continue, set spec.deletionPolicy: Delete. The plugins then delete their resources.

Wait until the claim is gone:

kubectl wait --for=delete camundaclusterclaim/my-cluster -n my-cluster-ns --timeout=30m

The claim deletes the CamundaCluster my-cluster with both policies. If the claim stays, read the status of the request that the message names:

kubectl get pluginrequest my-cluster-secondary-storage -n my-cluster-ns -o yaml