Configurer GKE ou Kubernetes autogéré

Vous pouvez configurer la plate-forme ML Diagnostics pour les charges de travail de ML exécutées sur Google Kubernetes Engine (GKE) ou sur Kubernetes autogéré.

ML Diagnostics inclut les fonctionnalités suivantes en disponibilité générale :

  • Surveillance automatique des charges de travail et collecte des métriques système : pour la surveillance automatique des charges de travail et la collecte des métriques système sur GKE, vous n'avez pas besoin d'instrumenter votre code ni d'effectuer de configuration supplémentaire. La surveillance des charges de travail et la collecte des métriques système sont activées par défaut. Vous n'avez pas besoin de suivre les étapes de ce guide. La surveillance des charges de travail est compatible avec les types de jobs GKE JobSet et Job, ainsi qu'avec les versions 1.36.4-gke.1247000 et ultérieures de GKE.
  • Métriques et profilage programmatique du SDK ML Diagnostics : si vous souhaitez utiliser le SDK ML Diagnostics pour collecter des métriques et exécuter un profilage programmatique, installez le chart Helm injection-webhook, étiquetez la charge de travail et utilisez le SDK ML Diagnostics. Sur GKE, vous pouvez utiliser une seule commande Google Cloud CLI si vous utilisez une version de GKE compatible, ou effectuer une installation manuelle. Sur Kubernetes autogéré, vous devez installer le webhook manuellement.
  • Profilage à la demande : si vous souhaitez utiliser le profilage à la demande, installez le chart Helm connection-operator. Sur GKE, vous pouvez utiliser une seule commande gcloud CLI si vous utilisez une version de GKE compatible, ou effectuer une installation manuelle. Sur Kubernetes autogéré, vous devez installer l'opérateur manuellement.

ML Diagnostics inclut également la fonctionnalité en preview suivante :

  • Profilage du DaemonSet Diagon : si vous souhaitez utiliser le profilage à la demande, le profilage continu et la capture automatique de profils à partir de la surveillance des charges de travail sur votre charge de travail GKE, déployez le DaemonSet Diagon sur vos clusters GKE TPU. Ce DaemonSet fonctionne également sur les clusters Kubernetes autogérés, où seuls le profilage à la demande et le profilage continu sont compatibles. La surveillance des charges de travail n'est pas compatible avec Kubernetes autogéré.

Déployer le DaemonSet Diagon

Si vous exécutez des charges de travail conteneurisées sur GKE ou des clusters Kubernetes autogérés, vous pouvez déployer le daemon Diagon en tant que DaemonSet. Cela garantit qu'une copie du daemon s'exécute sur tous les nœuds GPU et TPU du cluster, ou sur ceux sélectionnés.

Dépôt d'images de conteneurs

Le daemon Diagon est publié en tant qu'image Docker et est disponible à partir du chemin d'accès Artifact Registry suivant :

us-central1-docker.pkg.dev/hypercomputediagon-release/daemon-docker/mldiagnostics-daemon:latest

Procédure de déploiement

Pour déployer le DaemonSet Diagon sur votre cluster, procédez comme suit :

  1. Créez la configuration DaemonSet : enregistrez la configuration YAML suivante sous le nom diagon-daemonset.yaml. Cette configuration exécute le daemon Diagon en mode privilégié afin qu'il puisse collecter des métriques de diagnostic et de profilage à partir des appareils GPU et TPU hôtes sous-jacents.

    # diagon-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: diagon-daemon
  namespace: diagon
  labels:
    app.kubernetes.io/name: diagon-daemon
    app.kubernetes.io/part-of: diagon
spec:
  selector:
    matchLabels:
      name: diagon-daemon
  template:
    metadata:
      labels:
        name: diagon-daemon
    spec:
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      serviceAccountName: SERVICE_ACCOUNT_NAME
      terminationGracePeriodSeconds: 30
      tolerations:
      - operator: Exists
        effect: NoSchedule
      - operator: Exists
        effect: NoExecute
      containers:
      - name: diagon-daemon
        image: us-central1-docker.pkg.dev/hypercomputediagon-release/daemon-docker/mldiagnostics-daemon:latest
        imagePullPolicy: Always
        command:
        - /mldiagnostics_extension_files/bin/mldiagnostics_extension
        - -standalone=true
        - -channel=hypercomputecluster.googleapis.com/diagnostics
        - -alsologtostderr=true
        securityContext:
          privileged: true
        resources:
          requests:
            cpu: 10m
            memory: 32Mi
          limits:
            memory: 256Mi  # No CPU limit.

  2. Déployez le DaemonSet sur le cluster : exécutez la commande suivante pour déployer le daemon sur votre contexte Kubernetes actif.

    kubectl apply -f diagon-daemonset.yaml

  3. Vérifiez l'état du déploiement et du daemon : sur votre poste de travail d'administrateur ou dans Cloud Shell, vérifiez que tous les pods de daemon sont planifiés sur les nœuds de calcul et ont atteint l'état Running :

    kubectl get pods -n diagon -l name=diagon-daemon -o wide

    Inspectez les journaux de streaming pour confirmer la connectivité au plan de contrôle des diagnostics de ML Google Cloud et les pulsations actives :

    kubectl logs -n diagon -l name=diagon-daemon --tail=50

    Le résultat inclut les signatures de journaux attendues suivantes :

    Stream established.
