Gehoste Jupyter Notebooks en VS Code op Kubernetes

Jupyter notebooks zijn een krachtig en populair hulpmiddel dat een interactieve computeromgeving biedt waarin code, datavisualisatie en toelichtende tekst worden gecombineerd. Dit maakt het eenvoudiger om met data te werken en inzichten te delen.  Data scientists gebruiken Jupyter notebooks voor diverse taken gedurende de gehele levenscyclus van data-analyse en machine learning, zoals exploratieve data-analyse (EDA), datapreprocessing, visualisatie, modelontwikkeling, evaluatie, validatie, etc. Voor veel van deze use cases is het simpelweg installeren van Jupyter Notebook op je laptop voldoende om aan de slag te gaan. Voor veel bedrijven en organisaties is dit echter geen optie en zijn gehoste Jupyter notebooks noodzakelijk.

Waarom hebben we gehoste Jupyter notebooks nodig?

1. Toegang tot resources: Veel Data Science-workloads vereisen zware rekenkracht die niet kan worden geleverd door de lokale machines van DS'en of MLE's. Gehoste Jupyter notebooks kunnen DS'en/MLE's toegang bieden tot krachtige machines en GPU's.
2. Datatoegang en beveiliging: In veel ondernemingen werken DS'en/MLE's aan projecten met gevoelige data die niet naar de laptop van de werknemer mag worden gedownload. Met gehoste Jupyter notebooks kunnen bedrijven DS'en/MLE's veilig toegang verlenen om aan gevoelige projecten te werken.
3. Reproduceerbaarheid en samenwerking: Gehoste Jupyter Notebooks zijn een uitstekende manier om uitvoerbare code en resultaten binnen een team te delen. Omdat de ontwikkelomgeving identiek is, zijn de resultaten 100% reproduceerbaar en kunnen teamleden samenwerken aan projecten.

Hoe kan een bedrijf gehoste Notebooks aanbieden aan zijn data scientists?

Dit zijn de opties die een bedrijf vandaag de dag heeft om zijn engineers toegang te bieden tot Jupyter Notebook:

Een VM provisionen voor elke Data scientist:

DS'en/MLE's kunnen de omgeving instellen en een jupyter-server uitvoeren op een VM die kan worden gebruikt voor het draaien van de workloads. Hier is een eenvoudige handleiding over hoe je jupyterlab kunt uitvoeren op een ec2-instance.

👍 Voordelen:
- Geeft de DS volledige controle over de machine
- De gehele omgeving is persistent. De VM kan worden gestopt en herstart in dezelfde staat.

👎 Nadelen:
- Hoge cloud computing-kosten - Er is geen automatische stopfunctie. Een DS kan een VM starten en deze voor een groot deel van de tijd ongebruikt laten aanstaan, wat de kosten opdrijft.
- Moeilijk om een groot aantal VM's centraal te beheren en te traceren.
- De DS moet veel zaken handmatig instellen om de werkbank voor te bereiden voor het starten van experimenten.
- Problemen met reproduceerbaarheid - De DS heeft mogelijk een reeks packages geïnstalleerd die niet meer worden bijgehouden, waardoor het veel tijd kost om de code die op die VM draait naar productie te brengen.

Een beheerde oplossing gebruiken:

Een andere optie is het gebruiken van een beheerde oplossing zoals AWS Sagemaker, Vertex AI Notebooks of Azure ML Notebooks. Hoewel elk van deze methoden voordelen heeft, zijn hier in het algemeen een paar voor- en nadelen van deze opties.

Laten we bespreken wat elkeen van deze velden betekent:

