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.

Pre-requisites

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 destinations.platform.kratix.io
NAME               AGE
worker-1   1h

$ kubectl --context $PLATFORM get promises.platform.kratix.io
NAME              AGE
jenkins-promise   1h

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

$ kubectl --context $WORKER get pods
NAME                                READY   STATUS    RESTARTS   AGE
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:

worker-2.yaml

apiVersion: platform.kratix.io/v1alpha1
kind: Destination
metadata:
  name: worker-2
  labels:
    environment: dev
spec:
  stateStoreRef:
    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 destinations.platform.kratix.io
NAME       AGE
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
NAME                                READY   STATUS    RESTARTS   AGE
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.

info

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.