Kubernetes Packages
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.
Client-side Snaps
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.
kubectl
- client for running commands on a Kubernetes cluster. Docs | Snap
kubeadm
- a tool for bootstrapping a Kubernetes cluster. Docs | Snap
These are installed in the same way. For example:
sudo snap install kubectl --classic
Server Snaps
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.
Snap | Type | Store page |
---|---|---|
kube-apiserver | strict | https://snapcraft.io/kube-apiserver |
kube-controller-manager | strict | https://snapcraft.io/kube-controller-manager |
kube-proxy | classic | https://snapcraft.io/kube-proxy |
kube-scheduler | strict | https://snapcraft.io/kube-scheduler |
kubelet | classic | https://snapcraft.io/kubelet |
Example: kube-apiserver
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:
Running:
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 snap set
:
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
"
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
...
Going further
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:
--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"
The source code for the snaps can be found here:
https://launchpad.net/snap-kubectl
https://launchpad.net/snap-kubeadm
https://launchpad.net/snap-kube-apiserver
https://launchpad.net/snap-kube-controller-manager
https://launchpad.net/snap-kube-scheduler
https://launchpad.net/snap-kubelet
https://launchpad.net/snap-kube-proxy