• Persistent Environments: Dit verwijst naar de persistentie van de Python-omgeving. (Of pip package-installaties en door de gebruiker aangemaakte omgevingen al dan niet behouden blijven bij het herstarten van de Notebook)
• Persistent Root Installations: Wanneer root-toegang aan de gebruiker wordt verleend, of root package-installaties (bijv. apt install pkgs)  al dan niet behouden blijven bij het herstarten van de Notebook.
• Resource Usage Monitor: Of de gebruiker het CPU-/geheugengebruik van de notebook rechtstreeks binnen het notebookscherm kan monitoren.
• Code Server Support: Of de notebook-instance kan worden verbonden met een gehoste VS Code Server.
• SSH into the container: Mogelijkheid om via SSH te verbinden met een actieve notebook vanaf de lokale machine.
• Auto-Stop: Functie om de notebook te stoppen na een "periode van inactiviteit". Vertex biedt deze functie in de "Managed Notebooks"-versie. Sagemaker heeft een manier om notebooks te stoppen na een periode van inactiviteit, maar daarvoor moet een "Init Script" worden geconfigureerd in plaats van een eenvoudige deployment-optie, wat voor enige wrijving zorgt bij de gebruiker.
• Cross-Cloud Support: Deze functie is exclusief voor Truefoundry, aangezien je de notebook kunt uitvoeren op elk van de drie cloudproviders met exact dezelfde gebruikerservaring.
• Customization of Image: Het starten van de notebook met een specifieke set voorgeïnstalleerde packages.
• Mount shared Volume in Notebook: Notebooks van elkeen van de cloudproviders (AWS/Azure/Vertex) bieden de mogelijkheid om een afzonderlijk volume voor elke notebook aan te maken, maar bieden geen manier om een gedeeld volume te mounten. Stel bijvoorbeeld dat een onderneming een dataset van 500 GB heeft die door meerdere Data Scientists voor verschillende use cases wordt gebruikt. Nu moet elke DS deze data dupliceren en betalen voor de kosten van meerdere volumes, zelfs wanneer de notebooks niet draaien. Dit kan potentieel honderden tot duizenden dollars aan cloudkosten opslokken!
  Met Truefoundry kun je een NFS-type volume in read-only modus mounten op meerdere notebooks en daardoor besparen op dataduplicatiekosten!

Gehoste Notebooks op Kubernetes:

Een andere optie is het hosten van notebooks op Kubernetes, maar dit brengt eigen uitdagingen met zich mee omdat data scientists niet rechtstreeks met Kubernetes kunnen interageren en software ertussen nodig hebben die een eenvoudige interface biedt om Jupyter notebooks te starten. Laten we kijken wat de beschikbare opties hierin zijn:

Kubeflow Notebook Operator:
Kubeflow helpt om deployments van machine learning (ML)-workflows op Kubernetes eenvoudig, overdraagbaar en schaalbaar te maken. Het beschikt over een notebook-functie die helpt om notebooks eenvoudig te beheren en uit te voeren.
Hoewel Kubeflow een groot open-sourceproject is dat veel functies biedt voor Machine Learning-use cases, is het erg moeilijk om Kubeflow zelf te installeren en te beheren.

👍 Voordelen:
- Eenvoudig starten en beheren van notebooks voor DS'en
- Permanente home-directory ondersteund door een schijf
- Optie voor vooraf gedefinieerde images voor sklearn, pytorch en tensorflow die worden geleverd met alle geïnstalleerde afhankelijkheden.
- Open-source codebase
- Beschikt over een culling-functie die notebooks stopt na een periode van inactiviteit.

👎 Nadelen:
- Moeilijk om Kubeflow in te stellen op Kubernetes. Het kost veel tijd om Kubeflow te installeren en te onderhouden
- Om notebooks in meerdere regio's aan te bieden, moeten verschillende Kubernetes-clusters worden aangemaakt en moet Kubeflow op elk afzonderlijk cluster worden geïnstalleerd - wat leidt tot hoge infrastructuur- en onderhoudskosten.
- Python-packages zijn standaard niet persistent, wat betekent dat je packages elke keer dat je herstart opnieuw moet installeren
- Geen directe manier om root-toegang te krijgen tot de container [kan nuttig zijn voor meerdere use cases]
- Het stoppen van notebooks kan niet op individueel notebookniveau worden geconfigureerd en is een globale instelling. 

JupyterHub hosten op Kubernetes:
JupyterHub is een geweldige configuratie voor multi-user use cases die helpt bij het optimale gebruik van resources. Het deployen van JupyterHub op Kubernetes kan worden gedaan met een open-sourceproject genaamd Zero to JupyterHub with Kubernetes:

👍 Voordelen:
 - Meerdere gebruikers kunnen eenvoudig samenwerken met ondersteuning voor authenticatie
 - Eenvoudig instellen van auto-stop voor notebooks
 - Eenvoudig beheer van omgevingen

👎 Nadelen:
- Moeilijk in te stellen en te beheren. We moeten Networking, Persistent Volumes, Scaling en Load Balancing configureren om JupyterHub correct te laten werken.
- Moeilijk om GPU-workloads uit te voeren op verschillende typen GPU's op Jupyterhub. Lees bijvoorbeeld dit.
- Omgevingen zijn niet persistent

Hoewel er op dit moment veel oplossingen beschikbaar zijn, heeft elke oplossing zijn eigen beperkingen. Bij Truefoundry hebben we geprobeerd deze kloof te dichten en een notebook-oplossing te bouwen die voldoet aan alle behoeften van een DS en tegelijkertijd de kosten onder controle houdt. In de volgende sectie beschrijven we onze aanpak voor het bouwen van de notebook-oplossing en de uitdagingen die we tegenkwamen bij het maken ervan.

