Kratix Ep 2: Multi-Cluster Architecture & IaC

1. The Hub and Spoke Topology (WHERE)

#

To use Kratix properly in a production environment, you must physically separate your computing environments. You cannot treat Kubernetes as a single monolithic entity. Kratix introduces two entirely distinct environments:

The Platform Cluster (The Hub)

#

Think of the Platform Cluster as the brain of your Internal Developer Platform.

• Who accesses it: Platform Engineers (with administrative rights) and Application Developers (with limited user rights).
• What runs here: The core Kratix Controller, the Promises (API definitions), and the temporary Pipeline containers that execute scripts.
• What DOES NOT run here: Application workloads. If a developer asks for a Redis database, a Kafka queue, or a Jenkins CI server, those pods never spin up in this cluster. This cluster acts purely as an API gateway and an orchestration engine. If this cluster goes down, your existing production workloads are entirely unaffected.

The Worker Clusters (The Spokes)

#

Think of the Worker Clusters as the muscle.

• Who accesses it: Ideally, nobody. Humans should have zero direct SSH or kubectl access to these clusters. All deployments should be fully automated.
• What runs here: The physical workloads (e.g., the Redis databases, the E-Commerce microservices) and a GitOps agent (like ArgoCD or Flux).
• What DOES NOT run here: The Kratix Controller. The Worker Cluster has absolutely no idea what “Kratix” is. It only knows how to run standard Kubernetes YAML.

The Security Benefit: This model ensures that if an Application Developer accidentally submits a massive, malicious YAML payload that crashes the Kubernetes API server, only the Platform Cluster is affected. The production E-Commerce applications serving real customers on the Worker Clusters remain perfectly safe and online.

2. The Asynchronous Bridge (HOW)

#

Because Kratix lives exclusively in the Hub, and the Redis database must run in the Spoke, how do they communicate?

Does Kratix need root SSH access to every Worker cluster? No. Granting a central orchestration cluster direct cluster-admin access to every production cluster in your fleet is a massive security vulnerability. If the Hub is compromised, the entire fleet is compromised.

To solve this, Kratix utilizes a highly secure, asynchronous communication channel called the State Store.

A State Store is an intermediary location. It sits exactly in the middle between the Hub and the Spokes. Usually, this is a Git Repository (e.g., GitHub, GitLab, Bitbucket) or an AWS S3 Bucket.

The GitOps Flow of Data

#

Let’s trace the exact lifecycle of our E-Commerce Redis scenario, step-by-step:

1. The Request: The E-Commerce Developer runs kubectl apply -f redis-claim.yaml targeting the Platform Cluster.
2. The Processing: Kratix detects the new claim and boots a temporary Docker container (The Pipeline) in the Platform Cluster. This container runs a Bash script that calculates the required parameters and generates the raw Kubernetes StatefulSet YAML for the Redis database.
3. The Push (State Store): Kratix takes that generated YAML and commits it directly to a GitHub repository (e.g., github.com/acmecorp/kratix-state).
4. The Pull (Worker Cluster): ArgoCD, running on the Worker Cluster, constantly polls that GitHub repository every 3 minutes. It detects the new commit, pulls the StatefulSet YAML down, and applies it to the local cluster API. The physical Redis pod boots.

This architecture is entirely Pull-Based from the perspective of the Worker Cluster. The Hub cluster never initiates a network connection to the Worker clusters. Firewalls only need to allow outbound traffic from the Worker clusters to GitHub, drastically reducing the attack surface.

3. Integrating Infrastructure-as-Code (IaC)

#

This all sounds wonderful for Kubernetes workloads (like a Redis StatefulSet), but how does a non-Kubernetes tool like Terraform fit into this GitOps architecture?

What if the E-Commerce team’s Redis deployment is strictly regulated, and requires an AWS S3 bucket to store encrypted daily backups? ArgoCD cannot create an S3 bucket; it only understands Kubernetes YAML.

Kratix solves this elegantly by executing imperative tools inside the Pipeline container before the GitOps phase even begins.

The Kratix + Terraform Workflow:

1. Kratix boots the Pipeline container. (The Platform Team built this custom Docker image to include the terraform binary).
2. The Pipeline script reads the developer’s request.
3. The Pipeline executes terraform apply directly against the AWS REST API to create the S3 bucket. (The Pipeline container requires AWS IAM credentials to do this).
4. The Pipeline captures the resulting S3 bucket URL from the Terraform output.
5. The Pipeline generates the Kubernetes StatefulSet YAML for Redis, injecting the S3 bucket URL as an environment variable into the Redis pod configuration.
6. The Pipeline finishes and exits successfully. Kratix commits the StatefulSet YAML to the Git State Store.
7. ArgoCD pulls the YAML and deploys Redis onto the Worker cluster, perfectly configured to backup to the newly created S3 bucket.

In this scenario, Kratix successfully orchestrated an imperative, cloud-provider tool (Terraform) alongside a declarative, cluster-native tool (Kubernetes YAML) into a single, seamless atomic deployment for the developer.

4. Multi-Cluster Routing (Destinations)

#

If you have 10 Worker Clusters (e.g., 3 for Dev, 3 for Staging, 4 for Prod across different geographic regions), how does Kratix know which GitHub folder to push the YAML into, so it reaches the correct cluster?

Kratix manages this using a Custom Resource called a Destination.

When a Platform Engineer registers a new Worker Cluster with Kratix, they create a Destination object in the Platform Cluster. This object creates a hard link mapping a specific path in the Git repository to a specific set of identifying labels.

apiVersion: platform.kratix.io/v1alpha1
kind: Destination
metadata:
  name: worker-prod-us-east
  # These labels are how Kratix identifies this cluster!
  labels:
    environment: production
    region: us-east
spec:
  filepath:
    repo: https://github.com/acmecorp/kratix-state.git
    # Kratix will ONLY write to this specific folder for this Destination
    path: clusters/prod-us-east/

When an E-Commerce developer requests a Redis database and explicitly specifies environment: production in their YAML claim, Kratix evaluates all available Destinations. It finds the Destination with matching labels, and writes the output YAML explicitly into clusters/prod-us-east/.

Only the ArgoCD instance that is specifically configured to watch the clusters/prod-us-east/ path will pull it down. The Dev and Staging clusters will simply ignore it. This is how Kratix achieves massive, targeted multi-cluster routing without requiring complex networking setups.

Conclusion & Next Steps

#

You now deeply understand the “Where” and the “How”. Kratix sits safely inside the Hub, generates YAML via isolated Pipelines, and pushes it to Git, allowing highly-secured Worker Clusters to pull their workloads asynchronously.

However, a glaring architectural question remains. Didn’t we just learn in the previous series that Crossplane also handles infrastructure provisioning using a GitOps model? How do Kratix and Crossplane interact? Are they competing technologies, or do they work together?

In Episode 3: Kratix GitOps vs. Crossplane GitOps, we will resolve this architectural conflict once and for all. We will define the exact boundary between the two tools and learn why the most advanced Platform Engineering teams combine both of them to build the ultimate, declarative IDP.