4 ms·

Ask HN: Package Management for Kubernetes

3 points by linkdd 5y ago

Kubernetes has been around for 7 years now. I often think about Kubernetes as a Cloud Operating System (an interface to operate a cloud infrastructure). Coming from the Linux ecosystem, where every distribution has a package manager (be it apt for debs, dnf for rpms, etc...), it seems weird to me that no such solution exists (AFAIK) for Kubernetes. So far, we've seen Helm/Tanka which looks a lot like the tar.gz archives you'd deploy on a Slackware and wish for the lack of conflicts. In other words: no true dependency management (even with subcharts). Same with FluxCD and ArgoCD, you need to write yourself the source and wire the dependencies together yourself. This is like giving you APT without a repository (dpkg?). I just wish I could say "I have this package, it relies on cert-manager to generate certificates, install it if it's not already". I wish I could have a `PackageRepository` resource that would act like a line in your APT's sources.list and deploy `PackageDefinition` resources in my cluster. I wish I could have a `Package` resource that would deploy my application and its dependencies if not already installed. You would get the following commands out of the box: - kubectl get repositories -> list the repositories configured in your cluster - kubectl get pkgdefs -> list available packages in your cluster - kubectl get packages -> list installed packages in your cluster The underlying package could be an Helm chart, a kapp-controller manifest, or ArgoCD applications. It does not really matter (it would be like tar.gz vs tar.xz vs ... for your Linux package manager). Is there work on this subject going on? Is it worth putting time into it (seems a lot of work)? What do you think HN?

yuppie_scum 5y ago
Helm has a concept of repositories. You could host one yourself and refer to it in your sub charts.
- linkdd 5y ago
  If I want to distribute an application that relies on other charts, I should not have to include them in mine. It's like saying "you can build your own apt repository and embed your dependencies in your .deb package". This is not a viable/scalable solution. This is exactly the tar.gz on Slackware. The key point here is that I don't want to deploy an application, I want to distribute it to others so they can deploy it. And the more requirements you have, the more complex your installation procedure become. Which is error-prone and can be a barrier for adoption. If I want to distribute a .deb, I can specify dependencies from the distribution's repository. I don't need to take care of that myself, and I do not need to tell my users how to get the dependency, it will be the package manager's role (apt, dnf, ...).

3 points by linkdd 5y ago

yuppie_scum 5y ago

Helm has a concept of repositories. You could host one yourself and refer to it in your sub charts.

linkdd 5y ago
If I want to distribute an application that relies on other charts, I should not have to include them in mine. It's like saying "you can build your own apt repository and embed your dependencies in your .deb package". This is not a viable/scalable solution. This is exactly the tar.gz on Slackware. The key point here is that I don't want to deploy an application, I want to distribute it to others so they can deploy it. And the more requirements you have, the more complex your installation procedure become. Which is error-prone and can be a barrier for adoption. If I want to distribute a .deb, I can specify dependencies from the distribution's repository. I don't need to take care of that myself, and I do not need to tell my users how to get the dependency, it will be the package manager's role (apt, dnf, ...).