TrueFoundry-Architektur – Machine Learning auf Kubernetes!

TrueFoundry macht es extrem einfach, Anwendungen auf Kubernetes-Clustern in Ihrem eigenen Cloud-Provider-Konto bereitzustellen. Dies geschieht, indem Infrastrukturkomponenten für Data Scientists und Entwickler abstrahiert werden, während gleichzeitig Best Practices aus den Bereichen Sicherheit, Infrastruktur und Kostenoptimierung durchgesetzt werden.

Die wesentlichen Beweggründe für die aktuelle Architektur von TrueFoundry sind:

1. Daten sollten Ihr Cloud-/On-Premises-Konto nicht verlassen: Machine Learning beinhaltet in der Regel die Interaktion mit großen Datenmengen. Wenn Daten Ihr Cloud-Konto (VPC) verlassen, besteht das Risiko, dass die Datensicherheit beeinträchtigt wird, und es entstehen Kosten für Daten-Egress/-Ingress. Aus diesem Grund wurde TrueFoundry von Grund auf so konzipiert, dass sowohl Daten als auch Compute-Ressourcen in Ihrer eigenen Umgebung verbleiben.
2. ML übernimmt die SRE-Prinzipien Ihrer Organisation: Unternehmen implementieren gewöhnlich vollständige Stacks für Deployment, Monitoring und Alerting, um ihre Software-Microservices bereitzustellen. Wir wollten, dass ML dieselben Praktiken übernimmt und kein paralleles Infrastruktur-Setup aufbaut. Dies erleichtert es Infrastruktur- und SRE-Teams, Best Practices für Sicherheit und Kostenoptimierung in der gesamten Organisation durchzusetzen.
3. Cloud Native: TrueFoundry basiert auf Kubernetes und ist daher von Grund auf Cloud-Native. Obwohl Kubernetes Cloud-Native ist, gibt es jedoch viele feine Unterschiede zwischen den Kubernetes-Distributionen von AWS (EKS), GCP (GKE) und Azure (AKS). Einige Beispiele für diese Unterschiede sind:

GKE Autopilot erzwingt identische Werte für Requests und Limits bei Ressourcen, während AKS, EKS und GKE Standard dies nicht tun.

EKS und GKE bieten eine Option für Auto-Node-Provisioning, während AKS hierfür keine Möglichkeit bereitstellt.

Die Bereitstellungszeit von Nodes ist bei AKS recht hoch, was zu einem sehr langsamen Autoscaling-Verhalten führt.

Die Eigenschaft, Cloud-Native zu sein, verschafft uns Zugriff auf die unterschiedliche Hardware verschiedener Cloud-Provider, insbesondere im Fall von GPUs.

4. Integrieren statt neu erfinden: TrueFoundry lässt sich in die meisten gebräuchlichen Systeme integrieren, anstatt das Rad neu zu erfinden. Diese Philosophie prägt viele unserer Architekturentscheidungen. Dies macht den Weg für uns manchmal schwerer, da es nicht immer einfach ist, Integrationen dort zu bauen, wo keine solideren APIs verfügbar sind – aber wir übernehmen die schwere Arbeit, diese APIs und Schnittstellen zu entwickeln, damit unsere Nutzer nicht noch ein weiteres Tool erlernen müssen.

ML-Stack für schnelle Iteration und Wirkung

Machine Learning erfordert ein komplexes Stack-Setup, damit Data Scientists schnell experimentieren und Ergebnisse liefern können.

Idealerweise sollten Entwickler mehr Zeit in der obersten, grünen Schicht verbringen, während die unteren Schichten vollständig vor ihnen abstrahiert sein sollten. TrueFoundry bietet einen offenen und anpassbaren Stack, der mit Ihren bestehenden Tools zusammenarbeitet und Data Scientists hilft, Anwendungen zu iterieren, ohne sich auf die zugrundeliegenden Infrastrukturschichten konzentrieren zu müssen.

In dem folgenden Diagramm stellt TrueFoundry Model Training, Serving und die Model Registry bereit, um Data Scientists das Erstellen, Nachverfolgen und Deployen von Modellen zu erleichtern.

Zu den wichtigsten Integrationen, die TrueFoundry derzeit bietet, gehören:

1. CI/CD: GitHub Actions, Bitbucket Pipelines, Jenkins. Wir fügen basierend auf der Kundennachfrage weitere Integrationen hinzu.
2. Service Mesh: Derzeit arbeiten wir mit Istio. Wir planen, andere Ingress-Controller und Service-Mesh-Anbieter wie Linkerd und Nginx zu unterstützen.
3. Monitoring: Die von TrueFoundry bereitgestellten Anwendungen können mit jedem Ihrer bestehenden Monitoring-Systeme überwacht werden, z. B. Prometheus, CloudWatch, DataDog, NewRelic, ELK-Stack usw.
4. Kostenmanagement: Wir bieten eine feingranulare Kostenzuordnung auf Service-/Namespace-Ebene mithilfe von OpenCost. TrueFoundry liefert Entwicklern zudem direkte Einblicke, um die Kosten ihrer Services zu senken.
5. Zugriffskontrolle (Access Control): TrueFoundry lässt sich über OIDC- oder SAML-Protokolle zur Authentifizierung in die meisten IdPs wie Okta, Auth0, Azure AD und Keycloak integrieren. Die Autorisierung für verschiedene Workspaces ist fest in das Produkt integriert, um Berechtigungen auf granularer Ebene festzulegen.
6. Secrets Management: TrueFoundry lässt sich für das Secrets Management mit HashiCorp Vault, GCP Secrets Manager und AWS Parameter Store integrieren. Wir planen zudem die Integration mit Azure Vault und AWS Secrets Manager.
7. Workflow Engine: TrueFoundry lässt sich mit Argo Workflows integrieren, um eine Workflow-Engine bereitzustellen, die KI-Automatisierung für Data Scientists unterstützt.

TrueFoundry-Architektur

TrueFoundry bietet eine Split-Plane-Architektur, die aus den folgenden Hauptkomponenten besteht:

1. Control Plane: Dies ist das Gehirn des TrueFoundry-Systems, das die Orchestrierung von Deployments über die verschiedenen Compute-Planes hinweg übernimmt. In unserem Standardtarifen bieten wir eine gehostete Control Plane an. Für Enterprise-Kunden kann die Control Plane auch in der Cloud des Kunden bereitgestellt werden.
2. Compute Plane: Dies ist der Kubernetes-Cluster, auf dem der Code des Benutzers läuft. Auf der Compute Plane befindet sich ein Agent (tfy-agent), der mit der Control Plane kommuniziert und die von der Control Plane empfangenen Befehle ausführt. Der Code des Benutzers, der auf die Daten zugreift, läuft auf der Compute Plane – daher sollte der Compute-Plane-Cluster nah an den Daten angesiedelt sein.

3. Client-Schnittstellen: Entwickler und Data Scientists können über ein Python-SDK, unsere Web-UI oder die TrueFoundry-CLIs (servicefoundry und mlfoundry) mit der Benutzeroberfläche kommunizieren. TrueFoundry stellt Kunden außerdem APIs zur Verfügung, um Automatisierungs-Workflows zu erstellen, die hier dokumentiert sind: https://docs.truefoundry.com/reference

4. Authentifizierungsserver: Es gibt einen zentralen Authentifizierungs- und Lizenzierungsserver, der alle Organisationen und deren Mitglieder verwaltet. Dieser Server wird von TrueFoundry gehostet und kann auch mit externen IdPs integriert werden, um allen unseren Nutzern ein Single-Sign-On-Erlebnis zu bieten.

Vorteile dieser Architektur

Sicheres Networking

Die tfy-agent-Komponente hat keinen Ingress und ist dafür verantwortlich, die Verbindung zur Control Plane zu initiieren. Sie baut eine dauerhafte, verschlüsselte Verbindung zur Control Plane auf, über die die Kommunikation stattfindet. Dadurch funktioniert das System selbst dann, wenn die Compute-Plane-Cluster privat sind oder sich in verschiedenen VPCs befinden. Die einzige Einschränkung besteht darin, dass die URL der Control Plane für alle Compute-Plane-Cluster erreichbar sein muss. Sie können die dem tfy-agent erteilten Berechtigungen auch über Kubernetes-RBAC steuern, um den Zugriff auf bestimmte Namespaces zu beschränken.

