Kratix Ep 3: Kratix GitOps vs Crossplane GitOps

1. The Confusion of Overlap

#

At first glance, Kratix and Crossplane appear to solve the exact same problem: Abstracting immense technical complexity away from Application Developers by providing simple APIs.

• Crossplane uses Composite Resource Definitions (XRDs) to present a simple API (e.g., XPostgreSQLInstance). It uses a Composition engine to translate that simple request into complex AWS physical resources (VPC, Subnet, RDS Instance).
• Kratix uses Promises to present a simple API (e.g., RedisCluster). It uses a Pipeline container to translate that simple request into complex Kubernetes YAML (StatefulSet, Service, Ingress).

If you want to give the E-Commerce team a highly reliable, self-service database, which one do you use? Are they mutually exclusive?

The answer lies in understanding their Scope of Responsibility.

2. Crossplane: The Specialized Executor (Infrastructure Provider)

#

Crossplane is strictly an Infrastructure Provider. Its entire existence is dedicated to one highly specialized task: talking to cloud provider REST APIs (AWS, GCP, Azure) and enforcing their state.

Crossplane is exceptional at maintaining state because of its Reconciliation Loop. If a rogue sysadmin logs into the AWS Console and manually deletes an S3 bucket that was provisioned by Crossplane, the Crossplane controller will instantly detect the drift within seconds and recreate the bucket exactly as it was defined in the YAML.

However, Crossplane has severe limitations when building a holistic IDP:

• Crossplane cannot run an arbitrary bash script to perform custom pre-deployment logic.
• Crossplane cannot run Terraform code for legacy systems.
• Crossplane cannot generate a random, cryptographically secure password and push it directly into HashiCorp Vault.
• Crossplane is strictly limited to the Custom Resources provided by the official Upbound providers. If there is no provider for a niche tool you use, Crossplane cannot help you.

3. Kratix: The General Manager (Universal Orchestrator)

#

Kratix is a Universal Orchestrator. It does not know how to talk to AWS. It does not have built-in reconciliation loops that constantly poll the AWS API to check if an S3 bucket still exists.

Kratix’s primary superpower is its Pipeline. A Kratix Pipeline is an OCI (Docker) container. Inside that container, you are free to run literally anything. You can run curl, helm template, terraform apply, or a custom Python script that talks to an archaic on-premise mainframe.

Kratix excels at tying multiple, completely unrelated tools together into a single, cohesive workflow. However, because Kratix pipelines execute once and then terminate, Kratix is not designed to enforce the ongoing, infinite-loop state of physical cloud hardware the way Crossplane does.

4. The Ultimate Integration (Better Together)

#

To build a truly production-grade IDP, you do not choose between Kratix and Crossplane. You combine them.

Kratix acts as the frontend orchestrator (residing in the Hub), and Crossplane acts as the backend execution engine (residing in the Spoke).

Let’s return to our E-Commerce Redis Scenario. The E-Commerce team does not just need a raw AWS ElastiCache instance. They need a full “Production Environment”.

This environment realistically requires:

1. An AWS ElastiCache Redis Database. (Physical Cloud Hardware)
2. A Kubernetes Deployment for a caching proxy (e.g., Twemproxy). (Kubernetes Software)
3. A HashiCorp Vault Secret for the database credentials. (External Security Tool)

If you only used Crossplane, you could provision the ElastiCache instance flawlessly, but you would struggle immensely to deploy the software proxy or hit the Vault API simultaneously in the same atomic request.

The Combined Architecture Flow

#

Here is how Kratix and Crossplane execute this highly complex request together:

1. The Request: The Developer submits a single YAML file (The Kratix Claim) to the Platform Cluster.
2. The Kratix Pipeline: Kratix detects the claim and boots a Pipeline container.
3. Pipeline Logic Execution: The custom bash script inside the Pipeline container runs:
   • It hits the Vault API via curl to generate a random password and store it securely.
   • It runs helm template to generate a standard Kubernetes Deployment YAML for the software caching proxy.
   • It generates a Crossplane XRedisInstance YAML for the physical cloud hardware.
4. The Git Push: Kratix commits both the software proxy YAML and the Crossplane YAML to the Git repository (The State Store).
5. The GitOps Pull: ArgoCD (running on the Worker Cluster) detects the commit and applies both YAML files to the Worker Cluster’s API.
6. Crossplane Takes Over: Crossplane (running on the Worker Cluster) sees the new XRedisInstance resource appear. It immediately takes ownership, initiates the REST API calls to AWS, and physically provisions the ElastiCache instance. It then begins its infinite loop, handling all future drift detection and retry logic for the hardware.

Why is this the Holy Grail of Platform Engineering?

#

By combining them, you achieve the best of both worlds. Kratix handles the wildly complex, multi-tool orchestration (Vault + Software YAML + Hardware YAML) that requires imperative scripting. Crossplane handles the rigorous, infinite-loop infrastructure enforcement (keeping AWS in check).

You have built a system where developers get a complete, interconnected ecosystem with one YAML file, without the Platform Team having to write fragile CI/CD pipelines.

Conclusion & Next Steps

#

You now understand the exact boundary. Kratix is the high-level manager that delegates tasks. Crossplane is the highly specialized worker that executes the cloud infrastructure tasks. GitOps (ArgoCD) is the secure courier that delivers the messages between them.

Now that the architectural theory (the 5W1H) is fully established, it is time to get our hands dirty with raw code. What does a Promise actually look like in YAML? How do you write a Pipeline container from scratch?

In Episode 4: Kratix Core Concepts Deep Dive, we will look at the exact YAML structures required to build the E-Commerce Redis Promise, line by line.