Bonnes pratiques pour l'exécution de charges de travail par lot sur GKE

Cette page présente les bonnes pratiques à suivre pour créer des plates-formes de traitement par lot avec Google Kubernetes Engine (GKE). GKE fournit un framework puissant pour orchestrer des charges de travail par lot telles que le traitement de données, l'entraînement de modèles de machine learning, l'exécution de simulations scientifiques, et autres charges de travail de calcul hautes performances.

Ces bonnes pratiques sont destinées aux administrateurs de plate-forme, aux architectes cloud et aux professionnels des opérations qui souhaitent déployer des charges de travail par lot dans GKE.

Fonctionnement des charges de travail par lot

Une charge de travail par lot est un groupe de tâches qui s'exécutent sans intervention de l'utilisateur. Pour définir des tâches, vous devez utiliser la ressource Jobs Kubernetes. Une plate-forme de traitement par lot reçoit les Jobs et les met en file d'attente dans l'ordre dans lequel ils sont reçus. La file d'attente sur la plate-forme de traitement par lot applique une logique de traitement telle que la priorité, le quota et les ressources pouvant être allouées. En mettant en file d'attente et en personnalisant les paramètres de traitement par lot, Kubernetes vous permet d'optimiser l'utilisation des ressources disponibles, de minimiser le temps d'inactivité des jobs planifiés et de maximiser les économies. Le schéma suivant montre les composants GKE pouvant faire partie d'une plate-forme de traitement par lot.

Gestion de plate-forme de traitement par lots

Traditionnellement, les plates-formes de traitement par lot ont deux principaux personas utilisateur, les développeurs et les administrateurs de plate-forme:

  • Un développeur soumet un Job spécifiant le programme, les données à traiter et les conditions requises pour le Job. Le développeur reçoit ensuite la confirmation de l'envoi du Job et un identifiant unique. Une fois le Job terminé, le développeur reçoit une notification, ainsi que toutes les sorties ou tous les résultats du Job.
  • Un administrateur de plate-forme gère et fournit aux développeurs une plate-forme de traitement par lot efficace et fiable.

Une plate-forme de traitement par lot doit répondre aux exigences suivantes:

  • Les ressources de la plate-forme sont correctement provisionnées pour garantir que les Jobs s'exécutent avec peu ou pas d'intervention de l'utilisateur.
  • Les ressources de la plate-forme sont configurées conformément aux bonnes pratiques de l'organisation concernant la sécurité et l'observabilité.
  • Les ressources de la plate-forme sont utilisées aussi efficacement que possible. En cas de conflit de ressources, le travail le plus important est effectué en premier.

Préparer l'architecture de plate-forme de traitement par lot dans GKE

Un environnement GKE est constitué de nœuds, qui sont des machines virtuelles (VM) Compute Engine, regroupées pour former un cluster.

Ce tableau présente les principales recommandations lors de la planification et de la conception de votre architecture de plate-forme par lot:

Recommandation Ressources
Sélectionner un mode de fonctionnement GKE

Les modes de fonctionnement suivants sont disponibles dans GKE:

  • En mode Autopilot, GKE gère automatiquement la configuration de votre cluster, y compris vos nœuds, votre scaling, votre sécurité et d'autres paramètres préconfigurés, ce qui vous permet de vous concentrer sur votre charge de travail. Les clusters Autopilot sont hautement disponibles par défaut.
  • En mode standard, vous définissez et gérez la configuration de votre cluster, y compris vos nœuds, le scaling, la sécurité et d'autres paramètres avancés.

Consultez la comparaison de haut niveau entre les modes Autopilot et Standard.
Choisir le type de machine pour vos nœuds

GKE est compatible avec les séries de VM Compute Engine suivantes:

  • Coûts optimisés, tels que E2
  • Équilibré, tel que N2, N2D ou N1
  • Optimisé pour le scaling horizontal, comme Tau T2D ou Tau T2A
  • Mémoire optimisée, telle que M2 ou M1
  • Optimisé pour le calcul, tel que C2 ou C2D
  • Optimisé pour les accélérateurs, par exemple A2 avec des GPU NVIDIA A100, G2 avec des GPU NVIDIA L4 et A3 avec des GPU NVIDIA H100 (disponible en version Preview privée).

