Kubernetes 101: Welche Installationsmöglichkeiten bietet Kubernetes?

Nachdem wir uns in den vergangenen Artikeln bereits damit beschäftigt haben, was Kubernetes eigentlich ist, warum man es brauchen könnte und wie Kubernetes und seine API eigentlich funktionieren, juckt es dich inzwischen sicherlich in den Fingern, Kubernetes einmal selbst auszuprobieren.

Hierbei haben wir allerdings die Qual der Wahl – wie in vorangegangenen Blogposts bereits erwähnt, listet die CNCF fast 50 verschiedene Kubernetes-Distributionen auf ihrer Seite. Diese unterscheiden sich vor Allem durch ihren Fokus auf verschiedene Nutzergruppen oder Einsatzumgebungen voneinander:

• Lokal
• Auf Serverhardware oder in VMs
• In der Cloud
• “at the edge” oder im IoT-Bereich

Aus diesem Grund werde ich heute diese vier Anwendungsumgebungen etwas genauer beleuchten und für alle Domänen mögliche Installationskandidaten sowie zusätzliches, nützliches Tooling betrachten. Los geht’s!

Lokale Kubernetes-Installation

Kubernetes lokal zu installieren ist längst nicht so unsinnig, wie es zunächst scheinen mag – wie sinnvoll kann eine Container-Orchestrierung über mehrere Nodes hinweg auf einem Node schon sein? Die Antwort lautet: Sehr!

Für jeden Entwickler in einem Projekt ein eigenes Cluster auf firmeninterner Hardware oder in der Cloud zu provisionieren ist oftmals unrentabel, und eine lokale Kubernetes-Installation verhält sich zumindest ähnlich genug, um Feedback für die Entwickler zu geben. Auch für den Einsatz in CI/CD-Pipelines für Integrations- und End-to-End-Tests bietet sich die Installation eines “lokalen” Clusters zur Pipeline-Laufzeit an.

Welche Möglichkeiten zur Installation eines lokalen Clusters gibt es also? Hier ein kurzer Überblick:

• Docker Desktop – genau, richtig gelesen! Docker Desktop bietet bereits seit einigen Versionen die Möglichkeit, ein lokales Kubernetes-Cluster  in der momentan aktuellsten Version mit einem Node zu installieren. Hierfür wird im Hintergrund von Docker eine VM erstellt, in die dann Kubernetes und Tools für persistente Speicherverwaltung und Netzwerkanbindung des Clusters installiert werden. Docker Desktop kümmert sich darüber hinaus um die automatische Konfiguration der lokalen kubeconfig des Nutzers.
• Rancher Desktop – sehr ähnlich wie Docker Desktop, allerdings ohne Containerverwaltung – die GUI kümmert sich lediglich um die Konfiguration einer lokalen (versteckten) VM, in die ein Kubernetes-Cluster installiert wird, ebenfalls mit einem Node und zusätzlichen Onboard-Mitteln für Speicher und Netzwerk.
  Ebenfalls wie Docker Desktop kümmert sich auch Rancher Desktop um die automatische Konfiguration der lokalen kubeconfig. Ich persönlich bevorzuge von beiden Tools mittlerweile Rancher Desktop, da man hier nicht wie bei Docker Desktop auf die “aktuellste” Kubernetes-Version beschränkt ist.
• Minikube – Das Projekt wird von einer offiziellen Kubernetes SIG (Special Interest Group) entwickelt und maintained, im Gegensatz zu Docker/Rancher Desktop erlaubt einem Minikube eine deutlich erweiterte Konfiguration des Clusters auf Komponentenebene. Auch die Aktivierung verschiedener Updates wie Dashboards uvm. ist möglich.
• Microk8s – Microk8s ist eine von Canonical bereitgestellte Lösung für lokale Kubernetes-Installationen, die allerdings auch für die Installation “richtiger” Cluster über mehrere Nodes hinweg genutzt werden kann. Ähnlich wie bei Minikube können auch hier tiefergreifende Konfigurationen vorgenommen und Addons nach Bedarf an und ausgeschaltet werden.

Installation auf Hardware oder VMs

Hat man sich auf seinem lokalen Rechner oder Laptop ausgetobt, möchte man evtl. zum ersten Mal ein tatsächlich verteiltes Cluster als Proof of Concept oder sogar schon für den Produktionsbetrieb auf firmeneigener Hardware oder einer eigenen VM-Flotte einrichten. Neben dem bereits erwähnten Microk8s gibt es für dieses Szenario noch ein paar andere nennenswerte Möglichkeiten, sich ein Cluster einzurichten.