Geringe Abhängigkeit von der TrueFoundry Control Plane

Die TrueFoundry Control Plane ist nur für die Orchestrierung der Deployments auf der Compute Plane zuständig. Sie liegt nicht im kritischen Pfad des Anfrageflusses zu den bereitgestellten Services. Selbst wenn Sie die TrueFoundry Control Plane entfernen, laufen alle bereitgestellten Services reibungslos weiter. Diese Entkopplung der Service-Zuverlässigkeit von TrueFoundry trägt dazu bei, dass TrueFoundry nicht im kritischen Pfad der Service-Verfügbarkeit liegt.

Effizientes Multi-Cluster-Management

Die TrueFoundry Control Plane bietet eine zentrale Oberfläche (Single Pane of Glass), um alle Kubernetes-Cluster über Multi-Cloud-Provider und On-Premises hinweg im Unternehmen einzusehen. Dies macht es mit unserer Clone-and-Promote-Funktion extrem einfach, Workloads von einem Cluster auf einen anderen zu verschieben.

Geringere Kosten und weniger Wartungsaufwand

Der TrueFoundry Agent ist eine sehr leichtgewichtige Komponente, die auf jedem einzelnen Cluster läuft, während die Control Plane nur ein einziges Mal vorhanden sein muss. Die Control Plane benötigt mehr Ressourcen (3 CPU, 6 GB RAM), während der Agent nur 0,2 CPU und 400 MB RAM benötigt. Wenn das Skalierungsvolumen von Traffic und Teams steigt, müssen wir in der Regel weitere Cluster basierend auf Regionen oder Teams hinzufügen. Die Control Plane muss jedoch nicht dupliziert werden, was geringere Kosten und einen reduzierten Wartungsaufwand ermöglicht.

Ein Blick in die TrueFoundry Control Plane

Die TrueFoundry Control Plane besteht aus mehreren Microservices, die Deployments, Modell-Metadaten-Speicherung usw. orchestrieren. Die Hauptkomponenten der TrueFoundry Control Plane sind:

1. Web-UI

2. Microservices zur Orchestrierung von Deployments: Die Control Plane besteht aus einigen Microservices zur Orchestrierung der Deployments über die Cluster hinweg und zwischenspeichert zudem die Live-Updates von allen verbundenen Clustern in der Compute Plane.

3. Postgres-Datenbank: Diese wird verwendet, um alle Informationen über Teams, bereitgestellte Services und deren Metadaten zu speichern.

Compute-Plane-Cluster

Wir müssen einige Komponenten auf dem Compute-Plane-Cluster installieren, um die Vorteile von TrueFoundry voll auszuschöpfen. Die Liste lautet wie folgt:

1. tfy-agent (Erforderlich): Dies ist der truefoundry-agent, der die Verbindung zur Control Plane initiiert und dabei hilft, die Anweisungen der Control Plane zu koordinieren.
2. ArgoCD (Erforderlich): ArgoCD wird verwendet, um alle Manifeste auf dem Kubernetes-Cluster anzuwenden. Dies ist besser als die Ausführung von helm install, da der ArgoCD-Controller sicherstellt, dass der interne Status mit dem gewünschten Status in den Manifesten synchronisiert ist und nicht anfällig für Fehlschläge bei Helm-Installationen ist.
3. Istio (Derzeit erforderlich, wird in Zukunft optional sein): Wir nutzen derzeit Istio als Ingress-Controller für den Cluster. Wir schreiben die Ausführung von Istio-Sidecars nicht vor; diese können optional aktiviert werden, falls dies für Anwendungsfälle wie Mutual TLS erforderlich ist. Wir planen zudem die Nutzung der Gateway-APIs von Kubernetes, was es uns ermöglichen wird, mit mehreren Ingress-Controllern wie Nginx, Linkerd, Traefik etc. zu arbeiten.
4. Argo Workflows (Nur für das Ausführen von Jobs erforderlich): Wir nutzen Argo Workflows für die Ausführung aller Jobs innerhalb des Clusters aufgrund der fortgeschritteneren Optionen im Vergleich zu Kubernetes-Jobs.
5. Argo Rollouts (Erforderlich): Wir nutzen Argo Rollouts, um Canary- und BlueGreen-Rollouts auf Kubernetes zu unterstützen. Dies ist derzeit eine erforderliche Voraussetzung, wird aber in Zukunft optional sein.
6. Prometheus (Optional): Dies ist eine optionale Abhängigkeit, die benötigt wird, um Metriken wie CPU, Speicher und Anzahl der Anfragen für die Services anzuzeigen.
7. KEDA (Optional): Dies ist eine optionale Abhängigkeit und erforderlich, wenn Sie Autoscaling für Ihre Workloads aktivieren möchten.
8. Loki (Optional): Dies hilft bei der Log-Aggregation und ist eine optionale Abhängigkeit. Sie können jederzeit jeden anderen Log-Aggregator verwenden, mit dem Sie vertraut sind, wie z. B. ELK-Stack, CloudWatch, DataDog etc.
9. Treiber (EFS, EBS, GPU): Diese werden benötigt, wenn Sie GPU- oder Volume-Unterstützung in Ihrem Cluster benötigen.
10. Notebook Controller (Optional): Dies wird benötigt, wenn Sie Notebooks auf dem Kubernetes-Cluster bereitstellen möchten.

