TrueFoundry-architectuur - Machine Learning op Kubernetes!

TrueFoundry maakt het heel eenvoudig om applicaties te implementeren op Kubernetes-clusters in uw eigen cloudprovider-account. Het doet dit door de infrastructuurcomponenten te abstraheren voor data scientists en ontwikkelaars, terwijl de beste praktijken op het gebied van beveiliging, infrastructuur en kostenoptimalisatie worden gehandhaafd.

De belangrijkste motieven achter de huidige architectuur van TrueFoundry zijn:

1. Data mag uw cloud/on-prem-account niet verlaten: Machine Learning omvat meestal interactie met veel data. Als data uw cloudaccount (VPC) verlaat, bestaat het risico dat de databeveiliging in het geding komt en maken we ook kosten voor data-egress/ingress. Dit is de reden waarom TrueFoundry vanaf de grond is ontworpen om zowel data als compute binnen uw eigen omgeving te houden.
2. ML erft de SRE-principes binnen uw organisatie: Bedrijven implementeren meestal de gehele deployment-, monitoring- en alerting-stacks voor het implementeren van hun software-microservices. We wilden dat ML dezelfde praktijken zou overnemen en niet het pad van een parallelle infrastructuuropset zou volgen. Dit maakt het voor infrastructuur- en SRE-teams eenvoudig om de beste praktijken op het gebied van beveiliging en kostenoptimalisatie binnen de gehele organisatie af te dwingen.
3. Cloud Native: TrueFoundry is gebouwd op Kubernetes en daardoor van nature cloud-native. Hoewel Kubernetes cloud-native is, zijn er echter veel ingewikkelde verschillen tussen de Kubernetes-distributies van AWS (EKS), GCP (GKE) en Azure (AKS). Enkele voorbeelden van deze verschillen zijn:

GKE Autopilot dwingt af dat verzoeken en limieten voor bronnen dezelfde waarden hebben, terwijl AKS, EKS en GKE Standard dat niet doen.

EKS en GKE hebben een optie voor automatische node-provisioning, terwijl AKS hier geen mogelijkheid voor biedt.

De node-provisioningtijd is vrij hoog voor AKS, wat leidt tot zeer traag autoscaling-gedrag.

Cloud-native zijn geeft ons toegang tot de verschillende hardware die door verschillende cloudproviders wordt geleverd, vooral in het geval van GPU's.

4. Integreren in plaats van opnieuw uitvinden: TrueFoundry integreert met de meeste veelgebruikte systemen in plaats van het wiel opnieuw uit te vinden. Deze filosofie stuurt veel van onze architectuurbeslissingen. Het maakt de reis soms moeilijker voor ons, omdat het niet altijd eenvoudig is om integraties te bouwen waar geen solide API's beschikbaar zijn - maar wij doen het zware werk om die API's en interfaces te bouwen, zodat onze gebruikers niet nog een tool hoeven te leren.

ML Stack voor snelle iteratie en impact

Machine Learning vereist een ingewikkelde stack die moet worden opgezet zodat data scientists snel kunnen experimenteren en opleveren.

Idealiter zouden ontwikkelaars meer tijd moeten besteden in de bovenste groene laag, terwijl de onderste lagen volledig voor hen verborgen zouden moeten zijn. TrueFoundry biedt een open en aanpasbare stack die werkt met wat u momenteel gebruikt en helpt data scientists te itereren op de applicaties zonder zich te richten op de onderliggende infrastructuurlagen.

In het onderstaande diagram biedt TrueFoundry de Model Training, Serving en Model registry om het voor data scientists gemakkelijker te maken om modellen te bouwen, te volgen en te implementeren.

De belangrijkste set integraties die TrueFoundry momenteel biedt, zijn:

1. CI/CD: GitHub Actions, Bitbucket Pipelines, Jenkins. We voegen aanvullende integraties toe op basis van de vraag van klanten.
2. Service Mesh: We werken momenteel met Istio. We zijn van plan om andere Ingress-controllers en service mesh-providers zoals Linkerd, Nginx te ondersteunen.
3. Monitoring: De door TrueFoundry geïmplementeerde applicaties kunnen worden gemonitord met behulp van al uw bestaande monitoringsystemen zoals Prometheus, CloudWatch, DataDog, NewRelic, ELK-stack, enz.
4. Kostenbeheer: We bieden fijne kostenattributie op service-/namespaceniveau met behulp van OpenCost. TrueFoundry biedt ook rechtstreeks inzichten aan ontwikkelaars om de kosten van hun services te verlagen.
5. Toegangsbeheer: TrueFoundry integreert met de meeste IdP's zoals Okta, Auth0, AzureAD, Keycloak met behulp van OIDC- of SAML-protocollen voor authenticatie. Autorisatie voor verschillende werkruimten is ingebouwd in het product om permissies op een granulair niveau te bepalen.
6. Secrets Management: TrueFoundry integreert met HashiCorp Vault, GCP Secrets Manager en AWS Parameter Store voor het beheer van geheimen. We zijn ook van plan om integratie met Azure Vault en AWS Secrets Manager toe te voegen.
7. Workflow Engine: TrueFoundry integreert met Argo Workflows om een workflow-engine te bieden die AI-automatisering ondersteunt voor data scientists.

