Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Feature request: allow a way to configure microk8s components with configuration file.
See original GitHub issueThis feature request is to allow users to have ways to configure microk8s cluster components such as apiserver, kube proxy, controller, registry, etc… without resorting to modifying multiple files in /var/snap/microk8s/current file system.
Users should be able to configure microk8s like this microk8s.configure -f config.yaml
This can help administrators or users to easily share configs among their teams and potentially version them too.
What do you think?
List of configurable components.
- containerd
- kube api server
- kube controller
- kube proxy
- kubelet
- csr
Issue Analytics
- State:
- Created 4 years ago
- Reactions:13
- Comments:12 (5 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
This comes up very frequently (eg https://github.com/ubuntu/microk8s/issues/43 and https://github.com/ubuntu/microk8s/issues/92). It will be great to be able to have a
microk8s.init(following the lxd snap paradigm) that would configure MicroK8s.microk8s.init(or.setup) would be interactive and ask for some basic configuration options.microk8s.init -f config.yaml(or.setup) would use the config file providedmicrok8s.init --auto(or.setup) would reset to the default valuesmicrok8s.init set <property> <value>(or.setup) could set arbitrary configuration values that could be consumed by the addons, egmicrok8s.init set dns.upstream 1.2.3.4to set the upstream nameservers on dns.Implementation-wise I was thinking we could store the configuration yaml in $SNAP_DATA and offer a few utility functions to be used by the rest of MicroK8s. It would be up to the wrapper of each service (or addon script) to read that configuration and apply the subset of the configuration values that are relevant to what is wrapped.
Yes, that makes sense. When your have a MicroK8s cluster you would expect the user activity to propagate to the nodes (see for example the dns addon). The cluster-agent on the nodes takes care of the service configuration and restarts. It can even fire scripts that come in the form of addons.
We could leverage this for the wide configuration.