4 posts tagged with "SKE"

We love GitOps.

Kratix, a framework for building platforms on top of Kubernetes, has GitOps at its core, and it's a fundamental part of our recommended platform architecture. It’s what allows Kratix to schedule workloads to any type of Destination, what enables Compound Promises, and a central piece of the declare-and-converge philosophy we follow.

But what happens when hundreds of commits are pushed in a short period? Or when customers want to know "who did that?", but the answer is buried under thousands of automated commits? Or even when you can't commit to the repository at all?

In this blog, we will cover how our health checks turned a GitOps repository into a commit firehose, why switching to buckets was not enough, and how the new Health Source in SKE puts the Platform back in control.

We at Syntasso are very proud of the SKE Backstage integration we built. You apply a Promise, and a Component and a Template automagically appear in your Backstage instance. You can send requests to the platform via GitOps or directly via the Kubernetes API. Changes to the Promise regenerate the Template. You can use an array of CRD properties to control the validation applied to the form, and you can run custom containers to customise what the platform generates.

It is great.

Except, it kinda looks like this:

Which is enough to get you started, but it won't necessarily wow the platform users. It solved the immediate problem for the platform engineer (how do I expose this service on Backstage?), but it was quite simple on the visual front. Apparently raw YAML is not everyone's cup of tea… not sure why. it better.

In this post, we will explore why the interface matters and how it can drive adoption of your platform. We'll look at what we had before, what we have learned from our customers, and how we used that learning to improve the out-of-the-box experience with Backstage. We will then look at what we have just released to make it even better.

Navigating Kubernetes resources can often feel like searching for a needle in a haystack, especially when trying to gain a comprehensive overview of everything deployed within your cluster. While kubectl is a familiar tool, we've heard that it can be complicated to visualise the entire landscape of Kratix Promises and Resources.

To address this, we've been developing a powerful new solution: a SKE plugin for Headlamp, designed to provide unparalleled observability for your Kubernetes environments.

Earlier this year, we introduced an exciting new capability in Kratix: health checks for resources. This addition allows platform teams and app developer to easily observe the status of their requested workloads, without the need to switch context and find it in Destinations.

In this blog, we’ll discuss how you can use it to support progressive rollouts when updating Promises.

What’s the Problem?​

When a Promise gets updated, say with a new version of a Helm chart, the standard behavior in Kratix is to reconcile and update all resource requests at once. That’s fine in simple dev environments, but for complex workloads, upgrading everything at once is risky. A failed update could disrupt many environments simultaneously, and debugging becomes difficult when failures are scattered.

Platform engineers need a safer approach: progressive rollouts. Instead of deploying changes to your entire fleet at once, progressive rollout allows teams to introduce updates gradually to limit the impact, gather early feedback, and catch potential bugs before releasing broadly. But for that to work, Kratix needs a way to understand the health of each individual resource during and after an upgrade.