TrueFoundry Architecture — Maschinelles Lernen auf Kubernetes!

TrueFoundry macht es wirklich einfach, Anwendungen auf Kubernetes-Clustern in Ihrem eigenen Cloud-Provider-Konto bereitzustellen. Dazu werden die Infrastrukturkomponenten für Datenwissenschaftler und Entwickler herausgerechnet und gleichzeitig die Best Practices aus Sicht der Sicherheit, Infrastruktur und Kostenoptimierung durchgesetzt.

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

1. Daten sollten Ihr Cloud-/On-Prem-Konto nicht verlassen: Beim maschinellen Lernen wird in der Regel mit vielen Daten interagiert. Wenn Daten aus Ihrem Cloud-Konto (VPC) fließen, besteht das Risiko, dass die Datensicherheit beeinträchtigt wird, und am Ende fallen auch Kosten für den Datenausgang/-eingang an. Aus diesem Grund wurde TrueFoundry von Grund auf so konzipiert, dass Daten und Berechnungen in Ihrer eigenen Umgebung gespeichert werden.
2. ML erbt die SRE-Prinzipien in Ihrem Unternehmen: Unternehmen implementieren in der Regel die gesamten Bereitstellungs-, Überwachungs- und Warnpakete für die Bereitstellung ihrer Software-Microservices. Wir wollten, dass ML die gleichen Praktiken übernimmt und keine parallele Infrastruktur aufbaut. Dies macht es für Infrastruktur- und SRE-Teams einfach, die Best Practices für Sicherheit und Kostenoptimierung im gesamten Unternehmen durchzusetzen.
3. Cloud-nativ: TrueFoundry basiert auf Kubernetes und ist daher von Natur aus Cloud-nativ. Obwohl Kubernetes Cloud-nativ ist, gibt es viele komplizierte Unterschiede zwischen den Kubernetes-Distributionen von AWS (EKS), GCP (GKE) und Azure (AKS). Einige Beispiele für diese Unterschiede sind:

GKE Autopilot erzwingt, dass dieselben Werte für Anfragen und Grenzwerte für Ressourcen gelten, während AKS, EKS und GKE Standard dies nicht tun.

EKS und GKE haben eine Option für die automatische Node-Bereitstellung, während AKS dafür keine Möglichkeit bietet.

Die Knotenbereitstellungszeit für AKS ist ziemlich hoch, was zu einem sehr langsamen Autoscaling-Verhalten führt.

Da wir Cloud-nativ sind, können wir auf die unterschiedliche Hardware zugreifen, die von verschiedenen Cloud-Anbietern bereitgestellt wird, insbesondere im Fall von GPUs.

4. Integrieren statt neu erfinden: TrueFoundry lässt sich in die meisten gängigen Systeme integrieren, anstatt das Rad neu zu erfinden. Diese Philosophie bestimmt viele unserer Architekturentscheidungen. Es macht uns manchmal die Reise schwieriger, da es nicht immer einfach ist, Integrationen zu erstellen, für die keine soliden APIs verfügbar sind — aber wir machen die harte Arbeit, diese APIs und Schnittstellen zu erstellen, damit unsere Benutzer kein weiteres Tool lernen müssen.

ML-Stack für schnelle Iteration und Wirkung

Für maschinelles Lernen muss ein komplizierter Stack eingerichtet werden, damit Datenwissenschaftler schnell experimentieren und Ergebnisse liefern können.

Idealerweise sollten Entwickler mehr für die oberste grüne Ebene ausgeben, während die unteren Ebenen vollständig von ihnen abstrahiert werden sollten. TrueFoundry bietet einen offenen und anpassbaren Stack, der mit dem funktioniert, was Sie gerade verwenden, und der Datenwissenschaftler hilft, an den Anwendungen zu iterieren, ohne sich auf die zugrunde liegenden Infrastrukturschichten konzentrieren zu müssen.