Truefoundry's aanpak voor het bouwen van een Notebook-oplossing

Truefoundry is een developer platform voor ML-teams dat helpt bij het deployen van Models, Services, Jobs en nu ook Notebooks op Kubernetes. Je kunt meer lezen over wat we doen hier.  Onze motivatie voor het bouwen van een notebook-oplossing was simpelweg om experimenteren en ontwikkelen op ons platform mogelijk te maken. Na het bestuderen van alle beschikbare oplossingen, besloten we de pijnpunten en ontbrekende functies in de andere platforms op te lossen, zodat data scientists de beste ervaring kunnen hebben zonder hoge kosten te maken. Een paar dingen die we mogelijk wilden maken zijn:

1. Omgevingen persistent maken
2. De mogelijkheid voor de gebruiker om root-afhankelijkheden dynamisch te installeren en niet beperkt te zijn tot een vastgestelde set afhankelijkheden.
3. Mogelijkheid om op spot-instances te draaien in bepaalde gevallen, aangezien de prijzen daarvan aanzienlijk lager kunnen zijn. De ervaring kan in enkele gevallen minder zijn omdat de VM kan worden teruggevraagd, maar we hebben gemerkt dat dit in de praktijk vrij zeldzaam is en het kostenvoordeel weegt ruimschoots op tegen de incidentele onderbreking.
4. Mogelijkheid om auto-stop te configureren om kosten te besparen.

Bouwen op Kubeflow Notebooks

Kubeflow ondersteunt het uitvoeren van notebooks op Kubernetes. Het biedt out-of-the-box een aantal functies voor notebooks. We wilden echter de problemen aanpakken die we hierboven hebben belicht in Kubeflow Notebooks en een naadloze ervaring bieden aan datascientists en developers.

Daarom mussten we wijzigingen aanbrengen in de notebook controller, deze integreren met de backend van Truefoundry en de notebooks zichtbaar maken in onze UI.

We hebben de notebook controller geïnstalleerd, maar liepen tegen een paar problemen aan, waardoor we wijzigingen moesten aanbrengen in de kubeflow-notebook-controller:

1. Culling (Auto-Stop-functie voor Notebooks) werkt niet met custom endpoints. Kubeflow Notebook Controller vertrouwde op bepaalde endpoint-indelingen om culling te laten werken. Dit beperkt de gebruiker in het definiëren van een endpoint naar keuze.
2. Zelfde Cull-Timeout over het gehele cluster. Dit betekent dat je alleen een "Inactivity Timeout" voor notebooks op clusterniveau kunt instellen. Je kunt geen verschillende cull-timeoutwaarden instellen voor verschillende notebooks.
3. De standaard Python-omgeving is niet persistent

We hebben de bovenstaande twee problemen opgelost en de tfy-notebook-controller gelanceerd
en gepubliceerd als een helm-chart in Truefoundry's Public Charts repository. Je kunt de chart hier vinden.

UI voor het aanmaken, starten en stoppen van notebooks:

We hebben een eenvoudig te begrijpen UI gemaakt voor data scientists om notebooks te starten. De gebruiker kan de Idle Timeout (inactiviteitstijd waarna de notebook wordt gestopt), Persistent Volume Size (grootte van de schijf waarin de dataset en codebestanden worden opgeslagen), Resources (CPU-, geheugen- en GPU-vereisten) aanpassen en de notebook direct starten!

Met al deze wijzigingen hebben we de v0 van onze notebooks gelanceerd.

Maar we zijn nog ver verwijderd van een optimale gebruikerservaring, laten we de voor- en nadelen van deze aanpak bekijken:

👍 Voordelen:
- Permanente home-directory [alle bestanden en packages blijven behouden]
- Inactivity Timeout (Cull Timeout) per notebook kan worden geconfigureerd
- Notebook starten met een paar kliks
- Eenvoudig notebooks starten met GPU's

👎 Beperkingen:
- Python-omgeving is niet persistent (alle geïnstalleerde packages verdwijnen bij het herstarten van de pod)
- Geen manier om packages te installeren die root-toegang vereisen
- Geen goede manier om meerdere omgevingen voor experimenten te beheren
- Kan geen endpoint configureren voor de notebook [toegevoegd in de volgende versie]

Het oplossen van deze beperkingen is cruciaal omdat ze veel workflows van Data Scientists blokkeren, die zo eenvoudig kunnen zijn als het installeren van 'apt-packages' zoals ffmpeg.

