One post tagged with "kratix internals"

Ever wondered how Kratix actually gets your documents from the Platform Cluster to the correct Destination?

The Syntasso Team has recently introduced a change to Kratix to reduce the size of the Work object. While this change is mostly internal, we wanted to share how the innards of Kratix work.

So brace yourself to learn:

• how Kratix moves documents from Platform to Destinations
• what works and workplacements are
• how to inspect works to debug your Promises

You are probably already familiar with how Kratix works at a high level and with the diagram below:

As illustrated above:

1. The user sends a new App Request to the Platform Cluster.
2. The Promise reacts to that request and triggers the Resource Configure Workflows.
3. The Workflow completes and outputs a series of documents to be scheduled to a Destination.
4. These documents are written to a specific directory in the State Store.
5. In the diagram, the documents are scheduled to a Kubernetes Destination. These type of Destination usually have Flux (or ArgoCD, or another GitOps tool) watching the State Store. The tool picks up the new documents.
6. The documents are then processed and applied to the Destination.
7. The App becomes operational on the Destination.

In this post, I'm going to expand on points (3) and (4): what happens at the end of the Workflow? How is the document written to the State Store? And how does the change linked above affect this process?