In der Abbildung unten stellt TrueFoundry die Model Training, Serving and Model Registry bereit, um Datenwissenschaftlern das Erstellen, Verfolgen und Bereitstellen von Modellen zu erleichtern.

Die wichtigsten Integrationen, die TrueFoundryCurrently bietet, sind:

1. CI/CD: Github-Aktionen, Bitbucket-Pipelines, Jenkins. Je nach Kundennachfrage fügen wir zusätzliche Integrationen hinzu.
2. Service Mesh: Wir arbeiten derzeit mit Istio zusammen. Wir planen, andere Ingress-Controller und Service Mesh-Anbieter wie Linkerd, Nginx zu unterstützen.
3. Überwachung: Die von TrueFoundry bereitgestellten Anwendungen können mit jedem Ihrer vorhandenen Überwachungssysteme wie Prometheus, Cloudwatch, DataDog, NewRelic, ELK Stack usw. überwacht werden.
4. Kostenmanagement: Mit OpenCost bieten wir eine detaillierte Kostenzuweisung auf Dienst-/Namespace-Ebene. TrueFoundry bietet Entwicklern auch direkte Einblicke, um die Kosten ihrer Dienste zu senken.
5. Zutrittskontrolle: TrueFoundry lässt sich in die meisten IdPs wie Okta, Auth0, AzureAD, Keycloak integrieren und verwendet OIDC- oder SAML-Protokolle zur Authentifizierung. Die Autorisierung für verschiedene Arbeitsbereiche ist in das Produkt integriert, um Berechtigungen auf granularer Ebene festzulegen.
6. Verwaltung von Geheimnissen: TrueFoundry lässt sich für die Verwaltung von Geheimnissen in Hashcorp Vault, GCP Secrets Manager und AWS Parameter Store integrieren. Wir planen auch, die Integration mit Azure Vault und AWS Secrets Manager hinzuzufügen.
7. Workflow-Engine: TrueFoundry lässt sich in ArgoWorkflows integrieren, um Datenwissenschaftlern eine Workflow-Engine zur Verfügung zu stellen.

TrueFoundry-Architektur

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

1. Kontrollebene: Dies ist das Gehirn des TrueFoundry-Systems, das die Orchestrierung von Bereitstellungen auf den verschiedenen Rechenebenen durchführt. In unserem üblichen Plan bieten wir eine gehostete Steuerungsebene an. Für Unternehmenskunden kann die Steuerungsebene auch in der Cloud des Kunden bereitgestellt werden.
2. Ebene berechnen: Dies ist der Kubernetes-Cluster, auf dem der Code des Benutzers ausgeführt wird. Es gibt einen Agenten auf der Rechenebene (tfy-agent), das mit der Steuerungsebene kommuniziert und die von der Steuerungsebene empfangenen Befehle ausführt. Der Code des Benutzers, der auf die Daten zugreift, läuft auf der Rechenebene — und daher sollte sich der Cluster der Rechenebene in der Nähe der Daten befinden.

3. Client-Schnittstellen: Entwickler und Datenwissenschaftler können mithilfe eines Python-SDK, unserer Web-UI oder mithilfe der TrueFoundry-CLIs (servicefoundry und mlfoundry) mit der Benutzeroberfläche kommunizieren. TrueFoundry stellt auch APIs zur Verfügung, mit denen Kunden Automatisierungsworkflows erstellen können. Diese sind hier dokumentiert: https://docs.truefoundry.com/reference

4. Authentifizierungsserver: Es gibt einen zentralen Authentifizierungs- und Lizenzserver, der alle Organisationen und ihre Mitglieder verfolgt. Dieser Server wird von TrueFoundry gehostet und kann auch in externe IdPs integriert werden, um allen unseren Benutzern ein einmaliges Anmeldeerlebnis zu bieten.

Vorteile dieser Architektur

Sicheres Netzwerk