Chaque série de machines est associée à une ou plusieurs plates-formes de processeur, telles que les processeurs Arm et les processeurs x86 Intel et AMD.

Découvrez les options actuellement disponibles pour votre charge de travail.
Utiliser des accélérateurs matériels pour vos nœuds

Vous pouvez également utiliser des accélérateurs matériels tels que des processeurs graphiques (GPU) et des TPU (Tensor Processing Units) dans GKE. Pensez à la stratégie de temps partagé des GPU, qui permet à plusieurs conteneurs de partager du temps sur le même GPU physique. Cette approche est utile pour les charges de travail GPU intensives et homogènes avec des requêtes faibles. GPU multi-instances pour partitionner des GPU afin de partager une ressource GPU unique sur plusieurs conteneurs en même temps.
Activer l'autoscaler de cluster sur des clusters standards

GKE redimensionne automatiquement le nombre de nœuds dans un pool de nœuds donné en fonction des demandes de vos charges de travail. Vous n'avez pas besoin d'ajouter ou de supprimer manuellement des nœuds, ni de surprovisionner vos pools de nœuds. À la place, il vous suffit de spécifier une taille minimale et maximale pour le pool de nœuds.

Nous vous recommandons de définir l'autoscaler de cluster avec la configuration suivante:

  • Utilisez le profil optimize-utilization qui supprime les nœuds inutilisés jusqu'à trois fois plus rapidement que le profil équilibré. Pour en savoir plus, consultez la page Profils d'autoscaling.
  • Définissez la règle de localisation sur ANY. L'autoscaler de cluster GKE donne la priorité à l'utilisation des réservations inutilisées et crée des nœuds dans n'importe quelle zone disponible des régions. Pour en savoir plus, consultez la section Règle de localisation.
  • Activez le provisionnement automatique des nœuds pour automatiquement gérer et procéder à l'autoscaling de votre infrastructure. Une fois qu'un pool de nœuds est créé à l'aide du provisionnement automatique, l'autoscaler de cluster peut effectuer un scaling dynamique du pool de nœuds. Pour en savoir plus, consultez la section Fonctionnement du provisionnement automatique des nœuds.

Avec les clusters Autopilot, vous n'avez pas à vous soucier du provisionnement des nœuds, ni de la gestion des pools de nœuds, car les pools de nœuds sont automatiquement provisionnés via le provisionnement automatique de nœuds et font l'objet d'un scaling automatique pour répondre aux exigences de vos charges de travail.
Enregistrer votre cluster dans une version disponible

GKE peut gérer automatiquement votre version de cluster et les mises à niveau. Selon votre modèle d'adoption de version, vous pouvez enregistrer votre cluster dans les canaux disponibles de GKE.

Pour en savoir plus, consultez la page Comment choisir le meilleur canal de publication pour vos clusters.
Définir un champ d'application de maintenance à exclure pour votre cluster

Avec un intervalle d'exclusion de champ d'application de mise à niveau défini, GKE respecte que les charges de travail par lot de longue durée ne sont pas interrompues pour des raisons de maintenance avant la fin.

Pour en savoir plus, consultez la section Champ d'application de la maintenance à exclure.

Gérer le cycle de vie d'un Job

Dans Kubernetes, vous exécutez vos charges de travail dans un ensemble de pods. Les pods sont des groupes de conteneurs (un ou plusieurs) avec des ressources réseau et de stockage partagées. Les pods sont définis par une spécification Kubernetes.

Un Job crée un ou plusieurs pods et continue de les exécuter jusqu'à ce qu'un nombre spécifié de pods se termine avec succès. À la fin des pods, le Job effectue le suivi des réussites. Lorsqu'un nombre défini d'achèvements spécifié est atteint, le Job est terminé.

Le tableau suivant répertorie les recommandations clés lors de la conception et de la gestion des tâches:

Recommandation Ressources
Sélectionner le mode de finalisation du job Définissez le Mode de finalisation sur Indexed. Cette configuration est utile lors de l'attribution d'une partition des données à traiter en fonction de l'index du pod. Les pods d'un Job obtiennent un index de finalisation associé. La suppression d'un Job nettoie les pods qu'il a créés. La suspension d'un Job entraîne la suppression de ses pods actifs jusqu'à ce que le Job soit réactivé.
Définir des jobs cron pour les actions planifiées standards Utilisez les Jobs Cron pour GKE pour effectuer des actions planifiées régulières, telles que des sauvegardes, la génération de rapports ou un entraînement planifié pour les modèles de machine learning.
Gérer les échecs dans un Job Définissez la stratégie d'échec des pods Kubernetes et la limite d'échec des intervalles entre les tentatives pour les pods pour gérer les échecs récupérables et non récupérables dans un Job. Cette définition améliore la consommation des ressources de cluster en évitant les nouvelles tentatives d'exécution des pods et les échecs de Jobs superflus en raison de perturbations des pods. Par exemple, vous pouvez configurer la préemption, l'éviction lancée par l'API ou l'éviction basée sur le rejet où les pods qui ne tolèrent pas l'effet de rejet NoExecute sont supprimés. Découvrez comment gérer les échecs de pod récupérables et non récupérables avec une stratégie d'échec des pods.
Gérer plusieurs Jobs en tant qu'unité Utilisez l'API JobSet pour gérer plusieurs Jobs comme une unité pour traiter des modèles de charge de travail, tels qu'un pilote (ou un coordinateur) et plusieurs nœuds de calcul (par exemple, MPIJob) tout en définissant des valeurs par défaut pour les Jobs, alignées sur des modèles courants basés sur vos cas d'utilisation. Par exemple, vous pouvez créer un Job indexé par défaut, créer un service sans adresse IP pour les noms de domaine complets prévisibles (FQDN) pour les pods et définir la règle d'échec des pods associée.
Prolonger le temps d'exécution d'un pod qui ne tolère pas les redémarrages Définissez l'annotation Kubernetes cluster-autoscaler.kubernetes.io/safe-to-evict sur false dans la spécification du pod. L'autoscaler de cluster respecte les règles d'éviction définies sur les pods. Ces restrictions peuvent empêcher la suppression d'un nœud par l'autoscaler s'il contient un pod avec l'annotation cluster-autoscaler.kubernetes.io/safe-to-evict.

Pour en savoir plus, consultez la section Prendre en compte la planification et l'interruption des pods.

Gérer l'architecture mutualisée

L'architecture mutualisée de cluster GKE est une alternative à la gestion des ressources GKE par différents utilisateurs ou charges de travail, nommés locataires, dans une organisation unique. La gestion des ressources GKE peut respecter des critères tels que l'isolation du locataire, les quotas et plages de limites ou l'allocation des coûts.

Le tableau suivant répertorie les principales recommandations lors de la gestion de l'architecture mutualisée:

Recommandation Ressources
Utiliser les espaces de noms pour gérer l'isolation des locataires Vous pouvez isoler chaque locataire ainsi que ses ressources Kubernetes dans son propre espace de noms.
Utiliser des règles pour appliquer l'isolation du locataire Définissez des règles pour limiter l'accès aux API, définir des quotas, limiter l'utilisation des ressources et restreindre les actions que les conteneurs sont autorisés à effectuer. Ces règles sont limitées par les espaces de noms.
Définir l'attribution des coûts GKE Utilisez l'allocation des coûts GKE pour obtenir des insights sur les demandes de ressources de cluster pour chaque locataire par espace de noms.

Contrôler l'accès à la plate-forme de traitement par lot

GKE vous permet d'ajuster précisément les autorisations d'accès des charges de travail exécutées sur le cluster.

Le tableau suivant répertorie les principales recommandations pour la gestion des accès et de la sécurité

Recommandation Ressources
Définir la fédération d'identité de charge de travail pour GKE GKE permet aux charges de travail de votre cluster GKE d'emprunter l'identité des comptes de service Identity and Access Management (IAM) pour accéder aux services Google Cloud. En utilisant la fédération d'identité de charge de travail pour GKE, les charges de travail peuvent accéder en toute sécurité aux secrets stockés en dehors de GKE.

