I det här inlägget visar vi hur Kubeflow på AWS (en AWS-specifik distribution av Kubeflow) som används med AWS Deep Learning-behållare och Amazon Elastic File System (Amazon EFS) förenklar samarbete och ger flexibilitet vid utbildning av modeller för djupinlärning i stor skala på både Amazon Elastic Kubernetes-tjänst (Amazon EKS) och Amazon SageMaker använder en hybridarkitekturmetod.

Utveckling av maskininlärning (ML) bygger på komplexa och ständigt utvecklande ramverk och verktygssatser med öppen källkod, såväl som komplexa och ständigt utvecklande hårdvaru-ekosystem. Detta utgör en utmaning när man skalar ut ML-utveckling till ett kluster. Behållare erbjuder en lösning, eftersom de helt kan kapsla in inte bara träningskoden, utan hela beroendestapeln ner till hårdvarubiblioteken. Detta säkerställer en ML-miljö som är konsekvent och portabel, och underlättar reproducerbarheten av träningsmiljön på varje enskild nod i träningsklustret.

Kubernetes är ett allmänt använt system för automatisering av infrastrukturdistribution, resursskalning och hantering av dessa containeriserade applikationer. Kubernetes byggdes dock inte med ML i åtanke, så det kan kännas kontraintuitivt för datavetare på grund av dess stora beroende av YAML-specifikationsfiler. Det finns ingen Jupyter-upplevelse, och det finns inte många ML-specifika funktioner, såsom arbetsflödeshantering och pipelines, och andra funktioner som ML-experter förväntar sig, såsom hyperparameterjustering, modellvärd och andra. Sådana funktioner kan byggas, men Kubernetes var inte designad för att göra detta som dess primära mål.

Gemenskapen med öppen källkod tog notis och utvecklade ett lager ovanpå Kubernetes som heter Kubeflow. Kubeflow syftar till att göra distributionen av end-to-end ML-arbetsflöden på Kubernetes enkel, portabel och skalbar. Du kan använda Kubeflow för att distribuera de bästa öppna källkodssystemen för ML till olika infrastrukturer.

Kubeflow och Kubernetes ger flexibilitet och kontroll till dataforskarteam. Det är dock fortfarande en utmaning att säkerställa högt utnyttjande av utbildningskluster som körs i skala med minskade driftskostnader.

Det här inlägget visar hur kunder som har restriktioner på plats eller befintliga Kubernetes-investeringar kan ta itu med denna utmaning genom att använda Amazon EKS och Kubeflow på AWS för att implementera en ML-pipeline för distribuerad utbildning baserad på ett självhanterat tillvägagångssätt, och använda fullt hanterad SageMaker för en kostnadsoptimerad, helt hanterad och produktionsskala utbildningsinfrastruktur. Detta inkluderar steg-för-steg-implementering av en hybrid distribuerad utbildningsarkitektur som låter dig välja mellan de två metoderna under körning, vilket ger maximal kontroll och flexibilitet med stränga behov för dina implementeringar. Du kommer att se hur du kan fortsätta använda bibliotek med öppen källkod i ditt träningsskript för djupinlärning och fortfarande göra det kompatibelt att köras på både Kubernetes och SageMaker på ett plattformsoberoende sätt.

Hur hjälper Kubeflow på AWS och SageMaker?

Neurala nätverksmodeller byggda med ramverk för djupinlärning som TensorFlow, PyTorch, MXNet och andra ger mycket högre noggrannhet genom att använda betydligt större träningsdatauppsättningar, särskilt i användningsfall för datorseende och naturlig språkbehandling. Men med stora utbildningsdataset tar det längre tid att träna djupinlärningsmodellerna, vilket i slutändan saktar ner tiden till marknaden. Om vi ​​kunde skala ut ett kluster och minska utbildningstiden för modellen från veckor till dagar eller timmar, kan det ha en enorm inverkan på produktivitet och affärshastighet.

Amazon EKS hjälper till att tillhandahålla det hanterade Kubernetes-kontrollplanet. Du kan använda Amazon EKS för att skapa storskaliga utbildningskluster med CPU- och GPU-instanser och använda Kubeflow-verktygssatsen för att tillhandahålla ML-vänliga verktyg med öppen källkod och operationalisera ML-arbetsflöden som är portabla och skalbara med hjälp av Kubeflow Pipelines för att förbättra ditt teams produktivitet och minska tiden till marknaden.

Det kan dock finnas ett par utmaningar med detta tillvägagångssätt:

• Säkerställa maximalt utnyttjande av ett kluster över datavetenskapsteam. Till exempel bör du tillhandahålla GPU-instanser på begäran och säkerställa dess höga utnyttjande för krävande produktionsskalauppgifter som djupinlärningsträning, och använda CPU-instanser för mindre krävande uppgifter såsom dataförbearbetning
• Säkerställa hög tillgänglighet för tunga Kubeflow-infrastrukturkomponenter, inklusive databas, lagring och autentisering, som distribueras i Kubernetes klusterarbetarnod. Till exempel genererar Kubeflow-kontrollplanet artefakter (som MySQL-instanser, podloggar eller MinIO-lagring) som växer över tiden och som behöver ändra storlek på lagringsvolymer med kontinuerlig övervakning.
• Att dela utbildningsdataset, kod och beräkningsmiljöer mellan utvecklare, utbildningskluster och projekt är utmanande. Till exempel, om du arbetar med din egen uppsättning bibliotek och de biblioteken har starka ömsesidiga beroenden, blir det riktigt svårt att dela och köra samma kod mellan datavetare i samma team. Dessutom kräver varje träningskörning att du laddar ner träningsdatauppsättningen och bygger träningsbilden med nya kodändringar.