Die tfy-agent-Komponente hat keinen Zugriff und ist für die Initiierung der Verbindung zur Steuerungsebene verantwortlich. Sie baut eine persistente verschlüsselte Verbindung zur Steuerungsebene auf, über die die Kommunikation stattfindet. Dadurch kann das System auch dann funktionieren, wenn die Cluster auf der Rechenebene privat sind oder sich in verschiedenen VPCs befinden. Die einzige Einschränkung besteht darin, dass die URL der Steuerungsebene für alle Cluster der Rechenebene zugänglich sein sollte. Sie können auch die Berechtigungen kontrollieren, die tfy-agent mithilfe von Kubernetes RBAC gewährt werden, um Zugriff auf bestimmte Namespaces zu erhalten.

Weiche Abhängigkeit von der Truefoundry-Steuerungsebene

Die Truefoundry-Steuerungsebene ist nur für die Orchestrierung der Bereitstellungen auf der Rechenebene verantwortlich. Sie liegt nicht im kritischen Pfad des Anforderungsflusses zu den bereitgestellten Diensten. Selbst wenn Sie die Truefoundry Control-Ebene entfernen, laufen alle bereitgestellten Dienste weiterhin reibungslos. Diese Entkopplung der Serviceverlässlichkeit von Truefoundry trägt dazu bei, dass Truefoundry nicht auf dem kritischen Pfad der Serviceverlässlichkeit liegt.

Effizientes Multi-Cluster-Management

Truefoundry Control Plane bietet eine zentrale Ansicht aller Kubernetes-Cluster aller Cloud-Anbieter und vor Ort im Unternehmen. Dies macht es auch ganz einfach, Workloads mithilfe unserer Funktion „Clone and Promote“ von einem Cluster auf einen anderen zu verschieben.

Niedrigere Kosten und Wartung

Der Truefoundry-Agent ist eine sehr leichte Komponente, die auf jedem einzelnen Cluster installiert ist, während nur eine einzige Kopie der Steuerungsebene vorhanden sein muss. Die Steuerungsebene benötigt mehr Ressourcen (3 CPU, 6 GB RAM), während der Agent nur 0,2 CPU und 400 MB RAM benötigt. Wenn der Umfang des Datenverkehrs und der Teams zunimmt, müssen wir in der Regel weitere Cluster hinzufügen, die auf Regionen oder Teams basieren. Die Steuerungsebene muss jedoch nicht repliziert werden, was geringere Kosten und geringeren Wartungsaufwand ermöglicht.

Ein Blick in die Truefoundry Control Plane

Truefoundry Control Plane besteht aus mehreren Microservices, die die Bereitstellungen orchestrieren, die Speicherung von Metadaten modellieren usw. Die wichtigsten Komponenten der Truefoundry Control-Ebene sind:

1. Webbenutzeroberfläche

2. Microservices für die Orchestrierung von Bereitstellungen: Die Steuerungsebene besteht aus einigen Microservices zur Orchestrierung der Bereitstellungen in den Clustern. Außerdem werden die Live-Updates aller verbundenen Cluster auf der Rechenebene zwischengespeichert.

3. Postgres-Datenbank: Hier werden alle Informationen über Teams, eingesetzte Dienste und deren Metadaten gespeichert.

Cluster auf Rechenebene

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

