Why would one use Kosko instead of CDK8s?

[Vad1mo]

Found the project and it looks interesting.
I was wondering why would I want to use Kosko instead of CDK8s.

I didn't find any answer in the code or docs so hence the question/feature request to add this information.

[revolunet]

Hi, some input as a user :

Pros :

• kosko is "just" TypeScript around kubernetes API and some conventions (ex: environments)
• just Kubernetes manifests, nothing vendor specific but you can bring your own manifests
• easy to grasp for JS/TS devs
• compatible with JS/TS tooling (ex: jest for testing)

Cons, but i guess they're the same on CDK8S :

• JS/TS tooling stability
• Ops/YAML people dont get JS/TS benefits
• Not natively compatible with ArgoCD

Try the playground to see for yourself : https://kosko.dev/play

[Vad1mo]

ArgoCD can be used with CDK8s as plain k8s manifests are rendered. This makes also the output usable by ops people and their tooling and workflows with k8s manifests.

[revolunet]

kosko also renders plain manifests at the end, but i meant argocd cannot execute kosko er cdk8s by itself, the manifests needs to be GIT versionned

[tommy351]

Kosko is just a tool that renders TypeScript code into YAML and provides environment management, IDE auto-completion, and OpenAPI validation.

Based on what I saw on cdk8s documentation, it seems to be more focused on charts, dependency management, and multi-language support.

I think it might be easier to migrate to Kosko than cdk8s. If you have existing YAML files, you can load them directly, or let Kosko rewrite them into JavaScript for you. Kosko also supports Helm charts and Kustomize.

[geekflyer]

I just spend the past few days evaluating different solutions to use render k8s manifests (and potentially other stuff) using TypeScript+Node. From the TypeScript+Node camp I like kosko so far the most.
Here's my personal comparison (will update as I discover more stuff):

• Pulumi - overall pretty great and mature. I've used it in the past for GCP+AWS+k8s successfully. Unfortunately when working on large/non-trivial k8s components I often ran into problems when part of the program fails to apply but I want to ignore this failure for now and still be able to apply other parts of the program (due to how it awaits deployment and kinda exits early when part of the program fails to deploy). Also the fact that it keeps state seperate from k8s just introduced some annoying situations in which I had to manually resolve the inconsistencies. Overall https://github.com/laurci/kubernate#this-sounds-like-pulumi summarizes the issues pretty well. That said I still love and use pulumi for many non-k8s things, incl. GCP+AWS etc. and I'd use it any day over Terraform.
• Kubernate - https://github.com/laurci/kubernate . Doesn't seem well maintained. Wasn't obvious to me how to use it programmatically (that was kinda important to me).
• Cdk8s - https://cdk8s.io/ . The way how it defines constructs etc. feels pretty heavy. Class oriented but in a imo weird/untiuitive way. Also don't love that you have to regenerate the k8s APi from scratch - there is no prebuild package. Seems to have a large community though thanks to AWS. The main reason - and that's kind of a showstopper for me - I didn't like it is that it's API/constructs return untyped code with any. In general the framework doesn't really seem to adhere to modern TypeScript best practices and uses a lot of any types internally and on the API surface. Concretely when you do a const deployment = new KubeDeployment(this, "my-deployment", { spec: ... } ) you can't reference any of the spec properties of the deployment in a typed way. This makes reusing / referencing sub properties between k8s resources pretty brittle. Also cdk8s seemed to generate some resource names with random numbers and ck8s specific labels that are used for service selection etc. . Lastly since it solely relies on classes/constructors, it's not directly possible to define resources async, which limits what you can do. Altogether cdk8s just feels a bit too heavy and magic. I just want something that feels like a lightweight node library to generate arbitrary configuration, rather than some magic k8s-specific wrapper thing.
• https://github.com/jkcfg/jk - No native TypeScript or ts-node support. Also it's not actually running node / you can't import regular modules which limits what you can do. I don't really buy the hermeticity argument considering all the downsides this approach has.
• dxcfg - https://github.com/dxcfg/dxcfg . Honestly this one is really good and technically exactly what I'm looking for. I used it for a few days and it works like a charm. Very lightweight. It runs on deno though, which is a double edged sword. While I love deno, I noticed that using both deno and node in the same workspace is confusing as hell and also VS doesn't really love doing code completion etc. if you have a project that uses both. Also while there are a lot of good libraries, you can't beat the depth/breadth of npm's ecosystem.

My kosko impressions: It feels relatively lightweight, supports programmatic use. Relatively natural API that leverages ES exports/imports and normal way to define reuse methods whichever way you want (classes, functions (incl async), modules, up to you). Also one can see from the code that the author knows TypeScript well enough to avoid spurious use of any. First class support for creating resources in async functions. Altogether kosko looks much better than cdk8s to me, despite cdk8s popularity (well the AWS brand...).

Will update my thoughts as I use the product more.

[RealityAnomaly]

Wow this really seems like the holy grail. Have experimented with many solutions including Terraform, Pulumi, cdk8s and even my own custom-built nix-and-jsonnet nightmare amalgamation. Will report when I've evaluated more!