Pour en savoir plus, consultez les pages Fédération d'identité de charge de travail pour GKE et Accéder aux secrets stockés.
Définir l'isolation du réseau du cluster Utilisez des clusters privés dans lesquels le point de terminaison du plan de contrôle et les nœuds de calcul peuvent avoir des adresses IP internes. Vous pouvez également modifier l'isolation des clusters publics existants qui utilisent Private Service Connect.

Pour en savoir plus, consultez les pages Clusters publics et Modifier l'isolation des clusters.

Utiliser des nœuds GKE protégés Configurez les nœuds GKE protégés afin de fournir une identité et une intégrité solides et vérifiables de nœud qui permettent de renforcer leur sécurité.
Isolement physique Pour des raisons de sécurité, vos charges de travail peuvent nécessiter une isolation plus importante. Contrôlez la planification avec des rejets de nœuds afin de séparer physiquement les locataires dans des pools de nœuds à l'aide des rejets de nœuds et des tolérances de charge de travail. Cela garantit que seules les charges de travail appropriées doivent être planifiées sur ces pools de nœuds.

Mise en file d'attente et partage équitable

Pour contrôler la consommation de ressources, vous pouvez attribuer des limites de quota de ressources à chaque locataire, mettre en file d'attente les Jobs entrants et traiter les Jobs dans l'ordre dans lequel ils ont été reçus.

Le tableau suivant répertorie les principales recommandations lors de la gestion des files d'attente et du partage équitable entre les charges de travail par lot:

Recommandation Ressources
Utiliser Kueue

Kueue est un système de file d'attente de Jobs Kubernetes natif pour le traitement par lot, les calculs hautes performances, le machine learning et des applications similaires dans un cluster Kubernetes. Pour faciliter le partage équitable des ressources de cluster entre ses locataires, Kueue gère les quotas et la manière dont les Jobs les utilisent. Kueue prend les décisions suivantes:

  • Quand un Job doit attendre ?
  • Quand un Job doit être accepté pour démarrer, par exemple en créant le pod
  • Lorsqu'un Job doit être préempté, par exemple en supprimant le pod

Pour apprendre à mettre en œuvre un système de mise en file d'attente de Job, consultez la page Mettre en œuvre un système de mise en file d'attente de Jobs avec le partage de quotas entre espaces de noms sur GKE.

Pour en savoir plus sur Kueue, consultez la page Concepts de Kueue.

Stockage, performances et rentabilité

L'utilisation efficace de nos ressources de calcul et de stockage GKE peut réduire les coûts. Une stratégie consiste à redimensionner et configurer vos instances de calcul pour qu'elles correspondent à vos besoins de traitement par lot sans sacrifier les performances.

Ce tableau présente les principales recommandations lors de la conception et de la gestion du stockage et de l'optimisation des performances:

Recommandation Ressources
Utiliser Persistent Disk Compute Engine

Nous vous recommandons d'utiliser les configurations de Persistent Disk Compute Engine suivantes:

  • Utilisez des disques persistants régionaux pour permettre aux nœuds de calcul de toutes les zones d'une région d'accéder au même espace de stockage durable sous-jacent.
  • Pour les charges de travail nécessitant un stockage hautes performances, utilisez des disques SSD locaux pour les données éphémères ou un disque persistant extrême pour les données persistantes.
  • Utilisez Persistent Disk Hyperdisk Throughput pour provisionner de manière indépendante et dynamique le débit et la capacité pour une optimisation pour les charges de travail par lot.
Utiliser le stockage en réseau

Pour des performances de stockage optimales, utilisez le stockage en réseau suivant avec Persistent Disk:

  • Utilisez Filestore pour autoriser tous les nœuds de calcul d'un pod à accéder au même espace de noms de stockage et à la capacité d'évolutivité.
  • Utilisez Cloud Storage FUSE pour accéder à Cloud Storage directement à partir d'un conteneur en tant qu'installation POSIX locale.
Définir Pub/Sub

Votre charge de travail par lot peut également lire et écrire des données. Par exemple, vous pouvez utiliser Pub/Sub et écrire les résultats dans un entrepôt de données tel que BigQuery, où les rapports et les tableaux de bord sont mis à jour.