1. tfy-agent (Erforderlich): Dies ist der Truefoundry-Agent, der die Verbindung zur Steuerungsebene initiiert und hilft, die Anweisungen von der Steuerungsebene aus zu koordinieren.
2. Argo CD (Erforderlich): ArgoCD wird verwendet, um alle Manifeste auf den Kubernetes-Cluster anzuwenden. Dies ist besser als eine Helminstallation, da der ArgoCD-Controller sicherstellt, dass der interne Status mit dem gewünschten Status in den Manifesten synchronisiert wird, und nicht anfällig für Helm-Installationsfehler ist.
3. Istio (Derzeit erforderlich, wird in Zukunft optional sein): Wir setzen derzeit auf Istio als Ingress-Controller für den Cluster. Wir schreiben das Ausführen von Istio-Sidecars nicht vor und sie können optional aktiviert werden, wenn dies für Anwendungsfälle wie gegenseitiges TLS erforderlich ist. Wir planen auch, die Gateway-APIs von Kubernetes zu verwenden, was es uns ermöglicht, mit mehreren Ingress-Controllern wie Nginx, Linkerd, Traefik usw. zu arbeiten.
4. Argo-Arbeitsabläufe (Nur für die Ausführung von Jobs erforderlich): Wir verwenden ArgoWorkflows für die Ausführung aller Jobs innerhalb des Clusters, da es im Vergleich zu Kubernetes-Jobs erweiterte Optionen bietet.
5. Rollouts von Argo (Erforderlich): Wir verwenden ArgoRollouts, 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, Arbeitsspeicher und Anzahl der Anfragen für die Dienste anzuzeigen.
7. Keda (fakultativ): Dies ist eine optionale Abhängigkeit und wird benötigt, wenn Sie Autoscaling für Ihre Workloads aktivieren möchten.
8. Loki (Optional): Dies hilft bei der Protokollaggregation und ist eine optionale Abhängigkeit. Sie können jederzeit jeden anderen Log-Aggregator verwenden, mit dem Sie vertraut sind, wie ELK Stack, Cloudwatch, Datadog usw.
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 ist erforderlich, wenn Sie Notebooks auf dem Kubernetes-Cluster bereitstellen möchten.

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

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

Berechtigungen für tfy-agent

Der tfy-agent führt alle Aktionen für den Kubernetes-Benutzer im Namen der Benutzer aus, die auf der Truefoundry-Plattform angemeldet sind. Daher ist Administratorzugriff auf eine bestimmte Gruppe von Namespaces erforderlich, auf denen die Benutzer die Anwendungen bereitstellen dürfen. Wir haben Funktionen, um eine bestimmte Gruppe von Namespaces auf die schwarze oder weiße Liste zu setzen, und der Agent kann nur Aktionen für diese Namespaces ausführen.

Authentifizierung in Truefoundry

Truefoundry ist für die Lizenzierung und Authentifizierung auf einen Authentifizierungsserver angewiesen, der sich auf unseren Servern befindet.

Autorisierung in Truefoundry

Truefoundry bietet eine fein abgestimmte RBAC-Steuerung auf Mandanten-, Cluster-, Workspace- und ML-Repo-Ebene. Um die RBAC-Mechanismen in Truefoundry zu verstehen, können Sie unsere Dokumente hier lesen: https://docs.truefoundry.com/docs/collaboration-and-access-control

Alle Autorisierungsregeln befinden sich in der Postgres-Tabelle in der Steuerungsebene, und bei jedem API-Aufruf wird überprüft, ob der Benutzer berechtigt ist, diese Verbindung herzustellen.

Image Build Pipeline in der Steuerungsebene

Truefoundry bietet eine grundlegende Pipeline zur Image-Erstellung, die für die sehr schnelle Erstellung von Images auf Kubernetes optimiert ist. Falls Sie die Pipeline für die Erstellung von Images anpassen möchten, um statische Prüfungen oder andere Tools zum Scannen von Sicherheitslücken einzubeziehen, gibt es zwei Möglichkeiten:

1. Sie können weiterhin Ihre eigene CI-Pipeline verwenden, um Images zu erstellen, und dann die erstellte Image-URI als Eingabe für Truefoundry-Bereitstellungen bereitstellen.
2. Sie können die Truefoundry-Build-Pipeline so anpassen, dass sie alle gewünschten Komponenten enthält. Es ist im Grunde ein ArgoWorFlow und da Sie die Steuerungsebene im Enterprise-Plan besitzen, können Sie sie nach Belieben anpassen.

Geheime Verwaltung in Truefoundry

Echte Gießerei lässt sich in die beliebtesten Secret Management Stores integrieren. Es speichert nicht die geheimen Werte, sondern nur den Pfad zu diesen Geheimnissen.