• kubeadm – das “offizielle” Tool zur Installation von Kubernetes. Es kann dazu genutzt werden, um ein Cluster und seine Komponenten analog zu dem Aufbau einzurichten, der im letzten Teil dieser Serie zu Cluster-Architektur beschrieben wurde – kubelet, etcd, und die anderen Bestandteile eines Clusternodes laufen hierbei als einzelne Systemservices. kubeadm kümmert sich um Dinge wie Zertifikatsgenerierung und erstmalige Einrichtung sowie das einfache Hinzufügen neuer Nodes in das Cluster. Diese Art der Installation eignet sich auch für eine automatisierte Umsetzung bspw. via Ansible.
• Rancher – ein Cluster-Management-Tool von SUSE, mit dem sich Cluster sowohl on-prem als auch in der Cloud erstellen und zentral verwalten lassen. Auf lokalen VMs oder Hardware lassen sich hierbei wahlweise Cluster auf der Basis von K3s oder RKE1/2, beides ebenfalls von SUSE verwaltete Kubernetes-Plattformen.
• K3s – gerade eben bereits erwähnt, lässt sich K3s auch außerhalb des Rancher-Kontexts hervorragend für Kubernetes-Installationen nutzen. K3s besticht durch seinen abgespeckten Umfang und die Bündelung aller benötigten Komponenten in eine ausführbare Datei, was die Installation und Verwaltung enorm erleichtern kann. Auch hier ist eine Automatisierung durch Dritttools wie Ansible möglich.

Installation in der Cloud

In der Cloud hat man endgültig die Qual der Wahl – (fast) jeder Cloudanbieter hat dieser Tage eine sog. “Managed Kubernetes”-Lösung im Angebot, die mit einigen Klicks bestellt werden kann und nach ein paar Minuten verfügbar ist. Am beliebtesten sind hier natürlich die “Big Three” (Google Cloud, AWS, Azure Cloud), bei denen man aber in den meisten Fällen auch mehr Geld lässt als bei kleineren Mitbewerbern. Es gilt also, Kosten und Nutzen abzuwägen, oftmals reicht eine Lösung von kleineren Cloudanbietern wie bspw. unser Managed Kubernetes by NWS.

Natürlich kann man sich auch in der Cloud einzelne Server provisionieren und sich mit den oben erwähnten Tools sein eigenes Cluster, losgelöst von den gemanagten Angeboten der Provider, bauen. Auch die Verteilung eines Clusters über mehrere Cloud-Anbieter hinweg für eine maximale Fehlertoleranz ist ein Modell, das in der Vergangenheit bereits umgesetzt wurde. “Die Cloud” bietet also vielfältige Möglichkeiten, Kubernetes-Cluster ganz nach Bedarf, erwartbaren Risiken und Problemen aufzubauen, um maximal flexibel zu bleiben.

Kubernetes at the Edge

Immer beliebter wird auch der Betrieb von kleinen Kubernetes-Clustern “at the edge”, also möglichst nahe beim Endnutzer. So hat bspw. die amerikanische Fastfood-Kette “Chick-Fill-A” in jeder ihrer Filialen ein 3-Node-Cluster in Betrieb, in Summe über 2500 Cluster. Auch für solche Anwendungszwecke möchte man eine möglichst robuste und einfach zu wartende Kubernetes-Lösung einsetzen. Zwei beliebte Optionen hierfür sind – einmal mehr und auch von Chick-Fill-A genutzt – K3s sowie Talos.

Talos wird von SideroLabs entwickelt und ist eher Betriebssystem als nur Kubernetes-Plattform, wenn man es genau nimmt. Es spinnt quasi den Gedanken von K3s, eine gebündelte, vorkonfigurierte Zusammenstellung aller Komponenten bereitzustellen, einen Schritt weiter, und stellt direkt das Betriebssystem. Dieses ist minimal gehalten und immutable, was die Sicherheit drastisch erhöht und die Größe der zu installierenden Software minimiert. Sämtliche Konfiguration des Nodes und der Kubernetes-Installation darauf wird via API-Zugriffen vorgenommen.

Choose your Fighter

Wie eingangs erwähnt, sind die verschiedenen Umsetzungsmöglichkeiten einer Kubernetes-Installation schier endlos – weswegen auch dieser Artikel keinen Anspruch auf Vollständigkeit erhebt. Er kann allerdings trotzdem eine gute Übersicht über einige der momentan populärsten Lösungen geben und entspricht auch den von mir favorisierten Tools, um Kubernetes-Cluster in verschiedenen Umgebungen umzusetzen. Ich kann nur empfehlen, sich mit einigen aufgelisteten Lösungen vertraut zu machen, um ein Gespür dafür zu entwickeln, wie sich der Umgang mit Kubernetes auf verschiedenen Distributionen und Plattformen voneinander unterscheidet, angefangen bei einer lokalen Installation mit Docker/Rancher, und fortgeführt im eigenen Rechenzentrum oder der Cloud.

Daniel Bodky

Platform Advocate

---

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und beriet zwei Jahre lang Kunden zu den Themen Icinga2 und Kubernetes, bevor es ihn weiter zu Managed Services zog. Seitdem redet und schreibt er viel über cloud-native Technologien und ihre spannenden Anwendungsfälle und gibt sein Bestes, um Neues und Interessantes rund um Kubernetes zu vermitteln. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Read more from Daniel and meet the Team