Kubeflow på AWS hjälper till att hantera dessa utmaningar och tillhandahåller en semihanterad Kubeflow-produkt av företagsklass. Med Kubeflow på AWS kan du ersätta vissa Kubeflow-kontrollplanstjänster som databas, lagring, övervakning och användarhantering med AWS-hanterade tjänster som Amazon Relational Databas Service (Amazon RDS), Amazon enkel lagringstjänst (Amazon S3), Amazon Elastic File System (Amazon EFS), Amazon FSx, amazoncloudwatchoch Amazon Cognito.

Genom att ersätta dessa Kubeflow-komponenter frikopplas kritiska delar av Kubeflow-kontrollplanet från Kubernetes, vilket ger en säker, skalbar, motståndskraftig och kostnadsoptimerad design. Detta tillvägagångssätt frigör också lagrings- och beräkningsresurser från EKS-dataplanet, vilket kan behövas av applikationer som distribuerad modellutbildning eller användarservrar för bärbara datorer. Kubeflow på AWS tillhandahåller också inbyggd integration av Jupyter-datorer med Deep Learning Container (DLC)-bilder, som är förpackade och förkonfigurerade med AWS-optimerade ramverk för djupinlärning som PyTorch och TensorFlow som gör att du kan börja skriva din träningskod direkt utan att behöva hantera med beroendeupplösningar och ramverksoptimeringar. Dessutom låter Amazon EFS-integration med träningskluster och utvecklingsmiljön dig dela din kod och bearbetade träningsdatauppsättning, vilket undviker att bygga containerbilden och ladda enorma datauppsättningar efter varje kodändring. Dessa integrationer med Kubeflow på AWS hjälper dig att påskynda modellbyggandet och utbildningstiden och möjliggöra bättre samarbete med enklare data- och koddelning.

Kubeflow på AWS hjälper till att bygga en mycket tillgänglig och robust ML-plattform. Den här plattformen ger flexibilitet att bygga och träna modeller för djupinlärning och ger tillgång till många verktygssatser med öppen källkod, insikter i loggar och interaktiv felsökning för experiment. Men att uppnå maximalt utnyttjande av infrastrukturresurser samtidigt som man tränar modeller för djupinlärning på hundratals GPU:er innebär fortfarande en hel del operativa omkostnader. Detta skulle kunna åtgärdas genom att använda SageMaker, som är en helt hanterad tjänst designad och optimerad för att hantera prestanda och kostnadsoptimerade utbildningskluster som endast tillhandahålls när de begärs, skalas efter behov och stängs av automatiskt när jobb slutförs, vilket ger nära 100 % resursanvändning. Du kan integrera SageMaker med Kubeflow Pipelines med hanterade SageMaker-komponenter. Detta gör att du kan operationalisera ML-arbetsflöden som en del av Kubeflow-pipelines, där du kan använda Kubernetes för lokal utbildning och SageMaker för utbildning i produktskala i en hybridarkitektur.

Lösningsöversikt

Följande arkitektur beskriver hur vi använder Kubeflow Pipelines för att bygga och distribuera portabla och skalbara end-to-end ML-arbetsflöden för att villkorligt köra distribuerad utbildning på Kubernetes med hjälp av Kubeflow-träning eller SageMaker baserat på runtime-parametern.

Kubeflow-utbildning är en grupp Kubernetes-operatörer som lägger till Kubeflow stöd för distribuerad utbildning av ML-modeller med hjälp av olika ramverk som TensorFlow, PyTorch och andra. pytorch-operator är Kubeflow-implementeringen av Kubernetes anpassad resurs (PyTorchJob) för att köra distribuerade PyTorch-utbildningsjobb på Kubernetes.

Vi använder PyTorchJob Launcher-komponenten som en del av Kubeflow-pipelinen för att köra PyTorch distribuerad utbildning under experimentfasen när vi behöver flexibilitet och tillgång till alla underliggande resurser för interaktiv felsökning och analys.

Vi använder även SageMaker-komponenter för Kubeflow Pipelines för att köra vår modellutbildning i produktionsskala. Detta gör att vi kan dra fördel av kraftfulla SageMaker-funktioner som fullt hanterade tjänster, distribuerade utbildningsjobb med maximalt GPU-utnyttjande och kostnadseffektiv utbildning genom Amazon Elastic Compute Cloud (Amazon EC2) Spotinstanser.

Som en del av processen för att skapa arbetsflöden slutför du följande steg (som visas i föregående diagram) för att skapa denna pipeline:

