Helm is a great package manager. Packages and dependencies are hard. Especially when the "OS" is so different.

apt doesn't have to worry about if you have a LoadBalancer or StorageClass. It only cares about a filesystem and some services.

It would be great if there were a way to distribute *-lib "packages" too. Something I write in cdk8s I want to make easy to re-use and distribute.

This is typically where language specific package managers come in (npm, pip) so what's the equivalent for Kubernetes?

I think cdk8s has the opportunity to do that for builders. Not by creating yet another tool but by relying on language specific tooling that already exists. npm/pip/etc already have ways to solve this problem

Let CI/CD install cdk8s-cli

kustomize doesn't have a way to share overlays (I don't think it should) which IMO has made adoption slow.

Everything has to be made from scratch which is exactly what libraries help you avoid

libraries aren't for consumers. If I want to run apache I don't go looking for apache-lib. I apt install apache2 or yum install httpd (naming is hard)

If I want to build an https server with code I reach for flask or http-server. I install those with pip and npm

Kubernetes for a lot of people is still in the builders phase. Things change frequently and writing assembly (yaml) was the best option.

Now more tooling allows us to write higher level languages. Sharing and abstracting will let us move faster here.

Kubernetes native packages (CRDs & operators) are a great step forward from templating but still have a lot of rough edges and the "OS" is still maturing in a lot of areas.

There's also still a lot of rough edges around needing "config management" for clusters. We've repeated the same pattern of having bespoke snowflake clusters and slowly moving to clusters as crops

Some people have solved their config management with daemonsets and addons but it's not great from an operators perspective.

Still a lot of work we could do to make this better.

I'm interested to hear from you

How are you solving
- multi-cluster (per team/app)
- multi-cluster (per region/cloud provider)
- config management
- redistributing internal k8s libraries
- re-packaging/migrating legacy services

A monorepo full of yaml can't be the best solution. A monorepo full of templated yaml in some ways feels worse.

DaemonSet `docker pull` jobs feel as bad as curl | bash

I haven't talked to many people using kustomize at the scale it seems designed for

Provisioning is easy compared to day 2 upgrades

There are so many differences between terraform, pulumi, cluster-api, cloudformation.

If you're using kubernetes and not automating releases you'll find yourself with the "RHEL 4" Kubernetes cluster at the center of your business

One thing I'm still waiting for is the AppImage of Kubernetes.

What is the ELF binary equivalent? How can I package everything required to guarantee my software will run?