Add support for additional cmdline options to K3s container

[Donnerbart]

See #163

I wanted to add similar support for KindContainer, but struggled a bit to find the according place to do so. I ended up with kubeadm init --patch=/kubeadm-patch but that cannot be combined with --config. But that's where the warnings and deprecations commit for KindContainer originates from (first clean up, then add new features). I could also drop it from this PR to separate it from the new K3s feature.

[dajudge]

Thank you for incoporating the changes so quickly! 💪

I've pondered this approach a bit and I'm worried that in the current form we might be making the API too constrained for future extension.

I'm thinking towards a more generic way to modify the entire k3s command line right before container start - something along these lines.

I'd be super happy to hear your feedback on that approach!

[Donnerbart]

I'm thinking towards a more generic way to modify the entire k3s command line right before container start - something along these lines.

I'd be super happy to hear your feedback on that approach!

The modifier approach comes with the benefit of full flexibility, but the cost of redundant configuration options and the risk to easily break the container start.

An example for the redundancy would be the node port range configuration. That has a dedicated configuration API, but you could also tinker with the string in the command modifier.

An example to break something would be to remove the server part in the command modifier. I'm also not sure if there is a real-life use-case to modify on the traefik or tls-san options without breaking anything.

So with the current default command I don't see the need for this modifier. And if you'd ever add something to the default command it's probably either needed or should get its own dedicated configuration API (because it's actually no fun to modify an existing command with regex or string replacements).

[dajudge]

Thank you for your feedback @Donnerbart, it provides some good points to be considered in this context! 🙏

Over the weekend I've pondered the issue a bit together w/ @bobrossthepainter and I believe we should move forward with the modifier approach.

Here's the reasoning:

The modifier approach comes with the benefit of full flexibility, but the cost of redundant configuration options and the risk to easily break the container start.

I don't think redundancy is a big problem here: the convenience functions can cover the most common use cases while the modifier approach gives developers a power tool to cover all other use cases that we haven't foreseen or haven't gotten around to.

An example to break something would be to remove the server part in the command modifier.

As for the risk of shooting your own foot: if one dives into modifying the k3s cmdline one probably should know what they're doing anyway.

I'm also not sure if there is a real-life use-case to modify on the traefik or tls-san options without breaking anything.

I guess that's the point here: we're simply not sure of the use-cases people might have (e.g. I would never have come up with all the ideas that popped up in #163). So while kindcontainer likes having an opinionated API for the most common use cases, at least having an API that can serve as a fallback in such cases (which to my knowledge is not present at the moment) is a net win in my book.

Would you be willing to integrate the changes into this PR @Donnerbart ?

[Donnerbart]

No worries, I was mostly playing devil's advocate here, because I thought you might have enough pro arguments for the modifier approach.

I will update the PR in a minute.