1. Använd Kubeflow-manifestfilen för att skapa en Kubeflow-instrumentpanel och komma åt Jupyter-anteckningsböcker från Kubeflows centrala instrumentpanel.
2. Använd Kubeflow pipeline SDK för att skapa och kompilera Kubeflow pipelines med Python-kod. Pipeline-kompilering konverterar Python-funktionen till en arbetsflödesresurs, som är ett Argo-kompatibelt YAML-format.
3. Använd Kubeflow Pipelines SDK-klienten för att anropa pipelinetjänstens slutpunkt för att köra pipelinen.
4. Pipelinen utvärderar de villkorliga körtidsvariablerna och bestämmer mellan SageMaker eller Kubernetes som målkörningsmiljö.
5. Använd Kubeflow PyTorch Launcher-komponenten för att köra distribuerad utbildning i den inbyggda Kubernetes-miljön, eller använd SageMaker-komponenten för att skicka in utbildningen på SageMaker-hanterade plattform.

Följande figur visar Kubeflow Pipelines-komponenterna som är involverade i arkitekturen som ger oss flexibiliteten att välja mellan Kubernetes eller SageMaker distribuerade miljöer.

Workflow för användningsfall

Vi använder följande steg-för-steg-metod för att installera och köra användningsfallet för distribuerad utbildning med Amazon EKS och SageMaker med Kubeflow på AWS.

Förutsättningar

För detta genomgång bör du ha följande förutsättningar:

• An AWS-konto.
• En maskin med Docker och AWS-kommandoradsgränssnitt (AWS CLI) installerad.
• Alternativt kan du använda AWS Cloud9, en molnbaserad integrerad utvecklingsmiljö (IDE) som gör det möjligt att slutföra allt arbete från din webbläsare. För installationsinstruktioner, se Ställ in Cloud9 IDE. Från din Cloud9-miljö väljer du plustecknet och öppnar en ny terminal.
• Skapa en roll med namnet sagemakerrole. Lägg till hanterade policyer AmazonSageMakerFullAccess och AmazonS3FullAccess för att ge SageMaker tillgång till S3-hinkar. Den här rollen används av SageMaker-jobb som skickats in som en del av Kubeflow Pipelines-steget.
• Se till att ditt konto har SageMaker Training resurstypgräns för ml.p3.2xlarge ökat till 2 med hjälp av Service Quotas Console

1. Installera Amazon EKS och Kubeflow på AWS

Du kan använda flera olika metoder för att bygga ett Kubernetes-kluster och distribuera Kubeflow. I det här inlägget fokuserar vi på ett tillvägagångssätt som vi tror förenklar processen. Först skapar vi ett EKS-kluster, sedan distribuerar vi Kubeflow på AWS v1.5 på det. För var och en av dessa uppgifter använder vi ett motsvarande öppen källkodsprojekt som följer principerna för Gör ramverk. Istället för att installera en uppsättning förutsättningar för varje uppgift, bygger vi Docker-containrar som har alla nödvändiga verktyg och utför uppgifterna inifrån behållarna.

Vi använder Do Framework i det här inlägget, som automatiserar Kubeflow-distributionen med Amazon EFS som ett tillägg. För de officiella Kubeflow på AWS-distributionsalternativen för produktionsdistributioner, se konfiguration.

Konfigurera den aktuella arbetskatalogen och AWS CLI

Vi konfigurerar en arbetskatalog så att vi kan referera till den som utgångspunkten för stegen som följer:

export working_dir=$PWD

Vi konfigurerar även en AWS CLI-profil. För att göra det behöver du ett åtkomstnyckel-ID och en hemlig åtkomstnyckel för en AWS identitets- och åtkomsthantering (JAG ÄR) användare konto med administrativa rättigheter (bifoga den befintliga hanterade policyn) och programmatisk åtkomst. Se följande kod:

aws configure --profile=kubeflow
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: us-west-2
Default output format [None]: json

# (In Cloud9, select “Cancel” and “Permanently disable” when the AWS managed temporary credentials dialog pops up)

export AWS_PROFILE=kubeflow

1.1 Skapa ett EKS-kluster

Om du redan har ett EKS-kluster tillgängligt kan du hoppa till nästa avsnitt. För det här inlägget använder vi aws-do-eks projekt att skapa vårt kluster.

1. Klona först projektet i din arbetskatalog

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-eks
   cd aws-do-eks/

2. Bygg sedan och kör aws-do-eks behållare:

   ./build.sh
   ./run.sh

   Smakämnen build.sh script skapar en Docker-containeravbildning som har alla nödvändiga verktyg och skript för provisionering och drift av EKS-kluster. De run.sh script startar en behållare med den skapade Docker-avbildningen och behåller den, så att vi kan använda den som vår EKS-hanteringsmiljö. För att se statusen för din aws-do-eks container kan du springa ./status.sh. Om behållaren har statusen Avslutet kan du använda ./start.sh skript för att få upp behållaren, eller för att starta om behållaren, kan du köra ./stop.sh följd av ./run.sh.

