A deployment tool for cdk8s charts

[louisdussarps]

Hello everyone,
We’ve been working with CDK8s a lot and found that the deployment options — kubectl apply or trying it via Helm — didn’t fully meet our needs. We were looking for a more resilient way to deploy CDK8s charts, with features like:

• chaining multiple chart deployments
• automatically rolling back to previous state on failure
• exporting values from a chart (e.g., to configure DNS with the ip of the deployed gateway)
  So we built Orbits — a fully programmatic deployment framework for CDK8s. It lets you write deployment flows in Node.js, transparently manage deployment state, chain multiple stacks, and safely exit on errors.

Here’s a quick example of what a flow looks like:

// A resource will manage rollback and pruning of your charts
const myCdk8sResource = new Cdk8sResource();

// Define the chart to be deployed
myCdk8sResource.generateStack = function(){
   //you can return the chart you want
  return new cdk8s.Chart(myCdk8sApp, 'empty-chart');
};

// Launch a deployment and wait for it to complete
const output = await this.do("update-stack", myCdk8sResource); 
// Launch another deployment, using output from the previous one
try {
  await this.do("update-stack-2", new MyCdk8sResource2().setArgument(output));
} catch (err) {
  // Handle deployment failure — retry, adapt input, or trigger fallback logic
}

We wrote a blog post explaining how it works: https://orbits.do/blog/programmable-cdk8s-deployment
The tool is open source and available on npm. GitHub repo here: https://github.com/LaWebcapsule/orbits

Curious to hear what you think!
(And if you like the idea, a ⭐️ on GitHub would mean a lot to us!)

[patroldo]

Hi, @louisdussarps

Nice blog. Read it and awesome
Just before reading your post, i've faced similar issue that i need somehow to define order of resources to be applied
https://github.com/patroldo/kubectl-apply-with-deps

Could you please share your thoughts about it? Basically idea is - instead of building a custom solution which doing stuff like you described - to implement some variant of "standard" by which it's possible to define resource orchestration(at least during kubectl apply). In that case once certain type of solution is ready - it will be possible to show it to kubernetes community

[louisdussarps]

Hello @patroldo ,
Thanks for your time reading the blog post !
I went through the notes you made on the github and I think it's quite clear and complete, but I can misunderstood so don't hesitate to correct me if I am wrong.

I agree that Kubernetes itself doesn’t provide a native way to control the order in which manifests are applied.
Within the Kubernetes ecosystem, I find your annotation approach very relevant as it fits naturally with how users already work with manifests.
However, there are edge-cases (what happens if your kubectl apply crash while it was waiting for another deployment to succeed ? When you would restart the apply command, do you restart the apply on the whole templates list, taking the risk to redeploy resources already deployed, ...) that let me think that more than just annotations, you will need to store some states about your deployments somewhere. So a full solution in the kube ecosystem could be something such as an annotation system + a kube controller.
And, I would have thought that such mechanism already exists in some tools as flux and argoCD. For example, is the dependsOn property on Flux similar to your ?

In our case, we wanted to manage the state outside of kubernetes. For example, we wanted to manage flows where we :

• deploy templateA
• do an API call to some service ; save something in git... Operations that are not easily modeled as Kubernetes resources
• deploy templateB
  Also, we wanted to be able to handle error during the deployment, which is more feasible in Typescript than in a yaml specification.
  That’s why we built an external orchestrator to handle both Kubernetes and non-Kubernetes steps in a single flow