NOTE: Launch configurations are available starting from MicroK8s 1.27 and newer.
What are launch configurations?
Installing a single-node MicroK8s cluster is as simple as installing the MicroK8s snap, e.g:
sudo snap install microk8s --classic --channel 1.27
MicroK8s installations come with Calico as the default CNI, dqlite for the datastore and an opinionated set of default arguments for the Kubernetes services. While this works for most setups, there are a number of use-cases that benefit from being able to fine-tune the cluster configuration during initial setup. A launch configuration is a YAML configuration file that can be applied to a MicroK8s node typically during installation.
Launch configurations are only applied to the local MicroK8s node. For multi-node clusters, a launch configuration has to be applied on each cluster node separately.
For more details, see how to use launch configurations and the launch configurations reference.
Features
The setup options available via launch configurations are:
- Set Kubernetes services arguments to enable/disable desired FeatureGates.
- Adjust configuration arguments of Kubernetes services in environments with complex networking requirements (e.g. separate VLANs for control plane and data-plane traffic).
- Configure image registry mirrors for the container runtime.
- Change the default CNI used by MicroK8s.
- Enable/disable MicroK8s addons.
Use Cases
- Airgap deployments
- Use launch configurations to side-load images into the MicroK8s node during installation, configure image registry mirrors, etc.
- Reproducible deployments and environments.
- Deploy a cluster and automatically with a pre-defined set of addons, and Kubernetes configurations.
- Cloud-provider integrations
- Deploy a cluster on a public cloud and use the respective external cloud provider controller manager.
Default launch configuration
Starting with version 1.27, MicroK8s contains a default launch configuration that automatically enables the dns addon for newly deployed clusters.
Any custom launch configurations will always override the default configurations.
Multi-part launch configurations
The launch configurations schema has support for “multi-part” manifests, specified as separate YAML documents in the same file. This allows cluster operators to clearly declare the order of conflicting launch configurations, for example:
Note that in multi-part configurations, the schema version must be specified in all sections.
# Launch configuration example where the DNS addon is enabled, but we override cluster-domain to `cluster.internal`:
---
version: 0.1.0
addons:
- name: dns
---
version: 0.1.0
extraKubeletArgs:
--cluster-domain: cluster.internal