Currently the documentation details a manual installation process for Kubermatic and its components. This works pretty well, though has some friction on every minor release, as we usually have some small mandatory migration steps (for example 2.13 to 2.14).
We want to improve this process by providing a program similar to KubeOne that handles installation, upgrades as well as maybe some misc tasks.
We propose to add a new binary called kubermatictl that provides:
- mostly automated installation (a few things will always require manual intervention, like setting up complexer storage systems or integrating customized LoadBalancer support);
- handle upgrades between Kubermatic releases;
- perform both steps in a single
deploycommand (similar to kubeone’
- absorb the few utility functions that
kubermatic-operator-utilis currently providing (defaulting configuration files and such);
- maybe absorb the noderesource-documentor
If everything is set up, the workflow would be:
- kubermatictl installs nginx, cert-manager and Kubermatic Operator into a cluster;
- Kubermatic Operator then manages/reconciles the actual Kubermatic master and seed installation
To prevent confusion, we should avoid the following names:
Some of these have been floating around in various channels and have caused miscommunication already. Naming is apparently harder than expected
There is an open Pull Request https://github.com/kubermatic/kubermatic/pull/5685 that would move our old
kubermatic-installer into the Kubermatic repository. This will make it much, much easier to keep it in-sync (the old installer’s Achilles’ heel was that it was pretty much always outdated) and allow us to use it during all e2e tests (i.e. hopefully remove most of the
The code is far from perfect or complete, but it’s a starting point. It still has some DNA from when it was “only” an installer, so it will take some time to slowly merge other things into it.
The short-term goal is to merge it and get us to use it ASAP for our e2e tests. After that it has become an integral part and we cannot forget to keep it up-to-date anymore.
What do you think? Is it worth combining these things into a single binary? Do we really want to call it that or
k8ctl or something else?