3. Öppna ett skal i löpningen aws-do-eks behållare:
4. För att granska EKS-klusterkonfigurationen för vår KubeFlow-distribution, kör följande kommando:

   vi ./eks-kubeflow.yaml

   Som standard skapar den här konfigurationen ett kluster med namnet eks-kubeflow i us-west-2 Region med sex m5.xlarge noder. Dessutom är EBS-volymkryptering inte aktiverad som standard. Du kan aktivera det genom att lägga till "volumeEncrypted: true" till nodgruppen och den krypterar med standardnyckeln. Ändra andra konfigurationsinställningar om det behövs.

5. För att skapa klustret, kör följande kommando:

   export AWS_PROFILE=kubeflow
   eksctl create cluster -f ./eks-kubeflow.yaml

   Klustrets provisioneringsprocessen kan ta upp till 30 minuter.

6. För att verifiera att klustret skapades framgångsrikt, kör följande kommando:

   kubectl get nodes

   Utdata från föregående kommando för ett kluster som skapades framgångsrikt ser ut som följande kod:

   root@cdf4ecbebf62:/eks# kubectl get nodes
   NAME                                           STATUS   ROLES    AGE   VERSION
   ip-192-168-0-166.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-13-28.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-45-240.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-63-84.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-75-56.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-85-226.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326

Skapa en EFS-volym för SageMaker-utbildningsjobbet

I det här användningsfallet snabbar du på SageMaker-träningsjobbet genom att träna djupinlärningsmodeller från data som redan finns lagrad i Amazon EFS. Det här valet har fördelen av att direkt lansera dina träningsjobb från data i Amazon EFS utan att dataförflyttning krävs, vilket resulterar i snabbare träningsstarttider.

Vi skapar en EFS-volym och distribuerar EFS Container Storage Interface (CSI)-drivrutinen. Detta åstadkoms av ett distributionsskript som finns i /eks/deployment/csi/efs inom aws-do-eks behållare.

Det här skriptet förutsätter att du har ett EKS-kluster på ditt konto. Uppsättning CLUSTER_NAME= om du har mer än ett EKS-kluster.

cd /eks/deployment/csi/efs
./deploy.sh

Det här skriptet tillhandahåller en EFS-volym och skapar monteringsmål för undernäten i klustrets VPC. Den distribuerar sedan EFS CSI-drivrutinen och skapar efs-sc förvaringsklass och efs-pv ihållande volym i EKS-klustret.

Efter framgångsrikt slutförande av skriptet bör du se utdata som följande:

Generating efs-sc.yaml ...

Applying efs-sc.yaml ...
storageclass.storage.k8s.io/efs-sc created
NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
efs-sc          efs.csi.aws.com         Delete          Immediate              false                  1s
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  36m

Generating efs-pv.yaml ...
Applying efs-pv.yaml ...
persistentvolume/efs-pv created
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWX            Retain           Available           efs-sc                  10s

Done ...

Skapa en Amazon S3 VPC-slutpunkt

Du använder en privat VPC som ditt SageMaker-utbildningsjobb och EFS-filsystem har tillgång till. För att ge SageMaker-utbildningsklustret tillgång till S3-hinkarna från din privata VPC skapar du en VPC-slutpunkt:

cd /eks/vpc 
export CLUSTER_NAME= 
export REGION= 
./vpc-endpoint-create.sh

Du kan nu avsluta aws-do-eks containerskal och fortsätt till nästa avsnitt:

exit

root@cdf4ecbebf62:/eks/deployment/csi/efs# exit
exit
TeamRole:~/environment/aws-do-eks (main) $

1.2 Distribuera Kubeflow på AWS på Amazon EKS

För att distribuera Kubeflow på Amazon EKS använder vi aws-do-kubeflow-projekt.

1. Klona förvaret med följande kommandon:

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-kubeflow
   cd aws-do-kubeflow

2. Konfigurera sedan projektet:

   ./config.sh

   Detta skript öppnar projektets konfigurationsfil i en textredigerare. Det är viktigt för AWS_REGION att ställas in på den region som ditt kluster befinner sig i, liksom AWS_CLUSTER_NAME för att matcha namnet på klustret som du skapade tidigare. Som standard är din konfiguration redan korrekt inställd, så om du inte behöver göra några ändringar är det bara att stänga redigeraren.

   ./build.sh
   ./run.sh
   ./exec.sh

   Smakämnen build.sh skriptet skapar en Docker-containeravbildning som har alla verktyg som behövs för att distribuera och hantera Kubeflow på ett befintligt Kubernetes-kluster. De run.sh skriptet startar en behållare med Docker-avbildningen och exec.sh-skriptet öppnar ett kommandoskal i behållaren, som vi kan använda som vår Kubeflow-hanteringsmiljö. Du kan använda ./status.sh skript för att se om aws-do-kubeflow behållaren är igång och den ./stop.sh och ./run.sh skript för att starta om det vid behov.

3. När du har ett skal öppnat i aws-do-eks container kan du verifiera att det konfigurerade klusterkontexten är som förväntat:

   root@ip-172-31-43-155:/kubeflow# kubectx
   kubeflow@eks-kubeflow.us-west-2.eksctl.io

