Hello again, avid readers. Sorry that it’s been so long! I was originally optimistic that I’d be able to do monthly updates. I’ve since learnt that I’m not a monthly update kind of gal. So, we’re going a little bit more generic with the naming of these updates!
However, don’t let my inconsistency fool you into thinking that we aren’t doing exciting things here at Syntasso. This time, I want to focus on three big things:
Integrating Kratix with Portals
Resource Health Checks
K8S-ing it up for KubeCon
IDPortal for your IDPlatform
Is an IDP an Internal Developer Platform or an Internal Developer Portal? Plenty have discussed what the ‘P’ stands for. I think that what matters the most, with whatever direction you choose, is that you make it easy for Platform users to request the services they need, the way they want, at the right abstractions. Then, once the happy users are requesting away, Platform teams can use Kratix to consistently and safely fleet manage those services.
We’ve always been huge fans of Backstage.io, and have recently made trying out our SKE (Syntasso Kratix Enterprise) integration a little bit easier. Abby and the team have created a great video on how to get started with Backstage and SKE, as well as a hands-on lab so you can try it out yourself. Watch until the end of the video to get access to the lab!
For fans of other portals, Abby has also shown how Kratix and Port can work together to keep all of your Port-created services maintained and up to date! She shows off the powerful integration here.
Resource health checks
We all hope and pray that our systems and services are healthy and ready to go 100% of the time. But there are rare* occasions when things may not be working quite as we expect. Sometimes, you need to quickly know that something isn’t working the way you expect so you can fix it. We’ve made that a little easier with resource health checks. Kratix now understands the “healthRecord” field in the status of a resource. This allows you to send status and other free-form information back from your resource to the platform.
Taking this to another level is our SKE Health Agent. This little fella allows you to keep a separation between your platform cluster and worker clusters. For teams using Kubernetes, the agent understands the health checks you want to run against your resources and populates the health record for you. Reach out via slack or email if you’d like to know more.
This is step one in enabling native progressive rollouts in Kratix - giving you more power to upgrade your services. Pretty neat.
⚠️ We are working on a demo and lab of this new feature - I’ll update the blog when we finish them!
*Under no circumstances should anyone from teams I have worked with before chime in here.
Gettin’ ready for KubeCon
As you may have seen, the Syntasso crew is all over KubeCon like a rash. We’ll be putting on workshops, manning booths at both Platform Engineering Day and the main event, and talking on every day of the event (😱).
Those who’ve used Kratix will know we’re best buds with the Kubernetes UX and ecosystem - before we turn up, I wanted to shout a bit about how we make Kratix easy for those K8S wizards out there. Over to Derik, one of our Principal Engineers!
The API is just a CRD
Core to the Promise is the API it provides to the users of it. In it, you define what properties can be configured, how they should be validated, what’s required and what’s optional, and so on. We kept it simple: the `spec.api` of a Promise is literally a Kubernetes Custom Resource Definition. They become available to the users as a CRD. Nothing special about it, everyone knows how to write a CRD*. You get all the flexibility of CRDs without having to maintain a controller for it. It’s all win.
*not really 😅 it's a long piece of YAML, and it's easy to get it wrong (and sometimes hard to reason about it). That’s one of the reasons we built the Kratix CLI: a few commands and you will have your API in no time 😌
Kratix Pipelines are just Jobs (and pods)
If you look closely at the structure of the Kratix Pipeline, you will quickly realise it resembles the Kubernetes Pod spec. And that’s on purpose. When designing the Pipeline kind, we wanted to keep its specification as close as possible to the good ol’ Pod. Want to mount a particular secret or volume? `spec.volumes` and `spec.containers.volumeMounts`. Environment variables in your containers? set it with `env` or `envFrom`. Want to set the Pipeline pod security context? Just do it.
🛣️ On the Roadmap
Expose more Job and Pod properties
But simpler
On the other hand, no one likes configuring RBAC*. That’s why we made it a tad bit simpler. Kratix will automatically manage the creation of Roles, RoleBindings and all the other super fun resources that make up RBAC. You only need to set what permissions you want to give the Pod service account in `rbac`, and Kratix will do the rest.
The more observant of you may have noticed that the Pipeline Pod includes a few extra containers. Those are there to simplify your experience writing Promises. The first container executed, the `reader`, will populate the `/kratix/` volumes with the information you will likely need to execute your workflow. The last couple of containers are also injected by Kratix: the `work-creator` creates a `Work` that will be used to write the pipeline output to the State Store. The `status-writer` will make sure the resource `status` is updated appropriately.
Which brings us to the next point.
*in case you do, you can manage it yourself (just make sure to set the .rbac.serviceAccount in the Pipeline spec).
Status
Everyone loves a good status. It’s via the `status` that you can communicate to your users what’s actually going on with their resources. Kratix has a built-in mechanism for updating the resource status: you write a special file to `/kratix/metadata` (the file is creatively named `status.yaml`), and Kratix ensures the status is reflected in the resource. You can even update a resource status via the HealthRecord CR (hint: it’s used for health checks).
🛣️ On the Roadmap
Expand Kratix-owned resource status: we have recently introduced status to Destinations, and would like to continue expanding it so it’s clear to you what’s going on in your Platform
Support for events: status is great, and events are even better. It’s going to happen, I promise.
What have we missed?
Have you tried out Kratix recently? Or perhaps even our enterprise offering, Syntasso Kratix Enterprise? If you have any thoughts about how we can make that K8S-power-user experience even better, let us know by joining our community slack or starting a discussion in GitHub!
And if you’re going to KubeCon in London, come and say hello to us at the booths on Platform Engineering Day and in the start-up area of the main event. We’ll be giving demos and answering any questions you have every day! Buh-bye!
Comments