Kritieke problemen in de gebruikersworkflow oplossen

Tot dit punt gebruikten we de kant-en-klare images voor Jupyterlab geleverd door Kubeflow. Maar omdat we het probleem van niet-persistente omgevingen moeten oplossen, root-toegang moeten toestaan en apt-packages moeten installeren, hebben we onze eigen set docker-images nodig.
Laten we dus kijken hoe we deze problemen hebben opgelost!

• Niet-persistente omgevingen: Het doel was om de basis-Python-omgeving persistent te maken, zodat gebruikers eenvoudig notebooks kunnen gebruiken voor hun use cases.

- Het init-script van het docker-image aangepast en de conda-basisomgeving gekloond naar de home-directory met de naam jupyter-base
- Een .condarc-bestand toegevoegd en de directory $HOME ingesteld als het standaard omgevingspad
- Het .bashrc-bestand aangepast om de omgeving jupyter-base standaard te activeren

• Apt-packages installeren
  De gebruiker heeft de optie om een lijst met apt-packages op te geven die ze vooraf geïnstalleerd willen hebben in het image.
  We voegen dan een build-fase toe en maken een custom image aan waarin alle opgegeven packages vooraf zijn geïnstalleerd in de notebook!

• Root-toegang bieden
  In veel gevallen heeft de gebruiker root-toegang nodig om enkele packages te installeren en snel wat dingen uit te proberen. Hiervoor hebben we twee images gemaakt voor elk imagetype.
  truefoundrycloud/jupyter:latest en truefoundrycloud/jupyter:latest-sudo. Waarbij de images met sudo de gebruiker sudo-toegang zonder wachtwoord bieden.
  Dit is gedaan door het sudo-binary te installeren en de gebruiker toe te voegen aan de sudoers-lijst zoals beschreven in deze link.

Opmerking: Omdat we notebooks uitvoeren op kubernetes met de home-directory gemount, blijft alleen de home-directory persistent. De root package-installaties blijven niet behouden bij het herstarten van de pod. Lees dit voor een beter begrip hiervan.

Door deze problemen op te lossen, hebben we de meeste obstakels voor de gebruiker weggenomen en bieden we een degelijke notebook-ervaring. Na verloop van tijd zagen we echter dat gebruikers tegen enkele nieuwe uitdagingen aanliepen, die we in de volgende sectie zullen beschrijven.

Bruikbaarheidsproblemen in notebooks

• Moeilijk om het resourcegebruik (CPU en geheugen voor een notebook) te monitoren: De Kernel crasht heel vaak vanwege Out Of Memory-problemen. We komen vaak scenario's tegen waarin we een notebook uitvoeren en de kernel om de een of andere reden crasht, wat lastig kan zijn om te debuggen.

• Wijziging van de Python-omgeving kan soms leiden tot een beschadigde status waarin de notebookserver niet meer wil herstarten. Dit kan door meerdere oorzaken komen, zoals iemand die het package jupyterlab deïnstalleert. Omdat de omgeving persistent is, start de notebook niet meer op (zodra de huidige notebook is gestopt)
• Het beheren van meerdere omgevingen is mogelijk. De gebruiker moet de conda-omgeving echter handmatig toevoegen aan kernelspec en ervoor zorgen dat kernelspec correct is geconfigureerd, wat problemen kan veroorzaken.

De bruikbaarheidsproblemen oplossen

Resourcegebruik-statistieken toevoegen aan de notebook:
We hebben statistieken voor resourcegebruik aan de notebook toegevoegd door de extensie jupyterlab-system-monitor==0.8.0 te installeren en de instellingen te configureren in het init-script door argumenten mee te geven bij het starten van de Jupyterlab-server.

...


jupyter lab \
   ...
   --ResourceUseDisplay.mem_limit=${mem_limit} \
   --ResourceUseDisplay.cpu_limit=${cpu_limit} \
   --ResourceUseDisplay.track_cpu_percent=True \
   --ResourceUseDisplay.mem_warning_threshold=0.8


Zo ziet het eruit in de UI:

De kernel die de Jupyterlab-server uitvoert scheiden van de uitvoeringskernel

We moeten ervoor zorgen dat welke wijzigingen de gebruiker ook aanbrengt in de home-directory, de notebook altijd zonder problemen herstart. Hiervoor hebben we de 'base' anaconda-omgeving uit de directory /opt/conda gebruikt om de Jupyterlab-server te starten.
Daarnaast hebben we een afzonderlijke omgeving aangemaakt in de directory $HOME, maar dit voegt een kernel van de conda-omgeving base toe aan de Kernels-lijst.