4. För att distribuera Kubeflow på EKS-klustret, kör deploy.sh manus:

   ./kubeflow-deploy.sh

   Distributionen är framgångsrik när alla poddar i kubeflow-namnområdet går in i läge Kör. En typisk utdata ser ut som följande kod:

   Waiting for all Kubeflow pods to start Running ...
   
   Waiting for all Kubeflow pods to start Running ...
   
   Restarting central dashboard ...
   pod "centraldashboard-79f489b55-vr6lp" deleted
   /kubeflow/deploy/distro/aws/kubeflow-manifests /kubeflow/deploy/distro/aws
   /kubeflow/deploy/distro/aws
   
   Kubeflow deployment succeeded
   Granting cluster access to kubeflow profile user ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   clusterrolebinding.rbac.authorization.k8s.io/kubeflow-user-example-com-cluster-admin-binding created
   Setting up access to Kubeflow Pipelines ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   
   Creating pod-default for namespace kubeflow-user-example-com ...
   poddefault.kubeflow.org/access-ml-pipeline created

5. För att övervaka tillståndet för KubeFlow-poddarna, i ett separat fönster, kan du använda följande kommando:

   watch kubectl -n kubeflow get pods

6. Presse Ctrl + C när alla poddar körs, exponera sedan Kubeflow-instrumentpanelen utanför klustret genom att köra följande kommando:

   ./kubeflow-expose.sh

Du bör se utdata som ser ut som följande kod:

root@ip-172-31-43-155:/kubeflow# ./kubeflow-expose.sh
root@ip-172-31-43-155:/kubeflow# Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

Detta kommando vidarebefordrar Istio ingress gateway-tjänsten från ditt kluster till din lokala port 8080. För att komma åt Kubeflow-instrumentpanelen, besök http://localhost:8080 och logga in med standardanvändaruppgifterna (användare@exempel.com/12341234). Om du kör aws-do-kubeflow container i AWS Cloud9, då kan du välja FörhandsvisningOch välj sedan Förhandsgranska program som körs. Om du kör på Docker Desktop kan du behöva köra ./kubeflow-expose.sh skript utanför aws-do-kubeflow behållare.

2. Ställ in Kubeflow på AWS-miljön

För att ställa in din Kubeflow på AWS-miljö skapar vi en EFS-volym och en Jupyter-anteckningsbok.

2.1 Skapa en EFS-volym

Utför följande steg för att skapa en EFS-volym:

• Välj på Kubeflow-instrumentpanelen volymerna i navigeringsfönstret.
• Välj Ny volym.
• För Namn , stiga på efs-sc-claim.
• För Volymstorlek, stiga på 10.
• För Förvaringsklassväljer efs-sc.
• För Åtkomstlägeväljer ReadWriteOnce.
• Välja Skapa.

2.2 Skapa en Jupyter-anteckningsbok

För att skapa en ny anteckningsbok, utför följande steg:

• Välj på Kubeflow-instrumentpanelen bärbara datorer i navigeringsfönstret.
• Välja Ny anteckningsbok.
• För Namn , stiga på aws-hybrid-nb.
• För Jupyter Docket Image, välj bilden c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (den senaste tillgängliga Jupyter-pytorch DLC-bilden).
• För CPU, stiga på 1.
• För Minne, stiga på 5.
• För GPUs, lämna som Ingen.
• Gör inga ändringar i Arbetsyta Volym sektion.
• I Datavolymer avsnitt väljer Fäst befintlig volym och expandera avsnittet Befintlig volym
• För Namn väljer efs-sc-claim.
• För Bergsväg, stiga på /home/jovyan/efs-sc-claim.
  Detta monterar EFS-volymen på din Jupyter notebook-pod, och du kan se mappen efs-sc-claim i ditt Jupyter labbgränssnitt. Du sparar träningsdatauppsättningen och träningskoden i den här mappen så att träningsklustren kan komma åt den utan att behöva bygga om behållarbilderna för testning.
• Välja Tillåt åtkomst till Kubeflow Pipelines i avsnittet Konfiguration.
• Välja Starta.
  Kontrollera att din anteckningsbok har skapats (det kan ta ett par minuter).
• På bärbara datorer sida, välj Kontakta för att logga in i JupyterLab-miljön.
• På gå meny, välj Klona ett arkiv.
• För Klona en repo, stiga på https://github.com/aws-samples/aws-do-kubeflow.
  

3. Kör delad träning

När du har ställt in Jupyter-anteckningsboken kan du köra hela demon genom att använda följande steg på hög nivå från mappen aws-do-kubeflow/workshop i det klonade förvaret:

• PyTorch Distributed Data Parallel (DDP) utbildningsskript: Se PyTorch DDP-träningsskriptet cifar10-distributed-gpu-final.py, som inkluderar ett exempel på ett konvolutionellt neuralt nätverk och logik för att distribuera utbildning på en CPU- och GPU-kluster med flera noder. (Se 3.1 för detaljer)
• Installera bibliotek: Kör anteckningsboken 0_initialize_dependencies.ipynb för att initiera alla beroenden. (Se 3.2 för detaljer)
• Kör distribuerad PyTorch-jobbträning på Kubernetes: Kör anteckningsboken 1_submit_pytorchdist_k8s.ipynb att skapa och skicka distribuerad utbildning på en primär och två arbetarbehållare med hjälp av Kubernetes anpassade resurs PyTorchJob YAML-fil med Python-kod. (Se 3.3 för detaljer)
• Skapa en hybrid Kubeflow-pipeline: Kör anteckningsboken 2_create_pipeline_k8s_sagemaker.ipynb att skapa den hybrida Kubeflow-pipeline som kör distribuerad utbildning på antingen SageMaker eller Amazon EKS med hjälp av runtime-variabeln training_runtime. (Se 3.4 för detaljer)

