Kubernetes Snaps: The Quick Version

This article originally appeared on George Kraft’s blog

When we built the Canonical Distribution of Kubernetes (CDK), one of our goals was to provide snap packages for the various Kubernetes clients and services: kubectl, kube-apiserver, kubelet, etc.

While we mainly built the snaps for use in CDK, they are freely available to use for other purposes as well. Let’s have a quick look at how to install and configure the Kubernetes snaps directly.

The Client Snaps

This covers: kubectl, kubeadm, kubefed

Nothing special to know about these. Just snap install and you can use them right away:

$ sudo snap install kubectl --classic
kubectl 1.7.4 from 'canonical' installed
$ kubectl version --client
Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.4", GitCommit:"793658f2d7ca7f064d2bdf606519f9fe1229c381", GitTreeState:"clean", BuildDate:"2017-08-17T08:48:23Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

The Server Snaps

This covers: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy

Example: kube-apiserver

We will use kube-apiserver as an example. The other services generally work the same way.

Install with snap install

This creates a systemd service named snap.kube-apiserver.daemon. Initially, it will be in an error state because it’s missing important configuration:

$ 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: inactive (dead) (Result: exit-code) since Fri 2017-09-01 15:54:39 UTC; 11s ago
   ...

Configure kube-apiserver using snap set.

sudo snap set kube-apiserver \
  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 service snap.kube-apiserver.daemon restart
$ 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
   ...

Configuration

The keys and values for snap set map directly to arguments that you would
normally pass to the service. You can view a list of arguments by invoking the
service directly, e.g. kube-apiserver -h.

For configuring the snaps, drop the leading dashes and pass them through
snap set. For example, if you want kube-apiserver to be invoked like this

kube-apiserver --etcd-servers https://172.31.9.254:2379 --allow-privileged

You would configure the snap like this:

snap set kube-apiserver etcd-servers=https://172.31.9.254:2379 allow-privileged=true

Note, also, that we had to specify a value of true for allow-privileged. This
applies to all boolean flags.

Going deeper

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

/snap/<snap-name>/current/meta/hooks/configure

to see how they work.

The configure hook creates an args file here:

/var/snap/<snap-name>/current/args

This contains the actual arguments that get passed to the service by the snap:

$ cat /var/snap/kube-apiserver/current/args 
--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: https://github.com/juju-solutions/release/tree/rye/snaps/snap

We’re working on getting these snaps added to the upstream Kubernetes build process. You can follow our progress on that here: https://github.com/kubernetes/release/pull/293

If you have any questions or need help, you can either find us at #juju on
freenode, or open an issue against https://github.com/juju-solutions/bundle-canonical-kubernetes and we’ll help you out as soon as we can.