Hi,
if we ship pods like kured (kubernetes reboot daemon) or anything else like a monitoring or logging solution, how should we provide the required *.yaml files to start the pods on the cluster?
E.g. for the kured container we need to apply: - kured-rbac.yaml to allow kured to drain the node - kured-ds.yaml to start the daemonset
If we make kured a required default, it's easy. But what if this should be optional? What would be the best/official solution to provide users with this files, so that they can download the image from our registry and run it on the kubic cluster?
Thanks, Thorsten
On Thu, 2018-10-04 at 14:50 +0200, Thorsten Kukuk wrote:
Hi,
if we ship pods like kured (kubernetes reboot daemon) or anything else like a monitoring or logging solution, how should we provide the required *.yaml files to start the pods on the cluster?
E.g. for the kured container we need to apply:
- kured-rbac.yaml to allow kured to drain the node
- kured-ds.yaml to start the daemonset
If we make kured a required default, it's easy. But what if this should be optional? What would be the best/official solution to provide users with this files, so that they can download the image from our registry and run it on the kubic cluster?
I would argue for these kinds of things to be delivered as a Helm chart. For kured this[1] could be used as base - "forked", with just the image details swapped out for the openSUSE ones, and then published to an openSUSE charts repository. I say "forked" in quotes, because it's not *really* forking.. It's no different IMO to packaging bash.
Even for built in/default things, using a helm chart makes a lot of sense to me - we wouldn't suggest shipping binaries around as a .tgz, we have .rpm after all! For Kubernetes the equivalent to .rpm is Helm :)
Thanks, Kiall
[1]: https://github.com/helm/charts/tree/master/stable/kured
-
Kiall Mac Innes -
Thorsten Kukuk