Deploy Ray using Helm

Om onze rekenbehoeften te verdelen en zware taken uit te voeren, zoals het synthetiseren van je gegevens, moeten we een Ray cluster implementeren met Helm voor onze API om verbinding mee te maken. De grafiek kan worden gevonden in de repository hier of kan worden geleverd door een repo URL om direct te worden gebruikt in Helm. Neem contact op met het Syntho-team voor deze repo-URL.

Dit deel van de documentatie gaat uit van toegang tot de map helm/ray in de master branch van de eerder genoemde GitHub repository.

Een opmerking voor OpenShift gebruikers: Ray vereist dat we veel threads aanmaken binnen een pod, vooral bij het schalen van het Ray cluster. Standaard beperkt OpenShift het aantal processen dat een pod kan spawnen, vanwege het gebruik van CRI-O als Container Runtime Interface (CRI). We raden aan om deze limiet aan te passen: zie de sectie #additional-changes-for-openshift-cri-o

De afbeelding instellen

Stel in het values.yaml bestand in helm/ray de volgende velden in om het gebruik van het juiste Docker image te garanderen:

operatorImage:
  repository: syntho.azurecr.io/syntho-ray-operator
  tag: <tag>
  pullPolicy: IfNotPresent

image:
  archief: syntho.azurecr.io/syntho-ray
  tag: <tag>
  pullPolicy: IfNotPresent

De image tag wordt geleverd door het Syntho Team. In sommige gevallen kan de laatste tag worden gebruikt, maar we raden aan een specifieke tag in te stellen.

Naast het instellen van de juiste Docker image, definieer je de Kubernetes Secret die is aangemaakt onder imagePullSecrets:

imagePullSecrets:
    - naam: syntho-cr-secret

Deze waarde is standaard ingesteld op syntho-cr-secret.

Licentiesleutel - Ray

De licentiesleutel kan worden ingesteld onder SynthoLicense in het values.yaml bestand. Een voorbeeld hiervan zou zijn:

SynthoLicentie: <syntho-licentie-sleutel>

Gebruik de licentiesleutel van Syntho.

Clusternaam

De standaardclusternaam is ingesteld op ray-cluster. Als dit aangepast moet worden, kunt u dit doen door clusternaam te veranderen:

clusternaam: ray-cluster

Werkers en knooppunten

Allereerst zal het Syntho Team een aantal aanbevelingen hebben over wat de exacte grootte van het cluster zou moeten zijn gegeven uw gegevensvereisten. Als u hierover geen informatie hebt ontvangen, neem dan eerst contact op met het Syntho team om de optimale opstelling te bespreken. De rest van deze sectie geeft een voorbeeldconfiguratie om te laten zien hoe dat eruit ziet in de Helm grafiek.

Afhankelijk van de grootte en het aantal nodes van het cluster, pas je het aantal workers aan dat Ray beschikbaar heeft voor taken. Ray heeft ten minste één hoofdinstantie nodig. Om de prestaties te verhogen, kunnen we ook extra werkgroepen aanmaken. Onder head kunnen we de resources voor het hoofdknooppunt instellen. Dit hoofdknooppunt zal voornamelijk gebruikt worden voor administratieve taken in Ray en de werkerknooppunten zullen de meeste taken voor de Syntho Applicatie oppakken.

Voor een productieomgeving raden we een pool van workers naast de head node aan. Het Syntho Team kan aangeven welke resources moeten worden toegewezen aan de head node en worker nodes. Hier is een voorbeeldconfiguratie van een cluster met een head node en een node pool, van 1 machine, met 16 CPU's en 64GB RAM:

hoofd:
  rayStartParams:
    dashboard-host: '0.0.0.0'
    blok: 'true
  containerEnv:
  - naam: RAY_SCHEDULER_SPREAD_THRESHOLD
    waarde: "0.0"
  envFrom: []
  middelen:
    limieten:
      cpu: "16"
      geheugen: "64G"
    verzoeken:
      cpu: "16
      geheugen: "64G"
  annotaties: {}
  nodeSelector: {}
  toleranties: []
  affiniteit: {}
  securityContext: {}
  poorten:
  - containerPort: 6379
    naam: gcs
  - containerPort: 8265
    naam: dashboard
  - containerPort: 10001
    naam: client
  volumes:
    - naam: log-volume
      emptyDir: {}
  volumeMounts:
    - mountPath: /tmp/ray
      naam: log-volume
  sidecarContainers: []


worker:
  # Als je de standaard workergroup wilt uitschakelen
  # verwijder het commentaar van de regel hieronder
  # uitgeschakeld: waar
  groupName: workergroup
  replicas: 1
  labels: {}
  rayStartParams:
    block: 'true'
  initContainerImage: busybox:1.28
  initContainerSecurityContext: {}
  containerEnv:
   - naam: STRAAL_SCHEDULER_SPREIDING_DREMPEL
     waarde: "0.0"
  envFrom: []
  middelen:
    limieten:
      cpu: "16"
      geheugen: "64G"
    verzoeken:
      cpu: "16
      geheugen: "64G"
  annotaties: {}
  nodeSelector: {}
  toleranties: []
  affiniteit: {}
  securityContext: {}
  volumes:
    - naam: log-volume
      emptyDir: {}
  volumeMounts:
    - mountPath: /tmp/ray
      naam: log-volume
  sidecarContainers: []

