Configuring MicroK8s services

MicroK8s brings up Kubernetes as a number of different services run through systemd. The configuration of these services is read from files stored in the $SNAP_DATA directory, which normally points to /var/snap/microk8s/current.

To reconfigure a service you will need to edit the corresponding file and then restart the respective daemon. For example, to add debug level logging to containerd:

echo '-l=debug' | sudo tee -a /var/snap/microk8s/current/args/containerd
sudo systemctl restart snap.microk8s.daemon-containerd.service

The following systemd services will be run by MicroK8s. Starting with release 1.21, many individual services listed below were consolidated into a single kubelite service.


The Kubernetes API server validates and configures data for the API objects which include pods, services, replication controllers, and others. The API Server services REST operations and provides the frontend to the cluster’s shared state through which all other components interact.

Starting with release 1.21, daemon-apiserver was consolidated into daemon-kubelite.

The apiserver daemon is started using the arguments in ${SNAP_DATA}/args/kube-apiserver. The service configuration is described in full in the upstream kube-apiserver documentation.

Common config changes:
  • Remove the insecure port served on 8080 by default. this can be achieved by adding the line:
  • Allow privileged containers to be run (see also using PodSecurityPolicy below) by adding:
  • Restrict who is allowed to use privileged containers by enabling the PodSecurityPolicy. More on the PodSecurityPolicy is available in the Kubernetes documentation.

After changing the configuration, MicroK8s will need to be restarted for it to take effect:

microk8s stop
microk8s start


Containerd is the container runtime used by MicroK8s to manage images and execute containers.

The containerd daemon started using the configuration in
${SNAP_DATA}/args/containerd and ${SNAP_DATA}/args/containerd-template.toml.


The Kubernetes controller manager is a daemon that embeds the core control loops shipped with Kubernetes. In Kubernetes, a controller is a control loop which watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.

Starting with release 1.21, daemon-controller-manager was consolidated into daemon-kubelite.

The kube-controller-manager daemon is started using the arguments in ${SNAP_DATA}/args/kube-controller-manager. For more detail on these arguments, see the upstream kube-controller-manager documentation.


Etcd is a key/value datastore used to support the components of Kubernetes.

Etcd runs if ha-cluster is disabled. If ha-cluster is enabled, dqlite is run instead of etcd.

The etcd daemon is started using the arguments in ${SNAP_DATA}/args/etcd. For more information on the configuration, see the etcd documentation. Note that different channels of MicroK8s may use different versions of etcd.


Flannel is a CNI which gives a subnet to each host for use with container runtimes.

Flanneld runs if ha-cluster is not enabled. If ha-cluster is enabled, calico is run instead.

The flannel daemon is started using the arguments in ${SNAP_DATA}/args/flanneld. For more information on the configuration, see the flannel documentation.


The kubelet is the primary “node agent” that runs on each node. The kubelet takes a set of PodSpecs(a YAML or JSON object that describes a pod) that are provided and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not
created by Kubernetes.

Starting with release 1.21, daemon-kubelet was consolidated into the daemon-kubelite.

The kubelet daemon is started using the arguments in ${SNAP_DATA}/args/kubelet. These are fully documented in the upstream
kubelet documentation.


Used in release 1.21 and later. The kubelite daemon runs as subprocesses the scheduler, controller, proxy, kubelet, and apiserver services. Each of these individual services can be configured using arguments in the matching ${SNAP_DATA}/args/ directory:

  • scheduler ${SNAP_DATA}/args/kube-scheduler
  • controller ${SNAP_DATA}/args/kube-controller-manager
  • proxy ${SNAP_DATA}/args/kube-proxy
  • kubelet ${SNAP_DATA}/args/kubelet
  • apiserver ${SNAP_DATA}/args/kube-apiserver


The Kubernetes network proxy runs on each node. This reflects services as defined in the Kubernetes API on each node and can do simple TCP, UDP, and SCTP stream forwarding or round robin TCP, UDP, and SCTP forwarding across a set of backends.

Starting with release 1.21, daemon-proxy was consolidated into daemon-kubelite.

The kube-proxy daemon is started using the arguments in
${SNAP_DATA}/args/kube-proxy. For more details see the upstream kube-proxy documentation.


The Kubernetes scheduler is a workload-specific function which takes into account individual and collective resource requirements, quality of service requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, deadlines, and so on. Workload-specific requirements will be exposed through the API as necessary.

Starting with release 1.21, daemon-scheduler was consolidated into daemon-kubelite.

The kube-scheduler daemon started using the arguments in ${SNAP_DATA}/args/kube-scheduler. These are explained fully in the upstream kube-scheduler documentation.


Calico is a CNI which provides networking services. Calico runs on each node. calico-node is not managed by systemd.

Calico runs if ha-cluster is enabled. If ha-cluster is not enabled, Flannel runs instead.

Last updated 3 months ago. Help improve this document in the forum.