Charmed Kubernetes makes extensive use of snaps, both for Kubernetes services and for client-side tools to operate a cluster. This page details some of the Kubernetes-related snaps available and how they are used.
The following client tools are available. Note that it is not required that you use the Snap version of these tools to work with Charmed Kubernetes, they are just provided as a maintained and tested way of keeping up to date.
These are installed in the same way. For example:
sudo snap install kubectl --classic
When installing Charmed Kubernetes, various necessary services are actually installed from snap packages. The installation and management of these snaps is undertaken by the charms; there is no need for a user to interact with the snaps directly. The details here are provided for information only.
We will use kube-apiserver as an example. The other services generally work the same way.
sudo snap install kube-apiserver
This creates a
systemd service named
it will be in an error state because it's missing important configuration:
systemctl status snap.kube-apiserver.daemon
... will return status similar to:
● snap.kube-apiserver.daemon.service - Service for snap application kube-apiserver.daemon Loaded: loaded (/etc/systemd/system/snap.kube-apiserver.daemon.service; enabled; vendor preset: enabled) Active: inactive (dead) (Result: exit-code) since Fri 2020-09-01 15:54:39 UTC; 11s ago ...
The snap can be configured using
sudo snap set kube-apiserver args=" --etcd-servers=https://172.31.9.254:2379 --etcd-certfile=/root/certs/client.crt --etcd-keyfile=/root/certs/client.key --etcd-cafile=/root/certs/ca.crt --service-cluster-ip-range=10.123.123.0/24 --cert-dir=/root/certs "
Note: Any files used by the service, such as certificate files, must be placed within the /root/ directory to be visible to the service. This limitation allows us to run a few of the services in a strict confinement mode that offers better isolation and security.
After configuring, restart the service and you should see it running:
sudo snap restart kube-apiserver systemctl status snap.kube-apiserver.daemon
● snap.kube-apiserver.daemon.service - Service for snap application kube-apiserver.daemon Loaded: loaded (/etc/systemd/system/snap.kube-apiserver.daemon.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2017-09-01 16:02:33 UTC; 6s ago ...
Want to know more? Here are a couple good things to know:
If you're confused about what
snap set ... is actually doing, you can read
the snap configure hooks in
see how they work.
The configure hook creates an args file at
This contains the actual arguments that get passed to the service by the snap:
--cert-dir "/root/certs" --etcd-cafile "/root/certs/ca.crt" --etcd-certfile "/root/certs/client.crt" --etcd-keyfile "/root/certs/client.key" --etcd-servers "https://172.31.9.254:2379" --service-cluster-ip-range "10.123.123.0/24"
Note: While you can technically bypass
snap set and edit the args file
directly, it's best not to do so. The next time the configure hook runs, it
will obliterate your changes. This can occur not only from a call to
snap set but also during a background refresh of the snap.
The source code for the snaps can be found here: