RKEasy
Reproduzierbare RKE2-Kubernetes-Cluster über Bare Metal, vSphere, OpenStack und Cloud hinweg, automatisiert mit Ansible.
- Ansible
- RKE2
- Kubernetes
- IaC
Problem
RKE2-Cluster von Hand oder mit Ad-hoc-Skripten pro Umgebung aufzusetzen ist fehleranfällig und schwer reproduzierbar – jede Infrastruktur (Bare Metal, vSphere, OpenStack, Cloud) bekommt am Ende ihre eigene, leicht abweichende Vorgehensweise, was Wartung und Konsistenz über mehrere Cluster hinweg erschwert.
Kontext & Rahmenbedingungen
Open-Source-Projekt, inspiriert von Kubespray, komplett auf Ansible-Playbooks aufgebaut. Muss unterschiedliche Infrastruktur-Backends unterstützen (Bare Metal, vSphere, OpenStack, AWS und weitere) und dabei für unterschiedliche Linux-Distributionen funktionieren.
Meine Verantwortung
Alleiniger Autor: Design der Playbook- und Inventory-Struktur, Implementierung, Dokumentation und laufende Weiterentwicklung.
Lösungsweg & Architektur
- Inventory-getriebene Konfiguration: `inventory/sample` wird pro Cluster kopiert (z.B. `inventory/mycluster`) und über `group_vars` angepasst
- Getrennte Playbooks für Aufbau (`deploy_cluster.yml`) und Rückbau (`remove_cluster.yml`) eines Clusters
- Konfigurierbare Node-Rollen (Control-Plane/Worker), Pod-/Service-Netzwerk und Storage-Backend (z.B. Longhorn) pro Inventory
- Nutzt `ansible.utils` als Collection-Abhängigkeit für konsistente Netzwerk-/Datenverarbeitung über Playbooks hinweg
Wichtige Entscheidungen & Trade-offs
- Ansible statt eigenem CLI-Tool oder Operator – agentless, breit bekanntes Werkzeug, passt zum bestehenden Ops-Workflow; dafür weniger abstrahiert als eine dedizierte Steuerungsebene
- Eigenes Inventory-Verzeichnis pro Cluster statt einer gemeinsamen Konfiguration – hält Cluster strikt isoliert und reproduzierbar, auf Kosten von etwas mehr Duplikation zwischen Inventories
- Unterstützung mehrerer Infrastruktur-Backends über Ansibles Inventory-/Plugin-Flexibilität statt festverdrahteter Provider-Logik
Ergebnis
Unterstützt heute HA-Cluster-Aufbau über Bare Metal, vSphere, OpenStack und mehrere Cloud-Umgebungen hinweg mit derselben Playbook-Basis. Auf der Roadmap stehen u.a. weitere Cloud-Provider sowie eingebautes Monitoring/Logging/Security-Tooling.
Was ich heute anders machen würde
Automatisierte Tests für die Playbooks (z.B. mit Molecule) und ein schlankerer CLI-Wrapper um die rohen `ansible-playbook`-Aufrufe herum stehen noch aus – die würde ich heute früher einbauen, um den Einstieg für andere Nutzer:innen leichter zu machen.