Über 10 Jahre nach seiner Veröffentlichung hat das Kubernetes-Projekt seinen Weg in den „Mainstream“ gefunden. Bester Beweis dafür ist die Vielzahl an verfügbaren Lösungen: (Fast) jeder Cloudanbieter hat Managed Kubernetes im Angebot, dazu kommt eine Vielzahl von frei verfügbaren Kubernetes-Distributionen für verschiedenste Anwendungszwecke.
Im heutigen Blogpost möchten wir uns eine dieser Distributionen genauer anschauen: K3s verspricht lightweight Kubernetes, […] built for IoT and Edge computing. Doch was bedeutet das konkret?
Baue dein K3s-Cluster in der MyNWS Cloud auf preiswerten und performanten Cloudservern.
Erweitere dein Cluster mit Loadbalancern, S3-Storage, und vielem mehr, und baue die Lösung, die für dich passt!
Die Motivation hinter K3s
K3s ist eine leichtgewichtige Kubernetes-Distribution und unter Anderem für IoT-Umgebungen oder Edge Computing geeignet. Diese Umgebungen zeichnen sich normalerweise durch weniger verfügbare Ressourcen und längere Wartungszyklen als bspw. in klassischen Rechenzentren aus.
Aus diesen Charakteristiken ergeben sich einige der signifikanten Vorteile und Besonderheiten von K3s:
- eine einzige Binary: im Gegensatz zu anderen Kubernetes-Distributionen besteht K3s aus einer einzigen Binary, die alle benötigten Komponenten bündelt, von Containerruntime bis hin zu Ingresscontroller und CNI.
- < 70MB: Ideal für schnelle Downloads, Updates, und Umgebungen mit wenig persistentem Speicher.
- Verfügbar auf vielen Rechnerarchitekturen: K3s ist kompatibel mit x86_64, ARMv7 und ARM64.
- Einfache Konfiguration: Alle grundlegenden Optionen und viele weiterführende Features von K3s lassen sich entweder via Umgebungsvariablen, Konfigurationsdatei oder Kommandozeilenargument angeben.
- Einfache Skalierung: Neue Clusternodes können durch Angabe eines Tokens automatisch ins Cluster aufgenommen werden – egal ob Controlplane oder Worker Node.
Doch wie bewerkstelligt K3s das alles? Werfen wir doch einmal einen Blick auf die Architektur von K3s.
Komponenten von K3s im Überblick
Auf der Projektwebsite finden wir das folgende Schaubild:
Auf den ersten Blick sieht das nicht viel anders aus als in anderen Kubernetes-Distributionen. Wir sehen eine Container Runtime (containerd), die verschiedenen Bestandteile von Kubernetes selbst (API Server, Scheduler, Kubelet, Kube Proxy), ein Container Networking Interface (Flannel), sowie ein paar weitere Bestandteile.
K3s Nodekomponenten
Die Besonderheit: Alle Komponenten, die wir in dieser Grafik sehen, werden durch die k3s Binary gebündelt und orchestriert; darüber hinaus gibt es zusätzlich noch weitere Komponenten, die hier nicht abgebildet sind. Insgesamt bringt eine K3s-Installation folgende Dienste und Hilfstool auf Nodeebene mit sich:
- Kubernetes: Die üblichen Bestandteile und Controller eines Kubernetesclusters; API-Server, kube-proxy, controller-manager, cloud-controller-manager, Scheduler und Kubelet.
- containerd: Die Container Runtime, die von kubelet über das Container Runtime Interface (CRI) instrumentalisiert wird, um Workloads auf den Nodes zu betreiben.
- Kine: Ein Hilfstool, dass es Kubernetes ermöglicht, statt etcd auch alternative Datenbackends wie sqlite, PostGres oder MySQL zu nutzen.
- kubectl: Die offizielle Kubernetes CLI
- crictl: Eine CLI zur Interaktion mit CRI-konformen Container Runtimes.
- ctr: eine inoffizielle CLI für containerd.
K3s Clusterkomponenten
Hinzu kommen in einer Standardinstallation von K3s einige Hilfsmittel auf Clusterebene, die bei Einrichtung eines Clusters automatisch installiert werden:
- Flannel: Ein leichtgewichtiges Container Networking Interface (CNI) für Kubernetes. Mehr Informationen finden sich im GitHub-Repository des Projekts.
- Traefik Ingress Controller: Ein leichtgewichtiger, cloud-nativer Ingresscontroller.
- ServiceLB: ein LoadBalancer-Controller, der unabhängig von der Umgebung des K3s-Clusters funktioniert (ehemals Klipper).
Genauere Infos zur Funktionsweise finden sich in der Dokumentation von K3s. - CoreDNS: ein cloud-nativer DNS und Service Discovery Dienst, der Default für Kubernetes. Mehr Informationen finden sich auf der Website des Projekts.
- Local Storage Provisioner: Ein Storage Driver für Kubernetes, der die Erstellung von
PVCsauf lokalem Speicher der Nodes ermöglicht. Mehr Informationen und Beispiele finden sich in der Dokumentation von K3s. - Metrics Server: Ein Scraper für Metriken des K3s-Clusters und der darin laufenden Workloads, entwickelt und verwaltet durch die Kubernetes Special Interest Groups (SIGs). Mehr Informationen finden sich im GitHub-Repository des Projekts.
- Helm Controller: Ein Kubernetes-Controller zur Installation von Helmcharts durch Erstellung von
CustomResourceDefinitions(CRDs) im K3s-Cluster. Auf diese Weise lässt sich die Installation von beliebigen Anwendungen bspw. zum Zeitpunkt der Clustererstellung vereinfachen.
Mehr Informationen zur Nutzung finden sich in der Dokumentation von K3s.
Die Installation dieser Komponenten kann je nach Bedarf aktiviert oder deaktiviert werden, um ein noch besser auf die Umgebung abgestimmtes Cluster zu erhalten. Doch wie installiert man K3s überhaupt?
Installation von K3s im Überblick
K3s bietet ein Curl to Bash (oft auch Pipe and Pray) Kommando zur einfachen Installation:
curl -sfL https://get.k3s.io | sh - Dieser Befehl downloadet die K3s-Binary und installiert ein Single-Node Cluster mit sämtlichen verfügbaren Addons. Als persistentes Datenbackend wird hierbei auf sqlite zurückgegriffen.
Nach erfolgreicher Installation kann man sich den Zustand des Clusters mit dem ebenfalls in K3s integrierten kubectl Befehl anzeigen lassen:
sudo systemctl show k3s --property=ActiveState
ActiveState=active
sudo k3s kubectl get nodes
NAME STATUS ROLES AGE VERSION
ubuntu Ready control-plane,master 3m29s v1.31.4+k3s1
sudo k3s kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-ccb96694c-wg82j 1/1 Running 0 3m42s
kube-system helm-install-traefik-5xfzh 0/1 Completed 1 3m42s
kube-system helm-install-traefik-crd-drqpd 0/1 Completed 0 3m42s
kube-system local-path-provisioner-5cf85fd84d-mvm46 1/1 Running 0 3m42s
kube-system metrics-server-5985cbc9d7-xckzr 1/1 Running 0 3m42s
kube-system svclb-traefik-16fa2585-lf4jt 2/2 Running 0 3m29s
kube-system traefik-57b79cf995-lpskx 1/1 Running 0 3m29sWie zu erwarten läuft der k3s systemd Service, das Cluster besteht aus einem einzelnen Node, und im Cluster laufen die zuvor erwähnten Addons ( Traefik, ServiceLB, usw.).
Das Token, um diesem Cluster nun Workernodes hinzuzufügen, wurde unter /etc/rancher/node/password generiert und hinterlegt.
K3s im HA-Modus
Spätestens in Produktionsumgebungen möchte man normalerweise nicht auf einen Betrieb mit High Availability (HA) verzichten – auch dieses Szenario lässt sich mit K3s denkbar einfach bewerkstelligen.
Bei der Installation des ersten Servers sind ein Token sowie die Noderolle server anzugeben, die fehlenden, 2, 4, …, Controlplane-Nodes können dann durch Angabe desselben Tokens und des API-Endpunkts zur Registrierung in das Cluster eingebunden werden.
# Initialize the cluster on the first node
curl -sfL https://get.k3s.io | K3S_TOKEN=${SECRET_TOKEN} sh -s - server --cluster-init
# Join additional control plane nodes
curl -sfL https://get.k3s.io | K3S_TOKEN=${SECRET_TOKEN} sh -s - server \
--server https://192.168.1.10:6443Nach kurzer Zeit erhält man ein hochverfügbares Cluster, bestehend aus mehreren Controlplanenodes. Als persistentes Datenbackend wird hier standardmäßig auf ein hochverfügbares etcd Cluster zurückgegriffen, das ebenfalls durch K3s gemanagt wird:
sudo k3s kubectl get nodes
NAME STATUS ROLES AGE VERSION
ubuntu Ready control-plane,etcd,master 21m v1.31.4+k3s1
ubuntu2 Ready control-plane,etcd,master 3m11s v1.31.4+k3s1
ubuntu3 Ready control-plane,etcd,master 2m54s v1.31.4+k3s1
sudo kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-ccb96694c-wg82j 1/1 Running 0 22m
kube-system helm-install-traefik-5xfzh 0/1 Completed 1 22m
kube-system helm-install-traefik-crd-drqpd 0/1 Completed 0 22m
kube-system local-path-provisioner-5cf85fd84d-mvm46 1/1 Running 0 22m
kube-system metrics-server-5985cbc9d7-xckzr 1/1 Running 0 22m
kube-system svclb-traefik-16fa2585-748qt 2/2 Running 0 3m49s
kube-system svclb-traefik-16fa2585-74v6n 2/2 Running 0 3m37s
kube-system svclb-traefik-16fa2585-lf4jt 2/2 Running 0 21m
kube-system traefik-57b79cf995-lpskx 1/1 Running 0 21mIm Vergleich zu unserem Single-Node Cluster sehen wir, dass drei Pods für svclb-traefik laufen, nämlich genau einer pro Node. Das ist für die Simulierung des LoadBalancer Services für den Traefik IngressController ohne externe Dienste notwendig.
Für weitere Workernodes wird auch in diesem Setup jeweils ein Token unter /etc/rancher/node/password auf den Controlplanenodes generiert.
Konfiguration von K3s im Überblick
K3s lässt sich auf drei verschiedene Arten konfigurieren:
- Umgebungsvariablen: Zur Installation der Binary und bei Serviceneustarts werden Umgebungsvariablen in der Form
K3S_SOME_VALUEberücksichtigt. - Kommandozeilenargumente: Zur Installation der Binary und bei Serviceneustarts werden Kommandozeilenargumente und -parameter berücksichtigt, bspw.
serveroder--cluster-init, wie oben zu sehen. - Konfigurationsdatei: Zusätzlich kann eine Konfigurationsdatei im YAML-Format genutzt werden. Diese liegt per Default unter
/etc/rancher/k3s/config.yaml. Die Datei wiederum kann mittels Umgebungsvariable (K3S_CONFIG_FILE) oder Kommandozeilenargument (-c,--config) referenziert werden. Auch eine Konfiguration verteilt auf mehrere Dateien unter/etc/rancher/k3s/config.yaml.dist möglich.
Für erhöhte Flexibilität und Kontrolle bei Installation und Konfiguration lassen sich die drei Möglichkeiten beliebig kombinieren. Die folgenden Aufrufe der Binary sind beispielsweise äquivalent:
K3S_TOKEN=supersecret k3s server --agent-token=alsosecret
K3S_AGENT_TOKEN=alsosecret k3s server --token=supersecretEine detailierte Übersicht der verfügbaren Konfigurationsoptionen und ihrer Verwendung via CLI, Umgebungsvariablen oder Konfigurationsdatei findet sich in der K3s-Dokumentation.
Wichtig zu erwähnen bleibt, dass gewisse Einstellungen auf allen Controlplanenodes identisch sein müssen, damit das Cluster ordnungsgemäß funktioniert. Das betrifft unter Anderem die (De-)Aktivierung von Addons wie Traefik, ServiceLB, oder Flannel.
Mythen rund um K3s
Wenn du bis hierher gelesen hast, bleiben eventuell noch ein paar brennende Fragen offen – Gerüchte und Aussagen, die man des Öfteren auf Konferenzen, in Tutorials und Blogposts lesen kann. Auf ein paar dieser „Mythen“ möchte ich zum Ende des Blogposts noch eingehen.
„K3s unterstützt keine NetworkPolicies“
Für viele sicherheitsbewusste Anwender bereits ein K.O.-Argument. Begründet wird das in der standardmäßigen Nutzung von Flannel als CNI, das tatsächlich keine NetworkPolicies unterstützt. Aus diesem Grund hat das K3s-Projekt einen NetworkPolicy Controller in K3s selbst eingebaut.
Dieser lässt sich je nach Bedarf ein- und ausschalten, bspw. wenn man von vornherein ein anderes CNI (z.B. Cilium) nutzen möchte. Die Implementierungs- und Konfigurationsdetails finden sich in der K3s-Dokumentation.
Festzuhalten ist also: K3s unterstützt sehr wohl und trotz Flannel NetworkPolicies, ohne zusätzliche Konfiguration vornehmen zu müssen.
„K3s ist wegen sqlite nicht für Produktionsumgebungen geeignet“
In seiner „minimalen Form“ nutzt K3s, wie im ersten Beispiel dieses Blogposts gezeigt, sqlite als Datenbackend für den Zustand des Clusters. Dieser Umstand wird oftmals als Argument hergenommen, um die Untauglichkeit von K3s für „echte“ Workloads und Nutzung zu begründen.
Dies ist allerdings nicht richtig – bereits im zweiten Beispiel verwendet K3s ein hochverfügbares, automatisch für uns verwaltetes etcd Cluster, das automatisch auf den Controlplanenodes mitläuft. Alternativ lässt sich auch ein externes etcd Cluster referenzieren oder via K3s dedizierte etcd-Nodes erstellen.
Doch damit nicht genug: Ist ein Team erfahrener im Umgang mit einer relationalen Datenbank wie MySQL oder PostgreSQL, kann dank kine auch diese Möglichkeit für ein externes, hochverfügbares Datenbackend in Betracht gezogen werden.
So ließe sich entgegen gängiger Praxis auch ein hochverfügbares K3s-Cluster mit nur zwei Nodes umsetzen, da die ungerade Anzahl an Controlplane-Nodes lediglich für ein etcd-Quorum benötigt wird.
Mehr Informationen zum Thema Hochverfügbarkeit und externe Datenbackends für K3s finden sich in der K3s-Dokumentation.
„K3s ist zu opinionated“
Wie bereits bei der beispielhaften Installation von K3s gesehen, werden von Anfang an einige Dienste im Cluster installiert, darunter so essentielle Komponenten wie Traefik als IngressController. Diese Vorgaben erfreuen nicht jeden – manche Organisationen haben klare Vorgaben, welche Tools zu nutzen sind, und welche Konfiguration zu verwenden ist.
K3s erlaubt es, alle vorkonfigurierten Komponenten jederzeit zu deaktivieren. Das ist durch eine einfache Umkonfiguration möglich, die in der K3s-Dokumentation ausführlich beschrieben wird.
Auf ähnliche Weise ließen sich sogar beliebige andere Manifeste bei Initialisierung eines K3s-Clusters installieren. Man muss also weder auf Flexibilität und eigene Vorlieben und Voraussetzungen verzichten, noch das Rad neu erfinden – K3s bietet genug Möglichkeiten zur Integration.
K3s – eine Option für dein nächstes Projekt?
Egal ob „Kubernetes on the edge“, im Homelab, oder einfach als Ressourcen und Geld sparende Alternative für Dein nächstes Kubernetes-Cluster in der Cloud – K3s könnte eine Alternative sein. Mit seinem Fokus auf einfache Einrichtung, flexibler Konfiguration und vielfältiger Integrationsmöglichkeiten ist es die perfekte Wahl für Test- und CI/CD-Umgebungen, kleinere Projekte, oder Proofs of Concept (POCs).
In der MyNWS Cloud kannst du ein hochverfügbares K3s-Cluster basierend auf OpenStack z.B. bereits für unter 50€ pro Monat betreiben. Alternativ lässt sich K3s auch auf Single Board Computern (SBCs) oder Raspberry Pis betreiben. Die Grenzen der Möglichkeiten ergeben sich alleine durch deine Kreativität und Experimentierfreudigkeit!
Wir bei NWS sind gespannt, welches Projekt du als nächstes mit Kubernetes und K3s angehen wirst!
0 Kommentare