-
Notifications
You must be signed in to change notification settings - Fork 53
Kubernetes Snaps: The Quick Version
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"}
This covers: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy
We will use kube-apiserver as an example. The other services generally work the same way.
Install with snap install
:
sudo snap install kube-apiserver
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
...
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.
Config values are persisted individually, so if you later call snap set kube-apiserver allow-privileged=false
, the value for etcd-servers
will remain unchanged. You can remove an existing configuration by setting it to null:
snap set kube-apiserver allow-privileged=null
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 at /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 tosnap 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.