addon: Initially scaled to minimize resource use

[solsson]

Good for Minikube and other experimental setups.

Should be compatible with bootstrap.servers containing the regular 3 kafka nodes, because the first one exists.

Note that to scale up after create, the zookeeper config must be restored. It hard codes the list of instances.

[solsson]

If we begin to depend on preparation scripts like c481cba we might want to use the small scale as default, and increment the numbers in such scripts. It's a gotcha anyway that a kubectl apply might re-scale your cluster when you only wanted a pod definition change.

[solsson]

Quite interesting: https://kafka.blog/posts/scaling-down-apache-kafka/

[clintfred]

I'm probably the only slow one, but it took me a minute to realize that the intention was to use the single-node branch to get the "small cluster". @solsson Would you accept a PR to the README to make this clearer? Is the intention to eventually include this as a separate sub-dir in the kafka/ directory?

[solsson]

So far we've avoided templating and manifest duplication. Branches and forks is probably the only way to keep avoiding both of them. I have a similar challenge currently in #155 (comment).

Maybe "official forks" would be the most practical approach to offering different kinds of initial setup for different use cases? The reason being that we recommend everyone to fork anyway. The readme would contain a link and a one liner per official fork. We actually had that in https://github.com/Yolean/kubernetes-kafka/tree/v3.0.0#kafka-on-kubernetes but I'm very short on time to maintain even the main line, so I removed those due to lack of attention.

I'd be glad to see maintainers for such official forks. The single node experiment could definitely need more work, such as tuning for lower memory use.

Or are there advantages with permanently open PRs, for example wrt how github issues works? We could have a one liner per PR.

[solsson]

#253 will replace this kind of branch and the endless rebase it requires