Se till att du körde anteckningsboken 1_submit_pytorchdist_k8s.ipynb innan du startar anteckningsboken 2_create_pipeline_k8s_sagemaker.ipynb.

I de efterföljande avsnitten diskuterar vi vart och ett av dessa steg i detalj.

3.1 PyTorch Distributed Data Parallel (DDP) träningsskript

Som en del av den distribuerade utbildningen tränar vi en klassificeringsmodell skapad av ett enkelt konvolutionellt neuralt nätverk som arbetar på CIFAR10-datauppsättningen. Träningsmanuset cifar10-distributed-gpu-final.py innehåller endast biblioteken med öppen källkod och är kompatibel att köra både på Kubernetes och SageMaker träningskluster på antingen GPU-enheter eller CPU-instanser. Låt oss titta på några viktiga aspekter av träningsskriptet innan vi kör våra anteckningsbokexempel.

Vi använder torch.distributed modul, som innehåller PyTorch-stöd och kommunikationsprimitiver för parallellitet i flera processer över noder i klustret:

...
import torch
import torch.distributed as dist
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
import torch.utils.data
import torch.utils.data.distributed
import torchvision
from torchvision import datasets, transforms
...

Vi skapar en enkel bildklassificeringsmodell med en kombination av faltning, max pooling och linjära lager som en relu-aktiveringsfunktion appliceras på i det framåtgående passet av modellträningen:

# Define models
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(3, 6, 5)
self.pool = nn.MaxPool2d(2, 2)
self.conv2 = nn.Conv2d(6, 16, 5)
self.fc1 = nn.Linear(16 * 5 * 5, 120)
self.fc2 = nn.Linear(120, 84)
self.fc3 = nn.Linear(84, 10)

def forward(self, x):
x = self.pool(F.relu(self.conv1(x)))
x = self.pool(F.relu(self.conv2(x)))
x = x.view(-1, 16 * 5 * 5)
x = F.relu(self.fc1(x))
x = F.relu(self.fc2(x))
x = self.fc3(x)
return x

Vi använder ficklampan DataLoader som kombinerar datamängden och DistributedSampler (laddar en delmängd av data på ett distribuerat sätt med hjälp av torch.nn.parallel.DistributedDataParallel) och tillhandahåller en enprocess eller multiprocess iterator över data:

# Define data loader for training dataset
def _get_train_data_loader(batch_size, training_dir, is_distributed):
logger.info("Get train data loader")

train_set = torchvision.datasets.CIFAR10(root=training_dir,
train=True,
download=False,
transform=_get_transforms())

train_sampler = (
torch.utils.data.distributed.DistributedSampler(train_set) if is_distributed else None
)

return torch.utils.data.DataLoader(
train_set,
batch_size=batch_size,
shuffle=train_sampler is None,
sampler=train_sampler)
...

Om träningsklustret har GPU:er kör skriptet träningen på CUDA-enheter och enhetsvariabeln innehåller standard-CUDA-enheten:

device = "cuda" if torch.cuda.is_available() else "cpu"
...

Innan du kör distribuerad träning med PyTorch DistributedDataParallel för att köra distribuerad bearbetning på flera noder måste du initiera den distribuerade miljön genom att anropa init_process_group. Detta initieras på varje maskin i träningsklustret.

dist.init_process_group(backend=args.backend, rank=host_rank, world_size=world_size)
...

Vi instansierar klassificeringsmodellen och kopierar över modellen till målenheten. Om distribuerad träning är aktiverad för att köras på flera noder, DistributedDataParallel klass används som ett omslagsobjekt runt modellobjektet, vilket möjliggör synkron distribuerad träning över flera maskiner. Indata delas upp på batchdimensionen och en kopia av modellen placeras på varje maskin och varje enhet.

model = Net().to(device)

if is_distributed:
model = torch.nn.parallel.DistributedDataParallel(model)

...

3.2 Installera bibliotek

Du kommer att installera alla nödvändiga bibliotek för att köra PyTorch-exemplet med distribuerad träning. Detta inkluderar Kubeflow Pipelines SDK, Training Operator Python SDK, Python-klient för Kubernetes och Amazon SageMaker Python SDK.

#Please run the below commands to install necessary libraries

!pip install kfp==1.8.4

!pip install kubeflow-training

!pip install kubernetes

!pip install sagemaker

3.3 Kör distribuerad PyTorch-jobbträning på Kubernetes

Anteckningsboken 1_submit_pytorchdist_k8s.ipynb skapar den anpassade Kubernetes-resursen PyTorchJob YAML-filen med hjälp av Kubeflow-träning och Kubernetes-klienten Python SDK. Följande är några viktiga utdrag från den här anteckningsboken.

Vi skapar PyTorchJob YAML med de primära och arbetsbehållarna som visas i följande kod:

# Define PyTorchJob custom resource manifest
pytorchjob = V1PyTorchJob(
api_version="kubeflow.org/v1",
kind="PyTorchJob",
metadata=V1ObjectMeta(name=pytorch_distributed_jobname,namespace=user_namespace),
spec=V1PyTorchJobSpec(
run_policy=V1RunPolicy(clean_pod_policy="None"),
pytorch_replica_specs={"Master": master,
"Worker": worker}
)
)

Detta skickas till Kubernetes kontrollplan med hjälp av PyTorchJobClient:

# Creates and Submits PyTorchJob custom resource file to Kubernetes
pytorchjob_client = PyTorchJobClient()

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Visa Kubernetes träningsloggar

Du kan se träningsloggarna antingen från samma Jupyter-anteckningsbok med Python-kod eller från Kubernetes-klientskalet.

3.4 Skapa en hybrid Kubeflow-pipeline

Anteckningsboken 2_create_pipeline_k8s_sagemaker.ipynb skapar en hybrid Kubeflow-pipeline baserad på villkorlig körtidsvariabel training_runtime, som visas i följande kod. Anteckningsboken använder Kubeflow Pipelines SDK och det tillhandahålls en uppsättning Python-paket för att specificera och köra ML-arbetsflödespipelines. Som en del av denna SDK använder vi följande paket:

• Det domänspecifika språket (DSL)-paketdekoratören dsl.pipeline, som dekorerar Python-funktionerna för att returnera en pipeline
• Smakämnen dsl.Condition paket, som representerar en grupp av operationer som endast körs när ett visst villkor är uppfyllt, som att kontrollera training_runtime värde som sagemaker or kubernetes

Se följande kod:

# Define your training runtime value with either 'sagemaker' or 'kubernetes'
training_runtime='sagemaker'

# Create Hybrid Pipeline using Kubeflow PyTorch Training Operators and Amazon SageMaker Service
@dsl.pipeline(name="PyTorch Training pipeline", description="Sample training job test")
def pytorch_cnn_pipeline():

# Pipeline Step 1: to evaluate the condition. You can enter any logic here. For demonstration we are checking if GPU is needed for training
condition_result = check_condition_op(training_runtime)