Om dit op te lossen hebben we nb_conda_kernels geïnstalleerd om Jupyter-kernels te beheren. We hebben het init-script zo geconfigureerd dat alleen de permanente Python-omgevingen in de kernellijst verschijnen.

jupyter lab \
   ...
   --CondaKernelSpecManager.conda_only=True \
   --CondaKernelSpecManager.name_format={environment} \
   --CondaKernelSpecManager.env_filter=/opt/conda/*"


Hiermee krijgen we de garantie dat de notebookserver altijd zal starten, ongeacht de wijzigingen die een gebruiker binnen de notebook aanbrengt.
Het vereenvoudigt ook het beheer van meerdere kernels. Je hoeft enkel een nieuwe conda-omgeving aan te maken met het commando conda create -n myenv en deze verschijnt direct in de kernellijst.

Code-Server-ondersteuning toevoegen

Hoewel Jupyter notebooks een groot aantal problemen oplossen, zijn er diverse taken waarbij ze niet toereikend zijn:

1. Ontwikkeling van een service zoals een eenvoudige Gradio- of Streamlit-app. Gebruikers kunnen de code schrijven en uitvoeren in Jupyter Notebook, maar kunnen de service niet bekijken in de browser.
2. Als een gebruiker werkt aan een project waarvan de code is opgedeeld in meerdere bestanden, is de Jupyterlab-omgeving niet geschikt voor deze manier van ontwikkelen.

Gezien deze beperkingen hebben we besloten hier een oplossing voor te bouwen. We hebben code-server-ondersteuning toegevoegd om gebruikers een volledige IDE-ervaring te bieden in de browser.

Door het toevoegen van VS Code-ondersteuning stellen we gebruikers in staat om het volgende te doen:

1. Services ontwikkelen en testen rechtstreeks in je browser met de port-forwarding proxy van VS Code. Dit betekent dat je deployed services localhost:8000 beschikbaar kunnen worden gemaakt op ${NOTEBOOK_URL}/proxy/8000
2. Eenvoudig code beheren met overzichtelijke packages, aangezien dit een volledige IDE-ervaring biedt.
3. Gebruikmaken van alle bekende VS Code-extensies om de productiviteit te verhogen.
4. Eenvoudig applicaties debuggen door ze uit te voeren in debug-modus en breakpoints toe te passen.

Dit is gerealiseerd door het toevoegen van nog een docker-image. Hier is een diagram dat de docker-images van Truefoundry toont.

SSH-toegang tot je Notebook/VSCode:

Hoewel Gehoste VS Code in de meeste gevallen het probleem kan oplossen, kunnen er situaties zijn (vooral bij Jupyter Notebooks) waarin de gebruiker vastloopt en directe toegang nodig heeft tot de container waarin de Jupyter Notebook / VS Code Server draait.
We hebben dat vereenvoudigd door een ssh-server te installeren in elk van de notebooks. Om verbinding te maken met je container hoef je alleen een eenvoudig commando uit te voeren en je wachtwoord in te voeren:

ssh -p 2222 jovyan@test-notebook.ctl.truefoundry.tech


De kracht van deze tool kan worden uitgebreid met de VS Code-extensie genaamd Remote Explorer, waarmee je direct alle bestanden in je VS Code kunt openen!
Klik hier om er meer over te lezen

De uiteindelijke gebruikerservaring:

Met alle functies gebundeld in onze notebook-oplossing, ziet ons notebook deployment formulier er als volgt uit:

Prijsvergelijking

Laten we tot slot de prijzen van elk van de beheerde oplossingen vergelijken met Truefoundry.

Aangezien Truefoundry werkt door te deployen op de cloud van de klant door hun Kubernetes-cluster te verbinden, is hier de prijsstelling voor Truefoundry draaiend op verschillende cloudproviders.

In het geval van Truefoundry kun je daadwerkelijk aanzienlijk op kosten besparen omdat:

• Wij geen extra opslagkosten rekenen bovenop de kosten van de Virtual Machines
• Wij het uitvoeren van notebooks op spot-instances ondersteunen voor niet-productie workloads, wat een extra besparing van 50-60% op cloudkosten oplevert.

Conclusie

Dit was een kort overzicht van onze inspanningen bij het bouwen van de notebook-oplossing. Je kunt lid worden van ons Friends of Truefoundry Slack-kanaal als je onze aanpak diepgaander wilt bespreken of als je suggesties hebt.

Als je ons platform wilt uitproberen, kun je je hier registreren!