Skip to main content

Adding a new Destination

One of the most powerful features of Kratix is its ability to react when new Destinations are added to the platform. These Destinations can represent additional Kubernetes clusters, Kubernetes namespaces, or completely different infrastructure like a Terraform Cloud account or edge compute provider. By default, any Promise installed into Kratix will schedule it's Dependencies to new Destinations joining the platform.


In this section, we will register a new Kubernetes cluster as a Destination with Kratix, and experience the Kratix multi-cluster capabilities. Before continuing, you will need a Platform Kubernetes cluster running Kratix, and a second worker Kubernetes cluster to register with the Platform. You also need at least one Promise installed on the Platform.

For the context of this guide, we will assume the setup from Installing Kratix with KinD and that the following environment variables are set:

export PLATFORM="kind-platform"
export WORKER="kind-worker"

We will also use the Jenkins Promise as an example. Follow Installing a Promise to get Jenkins installed, if needed.

$ kubectl --context $PLATFORM get
worker-1 1h

$ kubectl --context $PLATFORM get
jenkins-promise 1h

On the worker, you should see the Jenkins Operator running:

$ kubectl --context $WORKER get pods
jenkins-operator-778d6fc487-gczpb 1/1 Running 0 1h

If your setup is different, update the commands accordingly.

Preparing the new clusterโ€‹

You will now add the new cluster to the Platform as a Destination and watch Kratix reconcile the system. For that, you need to first create the new Kubernetes cluster:

kind create cluster --image kindest/node:v1.27.3 --name worker-2
export WORKER_2="kind-worker-2"

Next, install the GitOps toolkit and create the necessary GitOps resources on the new worker cluster. The quickest way to do that is to run the ./scripts/install-gitops script from the Kratix root directory:

cd /path/to/kratix
./scripts/install-gitops --context ${WORKER_2} --path worker-2

Registering the Destinationโ€‹

You can now register your cluster with Kratix as a Destination. Create a file called worker-2.yaml with the following contents:

kind: Destination
name: worker-2
environment: dev
name: default
kind: BucketStateStore

The Destination will using the pre-existing MinIO State Store. Apply the Destination document to the platform cluster:

kubectl --context $PLATFORM apply --filename worker-2.yaml

Check the Destination was created:

$ kubectl --context $PLATFORM get
worker-1 1h
worker-2 1h

Kratix will react to the new Destination by scheduling the Jenkins Promise to the the correct bucket. After a couple of minutes, you should see the Jenkins Operator deployed and running on the new worker cluster:

$ kubectl --context ${WORKER_2} get pods
jenkins-operator-778d6fc487-c9w8f 1/1 Running 0 1h

When you request a new Jenkins, the Resources will be created in one of the available Destinations, by default this is selected in a non-deterministic way.

For further documentation on Destination scheduling, check the Destination Reference documentation.


If you are specifically interested in making a Resource location deterministic, you can check out the scheduling workloads reference.

๐ŸŽ‰ Congratulationsโ€‹

โœ…ย ย  You have created and registered a new Destination and watched the system react to it.
๐Ÿ‘‰๐Ÿพย ย  Let's write compound Promises.