Als autoscaling is ingeschakeld in Kubernetes, worden nieuwe nodes aangemaakt zodra de Ray-vereisten hoger zijn dan de beschikbare bronnen. Bespreek samen met het Syntho Team welke situatie het beste past bij uw gegevensvereisten.

Voor ontwikkel- of experimentele omgevingen is meestal een minder geavanceerde setup nodig. In dit geval raden we aan om te beginnen met het opzetten van alleen een head node type en geen workers of extra autoscaling setup. Het Syntho Team zal opnieuw advies geven over de grootte van deze node, gezien de gegevensvereisten. Een voorbeeldconfiguratie met een node met 16 CPU's en 64 GB RAM zou zijn:

hoofd:
  rayStartParams:
    dashboard-host: '0.0.0.0'
    blok: 'true
  containerEnv:
  - naam: RAY_SCHEDULER_SPREAD_THRESHOLD
    waarde: "0.0"
  envFrom: []
  middelen:
    limieten:
      cpu: "16"
      # Om out-of-memory problemen te voorkomen, wijs nooit minder dan 2G geheugen toe voor de Ray kop.
      geheugen: "64G" # Afhankelijk van de gegevensvereisten
    verzoeken:
      cpu: "16"
      geheugen: "64G" # Afhankelijk van de gegevensvereisten
  annotaties: {}
  nodeSelector: {}
  toleranties: []
  affiniteit: {}
  securityContext: {}
  poorten:
  - containerPort: 6379
    naam: gcs
  - containerPort: 8265
    naam: dashboard
  - containerPort: 10001
    naam: client
  volumes:
    - naam: log-volume
      emptyDir: {}
  volumeMounts:
    - mountPath: /tmp/ray
      naam: log-volume
  sidecarContainers: []

worker:
  # Als je de standaardwerkgroep wilt uitschakelen
  # de onderstaande regel verwijderen
  uitgeschakeld: waar

# De sleutel van de map wordt gebruikt als de groepsnaam.
# Bijvoorbeeld, sleutel:kleine-groep in de onderstaande map
# wordt gebruikt als de groepsnaam
extraWerkergroepen:
  smallGroup:
    # Standaard uitgeschakeld
    uitgeschakeld: onwaar

Daarnaast kunnen nodeSelector, tolerations en affinity worden gedefinieerd voor elk type node, om enige controle te hebben over waar de pods/nodes precies worden toegewezen. securityContext en annotiations kunnen ook worden ingesteld voor elk type worker/hoofdknooppunt.

Gedeelde opslag van Ray werkers

We hebben een extra Persistent Volume nodig voor de Ray workers om wat metadata te delen over de huidige taken die worden uitgevoerd. Dit is opgenomen in de Helm grafiek en heeft het Persistent Volume type ReadWriteMany. In de sectie storage kun je de storageClassName aanpassen om hiervoor te gebruiken. Zorg ervoor dat je een storageClass gebruikt die het type ReadWriteMany ondersteunt.

opslag:
  storageClassName: default # Verander naar de juiste storageClass

Volume koppelt

Optioneel

Als bepaalde volumes moeten worden gemount, kunnen de waarden volumes en volumeMounts worden aangepast om deze te definiëren. Houd er bij het gebruik van PV rekening mee dat Ray meerdere pods kan plannen die dat specifieke volume gebruiken, dus het moet toegankelijk zijn vanaf meerdere machines.

Extra wijzigingen voor OpenShift/CRI-O

Bepaalde orkestrators of opstellingen gebruiken CRI-O als de container runtime interface (CRI). Openshift 4.x heeft CRI-O momenteel standaard een limiet van 1024 processen. Bij het schalen kan deze limiet gemakkelijk worden bereikt met Ray. We raden aan om deze limiet in te stellen op ongeveer 8096 processen.

De Openshift documentatie beschrijft de stappen om deze limiet te verhogen hier. De volgende link heeft meer informatie over de instellingen die gebruikt kunnen worden in CRI-O.

Implementeren

Zodra de waarden correct zijn ingesteld in values.yaml onder helm/ray, kunnen we de applicatie deployen naar het cluster met het volgende commando:

helm install ray-cluster ./helm/ray --values values.yaml --namespace syntho

Eenmaal uitgerold kunnen we de servicenaam in Kubernetes vinden voor de Ray-applicatie. In het geval dat we de naam ray-cluster gebruiken, zoals in het bovenstaande commando, is de servicenaam (en hostnaam om te gebruiken in de variabele ray_address voor de Core API waardensectie) ray-cluster-ray-head.

Ten slotte kunnen we de ray-operator pod en de daaropvolgende Ray head of Ray worker pods controleren. Door kubectl logs deployment/ray-operator -n syntho uit te voeren, krijgen we de logs van de operator te zien.