TrueFoundry-architectuur

TrueFoundry biedt een split-plane architectuur die bestaat uit de volgende hoofdcomponenten:

1. Control Plane: Dit is het brein van het TrueFoundry-systeem dat de orchestratie van deployments over de verschillende compute planes uitvoert. We bieden een gehoste control plane in ons standaardplan. Voor enterprise-klanten kan de control plane ook in de cloud van de klant worden geïmplementeerd.
2. Compute Plane: Dit is het Kubernetes-cluster waarop de code van de gebruiker draait. Er bevindt zich een agent op de compute plane (tfy-agent) die communiceert met de control plane en de opdrachten uitvoert die zijn ontvangen van de control plane. De code van de gebruiker die toegang heeft tot de data draait op de compute plane - en daarom moet het compute plane-cluster dicht bij de data staan.

3. Client Interfaces: Ontwikkelaars en data scientists kunnen communiceren met de UI met behulp van een Python SDK, onze web-UI of de TrueFoundry CLI's (servicefoundry en mlfoundry). TrueFoundry stelt ook API's beschikbaar voor clients om automatiseringsworkflows te bouwen, die hier zijn gedocumenteerd: https://docs.truefoundry.com/reference

4. Authenticatieserver: Er is een centrale authenticatie- en licentieserver die alle organisaties en hun leden bijhoudt. Deze server wordt gehost door TrueFoundry en kan ook integreren met externe IdP's om al onze gebruikers een single sign-on-ervaring te bieden.

Voordelen van deze architectuur

Veilige netwerkomgeving

De tfy-agent-component heeft geen ingress en is verantwoordelijk voor het initialiseren van de verbinding met de control plane. Het zet een permanente versleutelde verbinding op met de control plane waarover de communicatie plaatsvindt. Hierdoor werkt het systeem zelfs als de compute-plane clusters privé zijn of zich in verschillende VPC's bevinden. De enige beperking is dat de URL van de control plane toegankelijk moet zijn voor alle compute-plane clusters. U kunt ook de permissies die aan de tfy-agent zijn verleend beheren met behulp van Kubernetes RBAC om toegang te krijgen tot bepaalde namespaces.

Zachte afhankelijkheid van de TrueFoundry control plane

De TrueFoundry control plane is alleen verantwoordelijk voor het orchestreren van de deployments naar de compute plane. Het bevindt zich niet in het kritieke pad van de verzoekstroom naar de geïmplementeerde services. Dus zelfs als u de TrueFoundry Control Plane verwijdert, blijven alle geïmplementeerde services probleemloos draaien. Deze ontkoppeling van servicebetrouwbaarheid van TrueFoundry helpt ervoor te zorgen dat TrueFoundry niet in het kritieke pad van de servicebetrouwbaarheid ligt.

Efficiënt beheer van meerdere clusters

De TrueFoundry Control Plane biedt één centraal overzicht om alle Kubernetes-clusters in de organisatie te bekijken, verspreid over multicloud-providers en on-premise. Dit maakt het ook heel eenvoudig om workloads van het ene cluster naar het andere te verplaatsen met onze functie Clone and Promote.

Lagere kosten en minder onderhoud

De TrueFoundry-agent is een zeer lichtgewicht component die op elk afzonderlijk cluster draait, terwijl er slechts één exemplaar van de control plane nodig is. De control plane heeft meer bronnen nodig (3 CPU, 6 GB RAM), terwijl de agent slechts 0,2 CPU en 400 MB RAM nodig heeft. Naarmate het verkeer en de teams schalen, moeten we meestal meer clusters toevoegen op basis van regio's of teams. Maar de control plane hoeft niet te worden gerepliceerd, wat leidt tot lagere kosten en minder onderhoud.

Een kijkje in de TrueFoundry Control Plane

De TrueFoundry Control Plane bestaat uit meerdere microservices die de deployments, de opslag van modelmetadata, enz. orchestreren. De belangrijkste componenten van de TrueFoundry Control Plane zijn:

1. Web-UI

2. Microservices voor het orchestreren van deployments: De control plane bestaat uit enkele microservices om de deployments over de clusters te orchestreren en slaat ook live updates op van alle verbonden clusters in de compute plane.

3. Postgres-database: Deze wordt gebruikt om alle informatie over teams, geïmplementeerde services en hun metadata op te slaan.

Compute-Plane Cluster

We moeten enkele componenten op het Compute-Plane cluster installeren om optimaal te profiteren van TrueFoundry. De lijst is als volgt:

1. tfy-agent (Vereist):  Dit is de truefoundry-agent die de verbinding met de control plane initialiseert en helpt bij het coördineren van de instructies van de control plane.
2. ArgoCD (Vereist): ArgoCD wordt gebruikt om alle manifesten toe te passen op het Kubernetes-cluster. Dit is beter dan het uitvoeren van een helm install, omdat de ArgoCD-controller ervoor zorgt dat de interne status wordt gesynchroniseerd met de gewenste status in de manifesten en niet gevoelig is voor mislukte Helm-installaties.
3. Istio (Momenteel vereist, zal in de toekomst optioneel zijn): We vertrouwen momenteel op Istio als de Ingress-controller voor het cluster. We verplichten het uitvoeren van Istio-sidecars niet en ze kunnen desgewenst optioneel worden ingeschakeld voor use-cases zoals mutual TLS. We zijn ook van plan om de Gateway API's van Kubernetes te gebruiken, waardoor we kunnen werken met meerdere Ingress-controllers zoals Nginx, Linkerd, Traefik, enz.
4. Argo Workflows (Alleen vereist voor het uitvoeren van jobs): We gebruiken Argo Workflows voor het uitvoeren van alle jobs binnen het cluster vanwege de meer geavanceerde opties die het biedt in vergelijking met Kubernetes-jobs.
5. Argo Rollouts (Vereist): We gebruiken Argo Rollouts om Canary- en BlueGreen-rollouts op Kubernetes te ondersteunen. Dit is momenteel een vereiste voorwaarde, maar dit zal in de toekomst optioneel zijn.
6. Prometheus (Optioneel): Dit is een optionele afhankelijkheid die nodig is voor het tonen van metrieken zoals CPU, geheugen en verzoekaantallen voor de services.
7. KEDA (Optioneel): Dit is een optionele afhankelijkheid en nodig als u autoscaling wilt inschakelen voor uw workloads.
8. Loki (Optioneel): Dit helpt bij logaggregatie en is een optionele afhankelijkheid. U kunt altijd een andere log-aggregator gebruiken waar u bekend mee bent, zoals ELK Stack, CloudWatch, DataDog, enz.
9. Drivers (EFS, EBS, GPU): Deze zijn nodig als u GPU- of volume-ondersteuning nodig heeft in uw cluster.
10. Notebook Controller (Optioneel):  Dit is nodig als u Notebooks wilt aanbieden op het Kubernetes-cluster.

Beperkingen op de Kubernetes cluster-AMI

TrueFoundry kan werken met elke onderliggende AMI, inclusief Bottlerocket op AWS. Omdat de agent net als elke andere Helm chart op Kubernetes draait, hebben we geen beperkingen of vereisten voor de onderliggende AMI's en kan deze op elke AMI draaien, inclusief bare-metal machines.

Permissies voor tfy-agent

De tfy-agent voert alle acties op de Kubernetes-gebruiker uit namens de gebruikers die zijn ingelogd op het TrueFoundry-platform. Daarom vereist het beheerderstoegang tot een bepaalde set namespaces waarop de gebruikers applicaties mogen implementeren. We hebben functionaliteit om een bepaalde set namespaces op een black- of whitelist te zetten, en de agent kan alleen acties uitvoeren op die namespaces.

Authenticatie in TrueFoundry

TrueFoundry vertrouwt op een authenticatieserver op onze servers voor licentieverlening en authenticatie.

Autorisatie in TrueFoundry

TrueFoundry biedt een fijnmazige RBAC-besturing op tenant-, cluster-, workspace- en ML-repo-niveau. Om de RBAC-mechanismen in TrueFoundry te begrijpen, kunt u onze documentatie hier lezen: https://www.truefoundry.com/docs/platform/manage-user-roles-and-permissions

Alle autorisatieregels bevinden zich in de Postgres-tabel in de control plane en elke API-call wordt gecontroleerd om te zien of de gebruiker geautoriseerd is om die verbinding uit te voeren.

Image Build Pipeline in control-plane

TrueFoundry biedt een basis image build-pipeline die is geoptimaliseerd om images heel snel te bouwen op Kubernetes. Als u de pipeline voor het bouwen van images wilt aanpassen met statische controles of andere hulpprogramma's voor het scannen op kwetsbaarheden, zijn er twee benaderingen:

1. U kunt uw eigen CI-pipeline blijven gebruiken om images te bouwen en vervolgens de URI van het gebouwde image opgeven als invoer voor TrueFoundry-deployments.
2. U kunt de TrueFoundry build-pipeline aanpassen om de door u gewenste componenten op te nemen. Het is in feite een Argo Workflow en aangezien u in het Enterprise-plan eigenaar bent van de control plane, bent u vrij om deze naar wens aan te passen.

Secret Management in TrueFoundry

TrueFoundry integreert met de meest populaire opslaglocaties voor het beheer van geheimen. Het slaat de geheime waarden zelf niet op en bewaart alleen het pad naar die geheimen.