Der Entwickler von Portfolio Perfomance hat die Arbeit and seinem freien Softwareprojekt einst als »Therapeutisches Programmieren« beschrieben. Die Idee dahinter ist, dass es bisweilen wohltuend ist, ein technisches Projekt zu bearbeiten, an dem man selbst alle gestalterischen Entscheidungen trifft, und einem keine Einschränkungen auferlegt werden. Man kann sich ganz auf das vorliegende Problem konzentrieren, ohne dass Zeitdruck oder Einflußnahme von Außen, die Freude und den Entdeckungsprozess schmälern. Ich habe viel über die Werkzeuge, welche ich in meiner Arbeit verwende, gelernt, indem ich einen Nutzen für sie in meiner Freizeit gefunden habe. Normalerweise stoße ich zwangsläufig auf die Notizen und Dokumentation anderer Leute, die genau das Selbe tun, was immer sehr hilfreich war. Also werde ich, um diese schöne Tradition zu pflegen dokumentieren, wie ich mein eigenes kleines Heimrechenzentrum einrichte.
Mir schwebte ein Aufbau vor, der gut von Automatisierung und deklarativer Infrastrukturbeschreibung profitieren kann, sodass ich ihn leicht wiederaufbauen kann, wenn Üble Dinge geschehen. Was die Anwendungen betraf, die auf der Infrastruktur laufen sollten, war mir schon klar, dass sie ein gewisses Maß an Instabilität verkraften können müssen, sowohl, weil ich zum Werkeln tendiere, als auch weil alte Hardware in meiner Umgebung ständig wiederverwendet wird, sodass der ein oder andere Ausfall früher oder später recht wahrscheinlich ist. Das macht Kubernetes sehr interessant für mich, weil es entworfen ist, um etwas Instabilität zu tolerieren. Ganz zu schweigen davon, dass es mir gestattet, die Arbeit, welche andere Leute auf das Schreiben von Kubernetesdeployments für all die großartigen Anwendungen, die es in der weiten Welt gibt, zu nutzen.
Falls mein geneigter Leser wissen möchte, warum ich das eine oder andere Werkzeug verwende, folgt eine kurze Erklärung im nächsten Absatz. Er möge aber bedenken, daß es sich hierbei um ein Freizeitprojekt handelt, welches vor allem dazu entworfen ist, mir zu gefallen.
Proxmox
Ich wollte wegen der häufigen neuen Versionen nicht für die Installation und Wartung von physichen Kubernetes Hosts zuständig sein. VMs sind zunächst leichter mit VM-Abbildern zu automatisieren, was aber nicht heißen soll, dass ich abgeneigt wäre, in Zukunft einen Image-basierten Ansatz zu versuchen. Darüber hinaus wollte ich eine Virtualisierungsumgebung, die ihren Dienst tut, ohne dass sie regelmäßig gehegt und gepflegt werden will, da ich der einzige sein werde, der sie warten wird (dementsprechend war OpenStack keine Option). Irgendeine proprietäre Lösung war auch kein gangbarer Weg, da ich keine nebulöse Organisation mit am Tisch haben möchte, wenn es darum geht, wie ich meine Infrastruktur verwende. Dadurch wurde die Entscheidung she einfach. Ich habe schon seit Jahren einen Proxmox-Server, dessen einziger Zweck es war, einen NFS-Server und verschiedene LXC Container in meinem Heimnetzwerk bereitzustellen, und Proxmox ist schlicht gleaufen und hat seinen Zweck erfüllt. Eine weitere schöne Eigenschaft ist die Hilfeleistung, die es beim Installieren und Betreiben von Ceph liefert.
Diese Artikelreihe geht davon aus, dass eine Proxmoxinstallation vorhanden ist. Falls das nicht der Fall sein sollte, sollte man sich darum zuerst kümmern.
Kubernetes
Ohne dies gäbe es nicht viel zu diesem Projekt zu schreiben. Es gibt viele Kubernetesdistributionen und dedizierte Betriebssysteme wie Talos oder Flatcar. Letztere sind hervorragend, um die beweglichen Tele und Risiken, dass ahnungslosen Händen etwas zu Bruch geht, zu reduzieren (und ich denke, dass ich sicherlich die eine oder andere dieser Varianten in der Zukunft testen will), aber ich will in der Lage sein, Dinge selbst zu verändern und zu Bruch gehen zu lassen, um dabei zu lernen. Deswegen werde ich mich zunächst auf das image-builder-Projekt verlassen, um standardisierte Kubenertes-VM-Abbilder zu produzieren. Es ist etwas umfangreicher, als der Bauprozess, den ich zuvor gesehen habe, aber es kommt von der Stange, und das gefällt mir.
Weitere Komponenten
- Cluster API kenne ich bereits, deswegen war es meine erste Wahl, wenn es darum ging, wie der Cluster verwaltet werden soll. Mir gefällt, dass es nicht so voreingenommen ist, wie OKD, wenn es darum geht, wie ein Kubernetes-Cluster aufgesetzt werden soll, und auch nicht voller Funktionen ist, die ich noch nicht brauche, wie Rancher. Auf Gardener habe ich auch einen Blick geworfen, um zu sehen, ob mir irgendwelche großartigen Funktionalitäten entgingen, aber mir fiel nichts offensichtliches auf.
- Mir war kube-vip noch nicht geläufig, als ich anfing dieses Projekt zu planen, es kam schlicht mit den Standardressourcen für den Cluster-API-Provider in Proxmox daher. Aber das war sehr günstig, denn es löste praktischerweise die Frage, wie ich denn die Lastverteilung für den Kubernetescluster bewerkstelligen wollte, ohne auf irgendwelche externen Dienste zurückgreifen zu müssen. Stattdessen läuft kube-vip als Pod in Kubernetes und arrangiert die Vergabe von virtuellen IP-Adressen auf den Knoten so, wie sie gebraucht werden.
- BGP erweiterte Netzwerksicherheit waren Funktionalitäten, die ich gerne nutzen wollte (ich bin recht sicher, dass ich früher oder später mit Rechenzentrumsswitchen arbeiten möchte). Cilium bietet mir dies, und vertraut ist es mir auch schon. Wenn Calico mit irgendeinem sagenhaften neuen Argument daherkommt, warum ich es einsetzen sollte, habe ich ein unterhaltsames Migrationsprojekt, aber für den Anfang, habe ich Cilium ausgewählt um schneller vom Fleck zu kommen.
- Ich will meine Infrastruktur gerne nach GitOps-Prinzipien verwalten, damit ich sie schnell aktualisieren, neu erstellen oder deprovisionieren kann. Darum habe ich ArgoCD dafür ausgesucht, denn es liefert mir genau diese Funktionalität. Und obwohl ich üblicherweise die Kommandozeile bevorzuge, bin ich gelegentlich eine GUI gegenüber nicht abgeneigt. Und es hat ein sympathisches Maskottchen, das wie ein Oktopuswürstchen mit Astronautenhelm aussieht. Es kann gut sein, dass ich später einmal Flux zum Spaß ausprobiere.
Mehr in Bälde
Einige Monate sind bereits vergangen, seit ich anfing diese Artikelreihe zu schreiben, aber die grundlegende Infrastruktur ist da, ebenso wie ein Großteil des Inhalts für die Artikel. Es braucht eine Weile für mich, um zu testen und meine Rohschriften in etwas umzuwandeln, das ich für vorzeigenswert halte. Schauen wir mal, was die nächsten Wochen bringen; vieles gutes, hoffentlich, und davon den ein oder anderen Artikel meiner Serie.