Nach der Theorie kommt die Praxis: Wir starten einen lokalen Kubernetes-Cluster und hissen die Nubus-Flagge – für zentrales Identity & Access Management im Testbetrieb. Falls Sie den ersten Teil verpasst haben: Dort erklären wir, wie Kubernetes funktioniert und wer im Cluster das Steuer in der Hand hat.
Im ersten Teil unserer kleinen Serie haben wir erklärt, wie Kubernetes funktioniert, welche Aufgaben es übernimmt und wer im Cluster das Steuer in der Hand hält. Jetzt wird’s praktisch: In diesem Artikel zeigen wir Ihnen, wie Sie Kubernetes lokal auf Ihrem Rechner zum Laufen bringen – ganz ohne Cloud, ganz ohne Serverfarm.
Wir setzen gemeinsam einen Test-Cluster mit kind auf, installieren einen Ingress-Controller und lassen zum Schluss Nubus für Kubernetes vom Stapel laufen – unsere Open-Source-Lösung für zentrales Identity & Access Management.
Inhaltsverzeichnis
Alles an Bord? Voraussetzungen für Ihre lokale Testumgebung
Bevor wir ablegen, brauchen wir ein wenig Ausrüstung. Für die folgende Anleitung genügt ein Linux-System mit 64-Bit-Prozessor (Intel, AMD oder ARM). Auch ältere Maschinen sind kein Problem: Jede gängige Linux-Distribution der letzten fünf Jahre ist geeignet. Getestet haben wir das Setup mit Ubuntu 24.04 auf einem Intel/AMD-System. Alternativ funktioniert das Ganze auch auf einem UCS 5-System oder in einer virtuellen Maschine unter Windows oder macOS.
Ihr System sollte mindestens 6 GByte RAM und 12 GByte freien Speicherplatz mitbringen – dann läuft der lokale Kubernetes-Cluster stabil.
Hinweis: Diese Installation ist für Testzwecke gedacht! Sie setzen hier einen lokalen Kubernetes-„Cluster“ auf, der nur auf einem einzigen Rechner – einem sogenannten Node – läuft. Das ist ideal zum Ausprobieren, aber natürlich nicht vergleichbar mit einem hochverfügbaren Produktivsystem.
Testfahrt – Kubernetes lokal ausprobieren mit kind
Bevor Sie Kubernetes im großen Stil einsetzen, lohnt sich ein Blick in die Praxis: Wie fühlt sich das Arbeiten mit einem Cluster an? Wie lassen sich Anwendungen installieren, konfigurieren, skalieren und beobachten? Zum Glück brauchen Sie dafür kein eigenes Rechenzentrum – ein Notebook reicht.
Mit kind (Kubernetes in Docker) lässt sich ein vollständiger Kubernetes-Cluster auf Ihrem lokalen System starten – schlank, schnell und perfekt zum Ausprobieren. kind nutzt Docker-Container, um einen oder mehrere Kubernetes-Nodes zu simulieren. So können Sie ganz in Ruhe testen, ohne eine Cloud oder VM-Infrastruktur aufsetzen zu müssen.
Damit es losgehen kann, brauchen Sie ein paar Werkzeuge auf Ihrem System:
- Docker: Laufzeitumgebung für die kind-Container
- kubectl: das Kommandozeilenwerkzeug, um mit dem Cluster zu sprechen
- Helm: der Paketmanager für Kubernetes-Anwendungen
- kind: startet den Cluster
- jq: ein kleines Hilfsprogramm zur Verarbeitung von JSON-Daten
Hinweis: Die genaue Installationsanleitung für diese Werkzeuge – etwa unter Ubuntu oder UCS – finden Sie in unserem Artikel Install Nubus for Kubernetes on your notebook in 20 minutes.
Schicht für Schicht – der Aufbau Ihres Mini-Clusters
Quelle: Univention Help Forum
Was auf den ersten Blick vielleicht komplex klingt, ist in Wahrheit elegant ineinander verschachtelt – wie bei einer russischen
Matroschka. Ganz außen: Ihre reale Hardware oder eine virtuelle Maschine. Darauf läuft ein Linux-Betriebssystem. In einem Docker-Container startet kind dann den lokalen Kubernetes-Cluster. Und innerhalb dieses Clusters befinden sich Ihre Anwendungen, z. B. Nubus, das aus rund 25 einzelnen Pods bzw. Containern besteht.
Diese Struktur macht es möglich, Kubernetes inklusive realitätsnaher Anwendungen wie Nubus komplett lokal zu testen – ohne dedizierte Server oder Cloud-Infrastruktur.
Leinen los – Ihren Kubernetes-Cluster starten mit kind
Jetzt, wo alle Werkzeuge installiert sind, fehlt nur noch der Cluster selbst. Den starten Sie mit kind – und zwar ganz einfach per Kommandozeile. Damit Sie später auch von außen auf Ihre Anwendungen im Cluster zugreifen können (z. B. per Webbrowser), definieren wir gleich die nötigen Portweiterleitungen für HTTP und HTTPS mit. Speichern Sie dafür die folgende Konfiguration in einer Datei namens kind-cluster-config.yaml:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
kubeadmConfigPatches:
- |
kind: InitConfiguration
nodeRegistration:
kubeletExtraArgs:
node-labels: "ingress-ready=true"
extraPortMappings:
- containerPort: 80
hostPort: 80
protocol: TCP
- containerPort: 443
hostPort: 443
protocol: TCP
Diese Konfiguration nutzt die Standardports 80 (HTTP) und 443 (HTTPS) auf Ihrem System. Falls dort bereits ein Webserver läuft, kommt es zu Konflikten. In diesem Fall können Sie stattdessen z. B. 8000 und 8443 verwenden – müssen dann aber einen Reverse Proxy wie Apache oder Nginx einrichten, der die Anfragen weiterleitet. Das ist auch nötig, wenn Sie mehrere Nubus-Instanzen parallel betreiben möchten.
Für die einfache Testfahrt genügt die Standardkonfiguration – solange die Ports frei sind, können Sie direkt loslegen. Wir nennen den Cluster im weiteren Verlauf nubus – passend zur Anwendung, die wir gleich darin installieren. Natürlich können Sie den Namen auch frei wählen.
Zum Start geben Sie folgenden Befehl ein:
kind create cluster --name nubus --config=kind-cluster-config.yaml
Nach kurzer Zeit ist der Cluster einsatzbereit – inklusive Netzwerkzugriff über die üblichen Webports. Prüfen können Sie das mit:
kubectl cluster-info --context kind-nubus
Wenn alles geklappt hat, sehen Sie die URLs für den Kubernetes-API-Zugriff. Sie haben jetzt ein echtes Kubernetes-Labor auf Ihrem Notebook – perfekt für Experimente, erste Deployments und für den ersten Testeinsatz mit Nubus.
Sicher anlegen – Ingress-Controller für den Zugang von außen
Ein Kubernetes-Cluster läuft erstmal für sich allein – wie ein Schiff ohne Hafen. Von außen ist nichts erreichbar. Damit Sie später Webanwendungen wie Nubus im Browser öffnen können, braucht Ihr Cluster einen Ingress-Controller. Dieser sorgt dafür, dass Anfragen von außen (z. B. an Port 80 oder 443) an die richtigen Container im Inneren weitergeleitet werden.
In unserem Fall setzen wir auf den bewährten Nginx Ingress Controller, – eine Referenzimplementierung der Kubernetes-Community, die direkt von Nubus unterstützt wird. (Achtung: ingress-nginx, nicht nginx-ingress! Die Namensähnlichkeit führt oft zu Verwechslungen.) Installieren Sie den Controller einfach per Helm:
helm upgrade --install ingress-nginx ingress-nginx \
--repo https://kubernetes.github.io/ingress-nginx \
--namespace ingress-nginx \
--create-namespace \
--version "4.8.0" \
--set controller.allowSnippetAnnotations=true \
--set controller.config.hsts=false \
--set controller.service.enableHttps=false \
--set controller.hostPort.enabled=true \
--set controller.service.ports.http=80
Nach kurzer Zeit läuft ein neuer Pod im Cluster, der auf Anfragen wartet:
kubectl get pods -A
In der Ausgabe sehen Sie unter anderem:
NAMESPACE NAME READY STATUS RESTARTS AGE ingress-nginx ingress-nginx-controller[…] 1/1 Running 0 3m19s kube-system coredns-668d6bf9bc-6hwlb 1/1 Running 0 3m41s # ...
Damit ist Ihr Cluster nun auch von außen erreichbar – bereit für die erste richtige Anwendung: Nubus für Kubernetes.
Volle Kraft voraus – Nubus im Cluster installieren
Jetzt, wo Ihr lokaler Kubernetes-Cluster läuft und von außen erreichbar ist, wird’s spannend: Wir installieren Nubus für Kubernetes. Bevor es losgeht, laden Sie die Konfigurationsdatei für Nubus herunter:
export VERSION="1.8.0"
curl --output custom_values.yaml "https://raw.githubusercontent.com/univention/nubus-stack/v${VERSION}/helm/nubus/example.yaml"
Sie können die Datei custom_values.yaml direkt so verwenden – oder an Ihre Umgebung anpassen und die dazu passenden Werte für baseDn, domainName und domain eintragen. Für einen ersten Test reicht die Standardkonfiguration mit example.com.
Jetzt wird Nubus über das sogenannte Umbrella Helm Chart installiert. Ein Helm Chart ist so etwas wie ein Bauplan für Kubernetes-Anwendungen: Es beschreibt, welche Dienste, Konfigurationen und Abhängigkeiten nötig sind – und wie sie im Cluster bereitgestellt werden. Das Umbrella Chart für Nubus bündelt dabei alle Einzelkomponenten – von Keycloak über LDAP bis hin zu Portal und APIs – und sorgt dafür, dass alles einheitlich konfiguriert und in der richtigen Reihenfolge gestartet wird.
export VERSION="1.8.0" export NAMESPACE_FOR_NUBUS=default export RELEASE_NAME=nubus helm upgrade \ --install \ --namespace="$NAMESPACE_FOR_NUBUS" \ --values custom_values.yaml \ --version "$VERSION" \ --timeout 20m \ "$RELEASE_NAME" \ oci://artifacts.software-univention.de/nubus/charts/nubus
Je nach Geschwindigkeit Ihrer Internetverbindung und Festplatte dauert das bis zu zehn Minuten. Danach sehen Sie eine Meldung wie:
[…] NAME: nubus LAST DEPLOYED: Tue Mar 17 17:09:00 2025 NAMESPACE: default STATUS: deployed REVISION: 1 NOTES: Thank you for installing nubus.
Maschinenraum hochfahren – was im Cluster gerade passiert
Nach der Installation läuft im Hintergrund einiges an – und zwar in Form vieler kleiner Dienste, die als Pods im Cluster gestartet werden. Diese Pods sind die Betriebscrew Ihres Nubus-Systems: Keycloak sorgt für Authentifizierung, LDAP hält die Identitäten bereit, verschiedene APIs kümmern sich um Provisionierung, Selbstverwaltung und vieles mehr.
Ein Blick auf die laufenden Pods zeigt Ihnen den aktuellen Status:
kubectl get pods NAME READY STATUS RESTARTS AGE nubus-keycloak-0 1/1 Running 5 (3m19s ago) 6m55s nubus-keycloak-bootstrap-[…] 0/1 Completed 0 6m54s nubus-ldap-notifier-0 0/1 CrashLoopBackOff 3 (31s ago) 6m55s nubus-ldap-server-primary-0 0/1 Running 0 6m54s nubus-ldap-server-proxy-[…] 0/1 Init:3/5 0 6m54s nubus-ldap-server-secondary-0 0/1 Init:4/5 0 6m55s […]
Keine Sorge, wenn nicht alles sofort rund läuft: Einige Dienste brauchen etwas Zeit zum Hochfahren oder hängen von anderen Komponenten ab. Es ist völlig normal, dass manche Pods zunächst im Zustand Init oder CrashLoopBackOff erscheinen. Kubernetes versucht automatisch, sie neu zu starten, sobald ihre Abhängigkeiten verfügbar sind. Nach ein paar Minuten pendelt sich alles ein.
Kapitän an Deck – Erste Anmeldung vorbereiten
Während sich die Dienste im Cluster noch sortieren, können Sie schon mal den Zugang für den ersten Login vorbereiten. Nach der Installation legt Nubus automatisch einen Benutzer Administrator an – mit allen nötigen Rechten für die Verwaltung.
Das Passwort holen Sie sich ganz einfach mit diesem Befehl ins Terminal:
kubectl -n default get secret nubus-nubus-credentials -o json | jq -r '.data.administrator_password' | base64 -d; echo b30665941288528735bf8aa04655188c1328509b
Falls Sie in der Datei custom_values.yaml keinen eigenen Wert für nubusMasterPassword gesetzt haben, erhalten Sie hier das automatisch generierte Standardpasswort. Dieses brauchen Sie gleich bei der Anmeldung im Browser.
Ziel anvisieren – DNS für Ihren ersten Login
Damit Sie Nubus bequem im Browser aufrufen können, muss Ihr System wissen, wohin die Adresse wie z. B. id.example.com zeigt. In echten Umgebungen übernimmt das ein DNS-Server. Für unseren lokalen Test reicht ein einfacher Trick: Wir tragen die passenden Namen in die Datei /etc/hosts ein. Fügen Sie dazu am Ende der Datei folgenden Eintrag hinzu:
127.0.0.1 id.example.com portal.example.com
Falls Sie in Ihrer values.yaml andere Domainnamen verwendet haben, passen Sie die Werte entsprechend an.
Jetzt können Sie im Browser die Portale öffnen:
- https://id.example.com – für Self-Services & Anmeldung
- https://portal.example.com – für den Zugriff auf die Nubus-Oberfläche
Das SSL-Zertifikat ist selbstsigniert – Ihr Browser wird Sie also warnen. Sie können die Ausnahme aber gefahrlos bestätigen. Beim ersten Login verwenden Sie den Benutzer Administrator. Das Passwort haben Sie im vorherigen Schritt per kubectl aus dem Secret ausgelesen.
Wenn’s knarzt im Gebälk – Tipps fürs Troubleshooting
Auch in einer gut konfigurierten Testumgebung kann es zu kleineren Problemen kommen – etwa, wenn ein Dienst nicht startet oder im Status CrashLoopBackOff hängen bleibt. In solchen Fällen helfen die Bordmittel von Kubernetes, um herauszufinden, wo es klemmt.
Nutzen Sie diesen Befehl, um die Logs eines Deployments anzuzeigen:
kubectl logs [-f] <object>
Das -f steht für „follow“ – die Logs werden live aktualisiert, ähnlich wie bei tail -f. Ersetzen Sie <object> einfach durch den Namen des gewünschten Deployments oder StatefulSets:
- UDM REST API:
kubectl logs -f deployments/nubus-udm-rest-api - Portal-Frontend:
kubectl logs -f deployments/nubus-portal-frontend - LDAP-Server (StatefulSet):
kubectl logs -f statefulsets/nubus-ldap-server-primary
Tipp: Tippen Sie kubectl logs und drücken zweimal die Tabulatortaste – so zeigt Ihnen die Shell automatisch alle verfügbaren Ressourcen an.
Klar Schiff machen – wenn Sie neu starten möchten
Ihr Testlauf war erfolgreich? Dann können Sie Nubus jetzt weiter ausprobieren – oder das Setup aufräumen. Wenn Sie nur Nubus entfernen möchten, ohne den Kubernetes-Cluster anzutasten, genügt der Befehl helm uninstall nubus. Der Cluster selbst bleibt dabei bestehen, und Sie können ihn für weitere Tests nutzen.
Falls Sie komplett von vorn beginnen möchten, löschen Sie den gesamten Cluster mit kind delete clusters nubus. Dabei wird der zugrunde liegende Docker-Container gestoppt und alle zugehörigen Volumes entfernt – belegter Arbeitsspeicher und Speicherplatz auf der Festplatte werden wieder freigegeben.
Das verwendete Docker-Image bleibt jedoch auf Ihrem System erhalten. So sparen Sie beim nächsten Start Zeit, weil es nicht erneut heruntergeladen werden muss. Möchten Sie auch das entfernen, zeigt Ihnen das Kommando docker images die Image-ID – diese löschen Sie anschließend mit docker rmi <IMAGE-ID>.
Land in Sicht – und wie es weitergeht
Mit diesem Artikel haben Sie den Grundstein gelegt: Ihr Kubernetes-Cluster läuft lokal, ist erreichbar und beherbergt mit Nubus eine vollständige IAM-Lösung für Container-Umgebungen. Die Reise durch Ihre Infrastruktur hat damit gerade erst begonnen – jetzt können Sie ganz in Ruhe die Funktionen von Nubus erkunden, Benutzer anlegen, Gruppen verwalten und sich mit der Oberfläche vertraut machen.
Ob Sie Nubus in einer Schulumgebung, einer Verwaltung oder in einem Rechenzentrum einsetzen wollen – der Test-Cluster bietet den perfekten Rahmen zum Ausprobieren. Wenn Sie Nubus später produktiv einsetzen möchten, lohnt sich ein Blick ins offizielle Nubus for Kubernetes – Operation Manual – dort finden Sie alle Details für den Einsatz in echten Produktionsgewässern.
