Komponenten · Konsole und Werkzeuge

okadm

Das Deployment-CLI: plan, install, upgrade, status, uninstall; kind-Labor oder Produktion.

Go client-go, Helm SDKopenkeel-okadm

Das Modul

okadm checks, installs and upgrades OpenKeel on an existing Kubernetes cluster, with one command per lifecycle step:

okadm plan    --mode lab                         # does the cluster meet the prerequisites? what is missing, how to fix it
okadm install --mode lab                         # no cluster configured: offers to create a kind cluster
okadm upgrade --version 2026.2.1                    # one component at a time, in dependency order
okadm install --mode lab --create-kind --ingress  # kind with 127.0.0.1:80/443 forwarded, Traefik, the console at http://skyline.127.0.0.1.nip.io
okadm status                                     # installed version, Helm releases, state of their pods
okadm uninstall --yes                            # components, then data services; volumes kept unless --purge
okadm install --component csi-tester --pure-endpoint fa.example.org --pure-api-token-file ./api-token
                                                 # only the FlashArray CSI driver and its test application

Go module: github.com/openkeel/openkeel-okadm, binary okadm (cmd/okadm)
Built on cobra, k8s.io/cli-runtime (kubectl connection flags), client-go and the Helm 3 Go SDK; no kubectl or helm binary is needed
The release manifest (which component version makes up each OpenKeel version) is embedded: internal/manifest/releases.yaml

Auszug aus openkeel-okadm/README.md (auf Englisch).

Wie die Kompatibilität getestet wird

okadm implementiert keine OpenStack-API neu: Seine Tests prüfen die erzeugten Charts und Installationen, und die damit installierten Clouds werden mit echten OpenStack-Clients geprüft.

Unit- und Golden Tests

Unit-Tests und echtes Chart-Rendering

Pläne, Werte und Installationsschritte mit Fake-Kubernetes-Clients und einem Fake-Helm-Releaser; das echte Umbrella-Chart wird mit den Werten von okadm in beiden Modi gerendert.

Ausführung

make test (go vet, go test -race -cover ./...), einschließlich TestRealChartRenders.

Quelle: openkeel-okadm/README.md

End-to-End in einem Lab

Installation auf einem neuen kind-Cluster

Das Binary allein erstellt den Cluster und installiert Operatoren, Infrastruktur, Keystone und Placement.

Ausführung

okadm install --mode lab --components keystone,placement mit --create-kind, eingebetteten Charts und Manifesten.

Letztes Ergebnis Alles Ready, Exit-Code 0; ein zweiter Durchlauf lädt die Images erneut und behält ihre Tags.

Quelle: openkeel-okadm/README.md

End-to-End in einem Lab

Echte Clients in einem mit okadm installierten Lab

ok und die Python-openstack-CLI führen Lesebefehle über jeden von okadm installierten Dienst aus.

Ausführung

okadm install --mode lab, danach beide CLIs nebeneinander.

Letztes Ergebnis 37 / 42 Lesebefehle identisch (2026-11-02).

Quelle: openkeel-ok/docs/CONFORMANCE.md

Client-Vertrag

Load-Balancer-Endpoint mit openstacksdk

Der von okadm registrierte Katalogeintrag load-balancer funktioniert mit openstacksdk und echten Keystone-Tokens: LB auf ACTIVE, Listener, Pool, Member, kaskadierendes Löschen.

Ausführung

okadm install auf kind mit --components ovn-octavia-provider.

Letztes Ergebnis Bestanden (2026-11-01); keine Datenebene in diesem Modus.

Quelle: openkeel-neutron/docs/CONFORMANCE.md

Im Rewrite ausgelassen

okadm stellt OpenKeel aus einem einzigen Go-Binary auf einem bestehenden Kubernetes-Cluster bereit und überlässt die Host-Vorbereitung, die hostseitige Datenebene und die von Hand verwaltete Infrastruktur Kubernetes und seinen Operatoren.

Von der Cloud-Native-Plattform übernommen

Host-Vorbereitung per SSH und Ansible-Inventar

Übernommen von Kubernetes

Warum es ausgelassen wurde

OpenKeel zielt auf einen bestehenden Cluster (oder einen kind-Cluster im Lab-Modus); okadm plan prüft die Voraussetzungen und gibt für jede fehlende den passenden Befehl aus.

Warum die Lösung nicht beeinträchtigt ist

Nichts wird per SSH auf den Hosts installiert; Knoten benötigen nur ihre Kubernetes-Rollen-Labels.

Quelle: openkeel-okadm/README.md

Von der Cloud-Native-Plattform übernommen

libvirt- und OVS-Agenten auf den Hosts

Übernommen von KubeVirt, OVN, CSI

Warum es ausgelassen wurde

Die Datenebene besteht aus Kubernetes-Komponenten: KubeVirt und CDI, Kube-OVN oder OVN sowie CSI-Speicher.

Warum die Lösung nicht beeinträchtigt ist

okadm installiert oder prüft diese Komponenten; VMs, Netzwerke und Volumes laufen als Cluster-Workloads.

Quelle: openkeel-okadm/README.md

Von der Cloud-Native-Plattform übernommen

Von Hand bereitgestellte MariaDB, RabbitMQ und Memcached

Übernommen von Kubernetes-Operatoren

Warum es ausgelassen wurde

Operatoren betreiben MariaDB Galera und RabbitMQ (kein Memcached: kein Go-Dienst braucht es); okadm erzeugt pro Komponente Datenbanken, Benutzer, vhosts und generierte Secrets.

Warum die Lösung nicht beeinträchtigt ist

Keine Passwortdatei zu pflegen; jede Komponente erhält ihre eigenen Zugangsdaten in Kubernetes-Secrets.

Quelle: openkeel-okadm/README.md

Vereinfachte interne Mechanik

Werkzeugkette aus Python, Ansible und helm oder kubectl

Warum es ausgelassen wurde

okadm enthält client-go, das Helm-3-SDK, die Charts und das Release-Manifest.

Warum die Lösung nicht beeinträchtigt ist

Installation, Upgrade, Status und Deinstallation laufen aus einem Binary; nur Container-Images werden heruntergeladen.

Quelle: openkeel-okadm/README.md

Hier ist nur aufgeführt, was bewusst ausgelassen wurde; noch nicht erledigte Arbeit steht in den Known gaps der docs/CONFORMANCE.md des Moduls. Alle Module

Ebenfalls in Konsole und Werkzeuge

Skyline

Ein einziges Go-Binary: die Konsolen-API, die Dateien der React-Konsole und ein Proxy zum Keystone-Katalog.

GoUpstream-React-Konsole

ok (CLI)

Der OpenStack-Client: die Befehle von python-openstackclient 10.3.1 und seinen Plugins, mit denselben Argumenten, Ausgaben und Exit-Codes.

GoStatisches Go-Binary