Nous vous recommandons d'utiliser les solutions de stockage suivantes:

  • Pour le stockage d'objets géré, utilisez Cloud Storage.
  • Pour le stockage de fichiers réseau géré, utilisez Filestore.
  • Pour les charges de travail nécessitant la sémantique du système de fichiers, utilisez le pilote CSI Cloud Storage FUSE. Ce pilote permet aux applications Kubernetes d'installer des buckets Cloud Storage en tant que systèmes de fichiers locaux
Spécifier les paramètres de réglage pour votre charge de travail

Nous vous recommandons d'utiliser les configurations suivantes:

  • Personnalisez la configuration du système de votre nœud pour votre charge de travail. Par exemple, définissez les valeurs minimale, par défaut et maximale du tampon de réception de socket TCP. Utilisez la configuration du système de nœud.
  • Activez l'interrogation intensive à l'aide de profils réseau. Certaines charges de travail sensibles à la latence du réseau peuvent être améliorées. Utilisez des profils réseau.
  • Augmentez la bande passante réseau pour les nœuds GKE en activant la carte d'interface réseau virtuelle Google (gVNIC), une interface de réseau virtuelle spécialement conçue pour Compute Engine recommandée pour les applications hautes performances.
  • Spécifiez le nombre de threads par cœur pour désactiver le multithread simultané.
Optimisez la mise en réseau et la latence de vos charges de travail GKE est compatible avec la stratégie d'emplacement compact pour les pools de nœuds qui spécifie que ces nœuds (et donc les charges de travail s'exécutant sur ces nœuds) doivent être placés plus près les uns des autres dans une zone. Cela est particulièrement utile pour les charges de travail à couplage fort et hautes performances pour lesquelles une faible latence entre les différents processus comprenant la charge de travail est une préoccupation majeure. Pour en savoir plus, consultez la section Emplacement compact.
Utilisez des VM Spot

Les VM spot sont des instances de machines virtuelles (VM) Compute Engine dont le prix est inférieur à celui des VM Compute Engine standards et qui n'offrent aucune garantie de disponibilité.

Nous vous recommandons d'utiliser les solutions suivantes:

  • Définissez l'autoscaling des pools de nœuds de VM Spot en combinaison avec location_policy= "ANY". Avec cette règle, les VM Spot présentent un risque plus faible de préemption. Cette combinaison est particulièrement utile pour les charges de travail qui peuvent survivre à la préemption de nœuds de calcul individuels, telles que les calculs parallèles réussis.
  • Si votre charge de travail présente une empreinte de ressource prévisible, combinez les réservations Google Cloud et les remises sur engagement d'utilisation pour réaliser des économies considérables. Créez un pool de nœuds en définissant sa taille sur le nombre d'instances réservées, et privilégiez la saturation de ce pool de nœuds pour une utilisation maximale.
Utiliser le streaming d'images

Utiliser le streaming d'image pour extraire des images de conteneur GKE diffuse les données à partir d'images éligibles. Cela permet à vos charges de travail de s'initialiser sans attendre le téléchargement de l'image entière, ce qui réduit considérablement les délais d'initialisation et améliore la rentabilité.

Surveillance

GKE est intégré à des outils d'observabilité et de journalisation qui vous aident à surveiller la fiabilité et l'efficacité de votre cluster. Le tableau suivant répertorie les recommandations clés lors de l'activation et de l'utilisation des outils d'observabilité de GKE:

Recommandation Ressources
Utiliser Prometheus

GKE est intégré à Google Cloud Observability. Personnalisez les métriques que vous souhaitez que GKE envoie à Cloud Logging et Cloud Monitoring

Google Cloud Managed Service pour Prometheus est activé par défaut pour les clusters GKE. Nous vous recommandons d'utiliser la collecte gérée pour éliminer la complexité de la configuration et de la maintenance des serveurs Prometheus.

Pour en savoir plus, consultez la section Service géré pour Prometheus.
Utiliser les tableaux de bord Cloud Monitoring

Utilisez les tableaux de bord Monitoring pour GKE pour afficher une vue d'ensemble de l'utilisation des clusters et des ressources, et afficher et filtrer les différentes métriques et dimensions.

Pour en savoir plus, consultez la page Observer les clusters GKE.

Étapes suivantes