Einschränkungen für das Kubernetes-Cluster-AMI

TrueFoundry kann mit allen zugrundeliegenden AMIs arbeiten, einschließlich Bottlerocket auf AWS. Da der Agent genau wie jeder andere Helm-Chart auf Kubernetes läuft, haben wir keine Einschränkungen oder Anforderungen an die zugrundeliegenden AMIs und können auf allen AMIs ausgeführt werden, einschließlich Bare-Metal-Maschinen.

Berechtigungen für den tfy-agent

Der tfy-agent führt alle Aktionen auf dem Kubernetes-User im Namen der Benutzer aus, die auf der TrueFoundry-Plattform angemeldet sind. Daher benötigt er Admin-Zugriff auf eine bestimmte Gruppe von Namespaces, auf denen die Benutzer die Anwendungen bereitstellen dürfen. Wir bieten Funktionen zum Blacklisten oder Whitelisten bestimmter Namespaces, und der Agent kann nur auf diesen Namespaces Aktionen ausführen.

Authentifizierung in TrueFoundry

TrueFoundry verlässt sich auf einen Authentifizierungsserver, der auf unseren Servern gehostet wird, um die Lizenzierung und Authentifizierung abzuwickeln.

Autorisierung in TrueFoundry

TrueFoundry bietet eine feingranulare RBAC-Steuerung auf Tenant-, Cluster-, Workspace- und ML-Repo-Ebene. Um die RBAC-Mechanismen in TrueFoundry zu verstehen, können Sie unsere Dokumentation hier lesen: https://www.truefoundry.com/docs/platform/manage-user-roles-and-permissions

Alle Autorisierungsregeln befinden sich in der Postgres-Tabelle in der Control Plane, und jeder API-Aufruf wird überprüft, um festzustellen, ob der Benutzer berechtigt ist, diese Verbindung auszuführen.

Image-Build-Pipeline in der Control Plane

TrueFoundry bietet eine grundlegende Image-Build-Pipeline, die darauf optimiert ist, Images sehr schnell auf Kubernetes zu erstellen. Falls Sie die Pipeline zur Erstellung von Images anpassen möchten, um statische Prüfungen oder andere Tools zum Scannen von Schwachstellen einzubinden, gibt es zwei Ansätze:

1. Sie können weiterhin Ihre eigene CI-Pipeline zum Erstellen von Images verwenden und dann die URI des erstellten Images als Eingabe für TrueFoundry-Deployments angeben.
2. Sie können die TrueFoundry-Build-Pipeline anpassen, um beliebige Komponenten einzubinden. Es handelt sich im Grunde um einen Argo Workflow, und da Sie im Enterprise-Tarif Eigentümer der Control Plane sind, steht es Ihnen frei, diese nach Ihren Wünschen anzupassen.

Secret Management in TrueFoundry

TrueFoundry lässt sich in die gängigsten Secret-Management-Speicher integrieren. Es speichert selbst keine Secret-Werte, sondern nur den Pfad zu diesen Secrets.