Received successful DaemonRegistrationResponse from backend
Sending DaemonHeartbeatRequest

  4. Mettre à jour l'image DaemonSet : pour passer à une version plus récente du daemon ou effectuer un rollback, mettez à jour le tag d'image dans votre fichier YAML ou exécutez directement la commande suivante.

    kubectl set image daemonset/diagon-daemon diagon-daemon=us-docker.pkg.dev/hypercomputediagon-release/daemon/diagon-daemon:v2.1.0 --namespace=kube-system

    Pour vérifier la progression du déploiement ou de la mise à jour, vérifiez l'état du déploiement :

    kubectl rollout status daemonset/diagon-daemon --namespace=kube-system

Configurer l'opérateur et le webhook

Pour configurer l'opérateur et le webhook, vous disposez des options suivantes :

  • Si vous utilisez une version de GKE ultérieure à la version 1.35.0-gke.3065000, vous pouvez configurer votre cluster GKE pour ML Diagnostics à l'aide d'une seule commande gcloud CLI, via la console Google Cloud ou à l'aide de Terraform.

  • Pour les versions de GKE antérieures à 1.35.0-gke.3065000 et Kubernetes autogéré, vous devez configurer manuellement le cluster pour installer les artefacts cert-manager, injection-webhook et connection-operator. Pour en savoir plus, consultez Installation manuelle.

Déployez l'opérateur et le webhook sur votre cluster GKE, ainsi que le DaemonSet Diagon. Si vous avez déjà déployé l'opérateur et le webhook, vous n'avez pas besoin de les supprimer. Au lieu de cela, l'opérateur sert de chemin de remplacement pour la capture de profils à la demande, et le webhook est toujours requis pour utiliser le SDK.

Si vous utilisez un environnement Kubernetes autogéré au lieu de GKE, installez le webhook pour le SDK et déployez le DaemonSet Diagon. Dans un environnement Kubernetes autogéré, la surveillance des charges de travail ne fonctionne pas. Seules les métriques du SDK, le profilage programmatique, le profilage à la demande et le profilage continu sont compatibles.

Pour les versions de GKE ultérieures à 1.35.0-gke.3065000, utilisez l'une des méthodes suivantes pour déployer les composants ML Diagnostics requis (connection-operator et injection-webhook) dans votre cluster GKE.

gcloud

Pour les nouveaux clusters GKE :

gcloud beta container clusters create CLUSTER_NAME --enable-managed-mldiagnostics

Pour les clusters GKE existants :

gcloud beta container clusters update CLUSTER_NAME --enable-managed-mldiagnostics

Pour désactiver ML Diagnostics, utilisez la commande suivante :

gcloud beta container clusters update CLUSTER_NAME --no-enable-managed-mldiagnostics

Pour en savoir plus sur les commandes gcloud CLI permettant de configurer un cluster GKE pour ML Diagnostics, consultez l'option enable-managed-mldiagnostics sur les pages de documentation de référence de l'API suivantes :

Console

  • Pour les nouveaux clusters GKE, accédez à Gestionnaire de fonctionnalités > Diagnostic de machine learning géré.

    Accéder à Diagnostics de machine learning gérés par GKE

  • Pour les clusters GKE existants, accédez à Clusters, sélectionnez le nom de votre cluster, accédez à Modifier, puis modifiez Diagnostics de machine learning gérés sous Fonctionnalités.

Terraform

Si vous utilisez Terraform pour provisionner votre infrastructure GKE, vous pouvez utiliser le fournisseur terraform-provider-google-beta (version v7.28.0 ou ultérieure) ou le module terraform-google-modules/kubernetes-engine/google (version v45.0.0 ou ultérieure).

Utiliser le fournisseur Terraform Google Cloud

Pour activer les diagnostics de ML gérés sur un nouveau cluster à l'aide de la ressource google_container_cluster, ajoutez le bloc managed_machine_learning_diagnostics_config avec enabled = true à l'aide du fournisseur google-beta (version v7.28.0 ou ultérieure) :

terraform {
  required_providers {
    google-beta = {
      source  = "hashicorp/google-beta"
      version = ">= 7.28.0"
    }
  }
}

resource "google_container_cluster" "primary" {
  provider = google-beta
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  # ... other cluster configuration ...

  managed_machine_learning_diagnostics_config {
    enabled = true
  }
}

Pour désactiver Managed ML Diagnostics sur un cluster à l'aide de la ressource Terraform, définissez enabled = false dans le bloc managed_machine_learning_diagnostics_config :

resource "google_container_cluster" "primary" {
  provider = google-beta
  name     = "CLUSTER_NAME"
  location = "LOCATION"

  # ... other cluster configuration ...

  managed_machine_learning_diagnostics_config {
    enabled = false
  }
}

