cdk8s : YAML engineering for developers

cdk8s has been in the Kubernetes landscape for a while but lately, with the upcoming 2.x version, it is rising back in the conversations. And to keep you all up to speed in those conversations, here’s a quick article.
So what is cdk8s and what problems does it solve?

There are many tools for YAML manifest engineering and this is one of them. What it offers additionally, is the ability to reuse the familiarity of programming languages. It lets you define application configurations using Typescript, JavaScript, Python, Java, or Go. Apart from the flexibility in language, you also get to choose the flexibility in API abstractions.

Construct Levels

There are 3 main categories of abstractions when it comes to the cdk8s library:

cdk8s.ApiObject

Level 0 offers the core API objects and you write pretty much the whole YAML (as one would do in Helm charts) or maybe even more. Such amounts of code also translate to a high amount of customization and flexibility.

k8s.KubeDeployment

Level 1 introduces type safety. At this level, you have a pre-defined schema to adhere to and a lot of code is generated for you.

kplus.Deployment

Level 2 consists of hand-crafted high-level APIs. At this stage, you are basically generating full-fledged YAML manifests from mere 2–3 lines of code.

To put it more into perspective, a simple deployment code can be written like this

Or can be abstracted and written with cdk8s-plus like this

Why choose cdk8s?

A big pain for a Kubernetes administrators/developer is upgrading the cluster to a newer release. There can be multiple apiVersions getting deprecated, many entirely removed. Even if you follow the changelogs and make the changes accordingly in your application, there is always a chance that you’d end up finding some breaking change in the live environment during the time of deployment.

By shifting towards the programming side, you now have the option to validate the code at the point of compilation. It is no longer a manifest of declarative configuration, but an actual code which needs to compile.

Shown above is a screenshot from the AWS Container Days (Kubecon EU 2022) where you can see that the Ingress version change while moving from v1.21 of Kubernetes to v1.22 was clearly marked out.

The same goes for the breaking changes in how a service is referenced

And if you were to use cdk8s-plus, such abstracted properties are auto-handled by the library. All you have to do is to move from the library version cdk8s-plus-21 to cdk8s-plus-22.

Parting note

Apart from the shallow learning curve for developers and easy upgrades of cluster, cdk8s offers a wide range on benefits. The community support might not be as big as HELM or Kustomize, it is a tool that will be a better fit in many ecosystems.