# Pipeline Step 2: to run training on Kuberentes using PyTorch Training Operators. This will be executed if gpus are not needed
with dsl.Condition(condition_result.output == 'kubernetes', name="PyTorch_Comp"):
train_task = pytorch_job_op(
name=training_job_name,
namespace=user_namespace,
master_spec=json.dumps(master_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_master_spec.yml
worker_spec=json.dumps(worker_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_worker_spec.yml
delete_after_done=False
).after(condition_result)

# Pipeline Step 3: to run training on SageMaker using SageMaker Components for Pipeline. This will be executed if gpus are needed
with dsl.Condition(condition_result.output == 'sagemaker', name="SageMaker_Comp"):
training = sagemaker_train_op(
region=region,
image=train_image,
job_name=training_job_name,
training_input_mode=training_input_mode,
hyperparameters='{ 
"backend": "'+str(pytorch_backend)+'", 
"batch-size": "64", 
"epochs": "3", 
"lr": "'+str(learning_rate)+'", 
"model-type": "custom", 
"sagemaker_container_log_level": "20", 
"sagemaker_program": "cifar10-distributed-gpu-final.py", 
"sagemaker_region": "us-west-2", 
"sagemaker_submit_directory": "'+source_s3+'" 
}',
channels=channels,
instance_type=instance_type,
instance_count=instance_count,
volume_size=volume_size,
max_run_time=max_run_time,
model_artifact_path=f's3://{bucket_name}/jobs',
network_isolation=network_isolation,
traffic_encryption=traffic_encryption,
role=role,
vpc_subnets=subnet_id,
vpc_security_group_ids=security_group_id
).after(condition_result)

Vi konfigurerar SageMaker distribuerad träning med två ml.p3.2xlarge instanser.

Efter att pipelinen har definierats kan du kompilera pipelinen till en Argo YAML-specifikation med hjälp av Kubeflow Pipelines SDK:s kfp.compiler paket. Du kan köra denna pipeline med hjälp av Kubeflow Pipeline SDK-klienten, som anropar Pipelines-tjänstens slutpunkt och skickar in lämpliga autentiseringsrubriker direkt från anteckningsboken. Se följande kod:

# DSL Compiler that compiles pipeline functions into workflow yaml.
kfp.compiler.Compiler().compile(pytorch_cnn_pipeline, "pytorch_cnn_pipeline.yaml")

# Connect to Kubeflow Pipelines using the Kubeflow Pipelines SDK client
client = kfp.Client()

experiment = client.create_experiment(name="kubeflow")

# Run a specified pipeline
my_run = client.run_pipeline(experiment.id, "pytorch_cnn_pipeline", "pytorch_cnn_pipeline.yaml")

# Please click “Run details” link generated below this cell to view your pipeline. You can click every pipeline step to see logs.

Om du får en sagemaker import fel, kör !pip install sagemaker och starta om kärnan (på Kärna meny, välj Starta om Kernel).

Välj Kör detaljer länk under den sista cellen för att se Kubeflow-pipelinen.

Upprepa steget att skapa pipeline med training_runtime='kubernetes' för att testa pipelinekörningen i en Kubernetes-miljö. De training_runtime variabel kan också skickas i din CI/CD-pipeline i ett produktionsscenario.

Visa Kubeflows pipelinekörningsloggar för SageMaker-komponenten

Följande skärmdump visar våra pipelinedetaljer för SageMaker-komponenten.

Välj träningsjobbet steg och på Loggar fliken, välj länken CloudWatch-loggar för att komma åt SageMaker-loggarna.

Följande skärmdump visar CloudWatch-loggarna för var och en av de två ml.p3.2xlarge-instanserna.

Välj någon av grupperna för att se loggarna.

Visa Kubeflows pipelinekörningsloggar för Kubeflow PyTorchJob Launcher-komponenten

Följande skärmdump visar pipelinedetaljerna för vår Kubeflow-komponent.

Kör följande kommandon med Kubectl på ditt Kubernetes-klientskal som är anslutet till Kubernetes-klustret för att se loggarna (ersätt ditt namnområde och podnamn):

kubectl get pods -n kubeflow-user-example-com
kubectl logs  -n kubeflow-user-example-com -f

4.1 Städa upp

För att rensa upp alla resurser vi skapat på kontot måste vi ta bort dem i omvänd ordning.

1. Ta bort Kubeflow-installationen genom att köra ./kubeflow-remove.sh i aws-do-kubeflow behållare. Den första uppsättningen kommandon är valfria och kan användas om du inte redan har ett kommandoskal i din aws-do-kubeflow behållare öppen.

   cd aws-do-kubeflow
   ./status.sh
   ./start.sh
   ./exec.sh
   
   ./kubeflow-remove.sh

2. Från aws-do-eks container-mappen, ta bort EFS-volymen. Den första uppsättningen kommandon är valfri och kan användas om du inte redan har ett kommandoskal i din aws-do-eks behållare öppen.

   cd aws-do-eks
   ./status.sh
   ./start.sh
   ./exec.sh
   
   cd /eks/deployment/csi/efs
   ./delete.sh
   ./efs-delete.sh

   Att ta bort Amazon EFS är nödvändigt för att släppa nätverksgränssnittet som är kopplat till den VPC vi skapade för vårt kluster. Observera att om du tar bort EFS-volymen förstörs all data som lagras på den.

3. Från aws-do-eks behållare, kör eks-delete.sh skript för att ta bort klustret och alla andra resurser som är associerade med det, inklusive VPC:n:

   cd /eks
   ./eks-delete.sh

Sammanfattning

I det här inlägget diskuterade vi några av de typiska utmaningarna med distribuerad modellträning och ML-arbetsflöden. Vi gav en översikt över Kubeflow på AWS-distribution och delade två projekt med öppen källkod (aws-do-eks och aws-do-kubeflow) som förenklar tillhandahållandet av infrastrukturen och distributionen av Kubeflow på den. Slutligen beskrev och demonstrerade vi en hybridarkitektur som gör det möjligt för arbetsbelastningar att sömlöst övergå mellan att köras på en självhanterad Kubernetes och en helt hanterad SageMaker-infrastruktur. Vi uppmuntrar dig att använda denna hybridarkitektur för dina egna användningsfall.

Du kan följa AWS Labs arkiv för att spåra alla AWS-bidrag till Kubeflow. Du hittar oss också på Kubeflow #AWS Slack Channel; din feedback där hjälper oss att prioritera nästa funktioner för att bidra till Kubeflow-projektet.

Särskilt tack till Sree Arasanagatta (programvaruutvecklingschef AWS ML) och Suraj Kota (programvaruutvecklare) för deras stöd till lanseringen av detta inlägg.

Om författarna

Kanwaljit Khurmi är en AI/ML Specialist Solutions Architect på Amazon Web Services. Han arbetar med AWS-produkten, teknik och kunder för att ge vägledning och teknisk assistans som hjälper dem att förbättra värdet av sina hybrid-ML-lösningar när de använder AWS. Kanwaljit är specialiserat på att hjälpa kunder med container- och maskininlärningsapplikationer.

Gautam Kumar är en mjukvaruingenjör med AWS AI Deep Learning. Han har utvecklat AWS Deep Learning Containers och AWS Deep Learning AMI. Han brinner för att bygga verktyg och system för AI. På fritiden tycker han om att cykla och läsa böcker.

Alex Iankoulski är en mjukvaru- och infrastrukturarkitekt i full stack som gillar att göra djupgående, praktiskt arbete. Han är för närvarande en Principal Solutions Architect for Self-managed Machine Learning på AWS. I sin roll fokuserar han på att hjälpa kunder med containerisering och orkestrering av ML- och AI-arbetsbelastningar på containerdrivna AWS-tjänster. Han är också författare till öppen källkod Gör ramverk och en Docker-kapten som älskar att använda containerteknologier för att påskynda innovationstakten och samtidigt lösa världens största utmaningar. Under de senaste 10 åren har Alex arbetat med att bekämpa klimatförändringar, demokratisera AI och ML, göra resor säkrare, hälsovården bättre och energismartare.