2 posts tagged with "kratix internals"

As much as we would all like, rolling out updates to any software can result in some bumps along the way. This applies to updates to Promises too but Kratix has some feature to help identify any issues within your Promise spec, your Promise workflows and the scheduling of documents outputted by your workflows.

In this blog post we'll explore some of the common issues that users experience when configuring Kratix and developing Promises and well as how Kratix tries to steer you in the right direction when something goes wrong. We'll be exploring:

• Querying Kratix effectively with labels
• Debugging scheduling issues Kratix
• Getting information from Destination and State Store status updates
• Validating the Kratix Promise spec

Click on "read more" to continue!

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?