Ein Kunde wollte Untersützung für fortgeschrittene Datenverarbeitung und wissenschaftliche Recherchen in einem eigenen Cluster haben: er hatte sich für Kubeflow entschieden und um unsere Hilfe bei der Installation gebeten.

Was ist Kubeflow überhaupt? Wie der Name schon andeutet, ist es eine Plattform (eigentlich mehrere miteinander verbundenen Anwendungen), die Datenverarbeitung und KI (wie Tensorflow, Jupyter Notebooks, usw) in Kubernetes-Clustern einfach einsetzbar macht. Es wird quelloffen von Google entwickelt und der Öffentlichkeit bereitgestellt. Es gibt sogar Varianten für die Installation – falls diese Umgebungen bei großen Cloud-Anbietern laufen und nicht im eigenen Rechenzentren.

[Image: https://www.Kubeflow.org/docs/images/central-ui.png ]

Menge und Qualität der erreichbaren Dokumentation helfen aber leider nicht besonders viel: Wie man Kubeflow bei einem der großen Cloud-Anbieter zum Laufen kriegen kann, ist einfach: hier klicken, jenen Befehl ausführen: fertig. Aber sonst? Ziemlich wenige Ansatzpunkte. Einerseits verständlich: Google&Co würde es vermutlich gefallen, wenn die Anwendung auf ihrer Infrastruktur benutzt würde. Aber: KubeFlow ist Open Source, da sollte es auch unabhängig vom Unterbau lauffähig sein!

Auf der Webseite von Kubeflow gibt es mittlerweile auch andere Anleitungen, die ganze Plattform erfolgreich zu deployen. Aber auch die sind sehr spezifisch, meist für eine bestimmte Version und häufig von einem Betreiber für die eigene Plattform:

(Quelle: https://www.kubeflow.org/docs/started/installing-kubeflow/)

Im Ungarischen gibt es dafür eine passende Redewendung: man näht den Mantel zum Knopf. Hier also: wollen wir Kubeflow installieren, sollten wir am besten eine geeignete Plattform wählen.

Bei unserem Kunden ist die Plattform aber schon gegeben: RKE2 von SUSE/Rancher. Dieses Setup betreuen wir bereits eine Weile, und bisher hat das alles zu unserer großen Zufriedenheit funktioniert. Alle Cluster beim Kunden benutzen RKE2 – wir wollen doch unsere Cluster einheitlich halten. Und das taucht in der Liste nicht auf.

Die Lösung, die unseren Zielen am nächsten kommt, ist Argoflow: eine Installationsmöglichkeit mit ArgoCD, ein beliebter CI/CD-Assistant im Kubernetes-Umfeld. Auch diese Lösung konzentriert sich aber eher auf die bekannten Cloud-Umgebungen, und verwendet weitestgehend Kustomize. Das ist einerseits gut: man kann damit fein justieren, welche Ressourcen angelegt werden, und wie diese sich verhalten. Andererseits setzt das voraus, dass man schon weiß, wie die Landschaft aufgebaut ist, was alles benötigt wird und was man alles einrichten, um das gewünschte Ziel zu erreichen. Wir erinnern wieder an Umfang und Qualität der Dokumentation – keine gute Ausrüstung für den Anfang.

Unbedingt erwähnenswert sind ein hilfreicher Artikel bei Heise (https://www.heise.de/hintergrund/Machine-Learning-Kubeflow-richtig-einrichten-ein-Tutorial-6018408.html) und ein öffentliches Git-Repo (https://github.com/SoeldnerConsult/kubeflow-in-tkg-cluster) von Söldner Consult GmbH. Daraus ergaben sich einige nützliche Erkenntnisse, aber wieder schrammt das ein wenig an unserem Ziel vorbei. Die ganze Logik ist auf VMWare Tanzu angepasst.

Trotz dieser wertvollen Einsichten mussten wir also weiter recherchieren. Ziemlich sicher waren wir nicht die Ersten mit eben diesem Problem, jemand muss es schon gelöst bekommen haben.

Und tatsächlich gibt es eine Methode, die die Installation bequem und einfach erledigt, in unterschiedlichen Umgebungen und für unterschiedliche Szenarien, und die alle erforderlichen Komponenten sinnvoll einrichtet und verbindet. kfctl – kf für Kubeflow, ctl für Control und sehr beliebt im Kubernetes-Umfeld – wurde ursprünglich zusammen mit Kubeflow entwickelt.

Das Projekt wurde allerdings eingestellt, und die Logik hat sich seit dem letzten dokumentierten Stand etwas geändert. Trotzdem hat dieser Weg letztlich zum Ziel geführt. Was in unserem Fall besonders wichtig ist: kfctl bietet die Möglichkeit, Istio und Dex mit einzurichten.

Istio und Kubeflow

Istio ist ein Service Mesh für Kubernetes: Es übernimmt das Netzwerk-Management für die Pods, bei denen es aktiviert ist. Aber es ist auch ziemlich ressourcenhungrig: will man es verwenden, injiziert es einen Sidecar Container in allen betroffenen Pods – der ist nur dafür da, die Netzwerkkommunikation der einzelnen Pods zu steuern und den Netzwerkverkehr zwischen den Hauptcontainern und allen anderen Ressourcen zu kontrollieren und zu manipulieren.

Wofür ist es überhaupt da? Eine Frage, die sich nicht einfach beantworten lässt. Ohne Istio wird Kuberflow aber nicht wie erwartet funktionieren. Welche Istio-Ressourcen angelegt werden, welche Dienste wie mittels Istio verbunden werden: nicht wirklich dokumentiert.

Dex und Kubeflow

Ähnlich sieht es mit Dex aus. Das ist eine Kubernetes-Anwendung für Authentifizierung und Authorisierung gegenüber einem externen Dienst. Logisch: soll es bei der Verarbeitung um sensitive Daten gehen, will man regeln, wer Zugriff darauf haben darf. Und Daten sind immer sensitiv, egal ob Kreditkarten-Nummern, Email-Addressen oder Gesundheitsdaten.

Dex ermöglicht all dies: es verbindet sich mit einem LDAP-Server, und prüft, ob User, die sich anmelden, das auch dürfen. An welcher Stelle Kubeflow es benötigt, für welche Dienste, wie es ggf. mit Istio verdrahtet werden soll, ob überhaupt – all das wird in den Dokumentationen wieder nicht verraten.

Aber: Mit kfctl ist das auch nicht wichtig. Ein paar einfache Befehle und wir haben alle nötigen Ressourcen, die auch noch wie gewünscht miteinander kommunizieren.

benutzer@maschine:~/kfctl$ ./kfctl --help
A client CLI to create kubeflow applications for specific platforms or 'on-prem' 
to an existing k8s cluster.

Usage:
  kfctl [command]

Available Commands:
  alpha       Alpha kfctl features.
  apply       deploys a kubeflow application.
  build       Builds a KF App from a config file
  completion  Generate shell completions
  delete      Delete a kubeflow application.
  generate    'kfctl generate' has been replaced by 'kfctl build'
Please switch to new semantics.
To build a KFAPP run -> kfctl build -f ${CONFIG}
Then to install -> kfctl apply
For more information, run 'kfctl build -h' or read the docs at www.kubeflow.org.
  help        Help about any command
  init        'kfctl init' has been removed.
Please switch to new semantics.
To install run -> kfctl apply -f ${CONFIG}
For more information, run 'kfctl apply -h' or read the docs at www.kubeflow.org.
  version     Print the version of kfctl.

Flags:
  -h, --help   help for kfctl

Use "kfctl [command] --help" for more information about a command.

benutzer@maschine:~/kfctl$ ./kfctl build --help
Builds a KF App from a config file

Usage:
  kfctl build [flags]

Flags:
  -d, --dump          dump manifests to stdout, default is false
  -f, --file string   Static config file to use. Can be either a local path:
                      		export CONFIG=./kfctl_gcp_iap.yaml
                      	or a URL:
                      		export CONFIG=https://raw.githubusercontent.com/kubeflow/manifests/v1.0-branch/kfdef/kfctl_gcp_iap.v1.0.0.yaml
                      		export CONFIG=https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_istio_dex.v1.2.0.yaml
                      		export CONFIG=https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_aws.v1.2.0.yaml
                      		export CONFIG=https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_k8s_istio.v1.2.0.yaml
                      	kfctl build -V --file=${CONFIG}
  -h, --help          help for build
  -V, --verbose       verbose output default is false

Das KubeFlow-Projekt stellt Konfigurationsdateien für kfctl zur Verfügung, die sich direkt einlesen lassen. Ist kubectl korrekt konfiguriert und verweist auf den richtigen Cluster, erledigt folgendes Kommando all die schwere Arbeit:

export CONFIG=https://raw.githubusercontent.com/kubeflow/manifests/v1.2-branch/kfdef/kfctl_istio_dex.v1.2.0.yaml
kfctl build -V –file=${CONFIG}

Das erzeugt alle Ressourcen-Manifeste und sorgt dafür, dass sie deployed werden. Das Verfahren baut auf Kustomize, daher ist die Summe aller erzeugten Dateien etwas irreführend, aber als Info trotzdem interessant: dieser Befehl erzeugt mehr als 7000 Dateien in mehr als 1100 Verzeichnissen. Vielleicht erklärt das, warum keine ausführliche Dokumentation zu finden ist – und warum es nicht so einfach ist, das Deployment mit einem einfachen kubectl apply zu erledigen.

Folgt man den Änderungen bei Kubeflow sorgfältig, lassen sich diese Manifeste auch in Zukunft verwenden: mit entsprechend vorsichtigen Modifikationen an den kustomize-Dateien, die für das Erzeugen der weiteren Manifesten dienen (siehe die 7000+ oben) lassen sich Änderungen einpflegen. Vorausgesetzt, die hier verwendete Logik der entfernten Quellen bleibt konsistent.

Und wie geht es weiter?

Kfctl war also der Weg, unseren Problemen zu lösen. Die Entwicklung wurde aber eingestellt, es gibt keine neuen Versionen mehr. Man muss eine andere Lösung für die Zukunft finden. Und wir sind daran: wir untersuchen die Lösungen, die von Kubeflow als Default angeboten werden, um zu sehen, inwiefern sie sich bei Updates verwenden lassen, wie übersichtlich sie sind, wie einfach sie sich bedienen lassen. Und wenn wir Antworten haben, melden wir uns mit denen wieder.