When searching this Slack space for `cdk8s`, zero ...
# kubernetes
When searching this Slack space for
, zero matches are found. Is nobody considering generating k8s objects programmatically with this tool? What are you all using for that part of your platform? Or are you just providing standard tools so developers can commit their yaml (or kustomize/jsonnet/...) into git?
Hey Serge 👋
Hi Laszlo. Didn't get yet to produce a good subject for our conversation on that other platform 🙂 but hadn't forgotten about it.
Time will come!
I don’t have anything to add in this conversation though, so i am out 💨
Issue @Serge van Ginderachter is that this is the free version of Slack
So messages from 3 months back are all hidden
Sure, but still, have been searching for it a couple of times over the past weeks/months. Seems to never come up.
To play devil's advocate I'll bite; I'm curious as to the advantage of using a tool like this that essentially transpiles back to YAML anyways? If folks have to learn how to use cdk8s to create objects, and potentially have to learn some YAML for troubleshooting later, wouldn't it be easier to learn the YAML? My worry is that if you have teams that use multiple languages, they each have to learn their language-specific way to create things, plus you've now got a dependency on cdk8s to keep up-to-date with k8s releases for API changes (and introduce another abstraction that could break/requires testing)
(genuinely curious to hear other people's use-cases btw, I don't have a strong preference!)
My use case is to use cdk8s for the backend of a platform; the idea is not to have this used by the end-user. Having done a lot with kustomize, and falling quite quickly in the complexity of it, even with only a handfull of clusters/environemnts and applications, I have become to strongly dislike the various "yaml abstraction layers" like kustomize or things like jsonnet etc.
Another point of view could also be: instead having to learn the various syntaxes of all those different (abstraction) tools, just stick to the language you already know. In that way, cdk8s makes a lot of sense.
Ah if used in the context of an IDP I can see how that makes sense, was going to mention that having feature developers author these wouldn't necessarily make sense, but if it's config-driven/UI-powered I could see the advantages for sure. Thanks the the insight!
@Serge van Ginderachter Convo years ago: Newbie: I don’t know why everyone hates syntax. I love syntax!! Old Bat (me): How many OSs do you work on on a daily basis? Newbie: Well, one. Old Bat: Well, I work on five on a daily basis and you know what? I really hate syntax because they are all just a bit off from each other. (still true)
Yeah, it depends on the level of abstraction you're looking for, other requirements you may have like packaging and ofc. experience in the team to maintain the setup. We have a product that's also offered for on-premise installations, so we built a helm chart for it to ensure that on-premise installations are done similarly to our own SaaS version, as much as possible. We then use ArgoCD facilitate the helm chart installation. Also the "base plumbing" for all our clusters comes from an "app of apps", i.e. 1 helm chart that creates multiple ArgoCD apps that each manage a specific helm chart, e.g. storage controllers, load balancer controller, external DNS, etc. For us this works conveniently so far. As we've already been using Terraform for years, also to build managed k8s clusters, we don't really have the need to start managing e.g. databases via Kubernetes, that seems a bit "indirect" (i.e. unnecessary adding moving parts to the mix). Terraform syntax isn't super awesome, but most of our reasoning is at a slightly higher abstraction level anyway, so actually there's not much difference in preparing or staring at code that creates a database instance in terraform or, say, python (with cdk8s), since both wrap tightly around the cloud provider's api. In both cases you can make code reusable or combine multiple resources. But admittedly, if we'd start greenfield today, cdk8s might be a fair option.