Utiliser le module Terraform GKE

Pour activer Managed ML Diagnostics sur un cluster à l'aide du module terraform-google-modules/kubernetes-engine/google (tel que le sous-module beta-public-cluster), définissez enable_managed_machine_learning_diagnostics = true :

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google//modules/beta-public-cluster"
  version = ">= 45.0"

  project_id = "PROJECT_ID"
  name       = "CLUSTER_NAME"
  region     = "LOCATION"

  # ... other cluster configuration ...

  enable_managed_machine_learning_diagnostics = true
}

Pour désactiver Managed ML Diagnostics sur un cluster à l'aide du module Terraform, définissez enable_managed_machine_learning_diagnostics = false :

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google//modules/beta-public-cluster"
  version = ">= 45.0"

  # ... other cluster configuration ...

  enable_managed_machine_learning_diagnostics = false
}

Après avoir mis à jour votre configuration, appliquez les modifications :

terraform apply

Pour en savoir plus sur l'utilisation de Terraform avec GKE, consultez Compatibilité de Terraform avec GKE.

Installation manuelle

Pour les versions de GKE antérieures à 1.35.0-gke.3065000, vous devez configurer manuellement le cluster GKE pour installer les éléments suivants :

  • cert-manager : condition préalable pour injection-webhook.
  • injection-webhook : fournit au SDK les métadonnées requises. Il est compatible avec les charges de travail de ML Kubernetes courantes, telles que JobSet, RayJob et LeaderWorkerSet.
  • connection-operator : pour le profilage à la demande sur GKE. Le déploiement de connection-operator avec injection-webhook dans le cluster GKE initialise les requêtes de profilage vers les pods cibles avec des serveurs de profilage en cours d'exécution lorsque vous déclenchez la capture à la demande.

Pour en savoir plus sur la configuration d'un cluster GKE, consultez Configurer un cluster GKE.

Cert-manager

Le module complémentaire cert-manager agit en tant que contrôleur de certificats pour votre cluster, ce qui garantit la sécurité de vos applications et empêche l'expiration involontaire de vos certificats.

Utilisez Helm pour installer les éléments suivants :

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.13.0 \
  --set installCRDs=true \
  --set global.leaderElection.namespace=cert-manager \
  --timeout 10m

Injection-webhook

Le chart Helm injection-webhook transmet les métadonnées au SDK. Utilisez helm upgrade --install pour installer pour la première fois ou mettre à niveau une installation existante.

helm upgrade --install mldiagnostics-injection-webhook \
  --namespace=gke-mldiagnostics \
  --create-namespace \
  --version 0.25.0 \
  oci://us-docker.pkg.dev/ai-on-gke/mldiagnostics-webhook-and-operator-helm/mldiagnostics-injection-webhook

Opérateur de connexion

Le chart Helm connection-operator permet d'activer le profilage à la demande sur GKE. Utilisez le tableau suivant pour trouver la version mldiagnostics-connection-operator appropriée :

Version JAX Version du chart Helm
0.8.x 0.24.0
0.9.x+ 0.24.0+

Utilisez Helm pour installer la version requise.

Pour JAX 0.8.x :

helm upgrade --install mldiagnostics-connection-operator \
  --namespace=gke-mldiagnostics \
  --create-namespace \
  --version 0.24.0 \
  oci://us-docker.pkg.dev/ai-on-gke/mldiagnostics-webhook-and-operator-helm/mldiagnostics-connection-operator \
  --set 'mldiagnosticsConnectionOperator.controller.args={--metrics-bind-address=:8443,--health-probe-bind-address=:8081,--sidecar-timeout=65m,--disable-hostname-override}'

Pour JAX 0.9.x ou version ultérieure :

helm upgrade --install mldiagnostics-connection-operator \
  --namespace=gke-mldiagnostics \
  --create-namespace \
  --version 0.24.0 \
  oci://us-docker.pkg.dev/ai-on-gke/mldiagnostics-webhook-and-operator-helm/mldiagnostics-connection-operator

Ajouter un libellé à une charge de travail

Pour le profilage automatisé, vous devez déclencher le injection-webhook pour injecter des métadonnées dans les pods. Ajoutez le libellé managed-mldiagnostics-gke=true à la charge de travail ou à son espace de noms avant de déployer la charge de travail :

  • Ajouter un libellé à une charge de travail : ajoutez un libellé à une charge de travail JobSet, LeaderWorkerSet ou RayJob, ce qui active le webhook pour cette charge de travail spécifique. Voici un exemple pour une charge de travail JobSet :

    apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: single-host-tpu-v3-jobset2
  namespace: default
  labels:
    managed-mldiagnostics-gke: "true"

  • Ajouter un libellé à un espace de noms : cette option active le webhook pour toutes les charges de travail JobSet, LeaderWorkerSet et RayJob de cet espace de noms.

    kubectl create namespace ai-workloads
kubectl label namespace ai-workloads managed-mldiagnostics-gke=true