Cette page décrit les bonnes pratiques à suivre pour gérer des charges de travail volumineuses sur plusieurs clusters GKE. Ces bonnes pratiques abordent les considérations à prendre en compte pour répartir les charges de travail sur plusieurs projets et ajuster les quotas requis.
Bonnes pratiques pour la répartition de charges de travail GKE sur plusieurs projets Google Cloud
Pour mieux définir la structure de votre projet Google Cloud et la répartition de vos charges de travail GKE en fonction des besoins de votre entreprise, nous vous recommandons d'envisager les actions de conception et de planification suivantes :
- Suivez les bonnes pratiques de gestion des ressources cloud afin de prendre les décisions initiales concernant la structure de votre organisation pour les dossiers et les projets. Google Cloud recommande d'utiliser des éléments de la hiérarchie des ressources, tels que des dossiers et des projets, pour répartir votre charge de travail en fonction de vos propres limites organisationnelles ou de vos règles d'accès.
- Déterminez si vous devez répartir vos charges de travail en raison des quotas de projet. Google Cloud utilise des quotas par projet pour limiter l'utilisation des ressources partagées. Vous devez suivre les recommandations décrites ci-dessous et ajuster les quotas de projet pour les charges de travail volumineuses. Pour la plupart des charges de travail, vous devriez pouvoir atteindre les quotas plus élevés requis dans un seul projet. Cela signifie que les quotas ne doivent pas être la principale motivation pour la répartition de votre charge de travail entre plusieurs projets. Conserver vos charges de travail dans un nombre réduit de projets simplifie l'administration de vos quotas et charges de travail.
- Déterminez si vous prévoyez d'exécuter des charges de travail très volumineuses (à une échelle de plusieurs centaines de milliers de processeurs ou plus). Dans ce cas, le fractionnement de votre charge de travail sur plusieurs projets peut améliorer la disponibilité des ressources cloud (telles que les processeurs ou les GPU). Cela est possible grâce à l'utilisation d'une configuration optimisée de la virtualisation de zone. Dans ce cas, veuillez contacter votre responsable de compte pour obtenir une assistance et des recommandations spécifiques.
Bonnes pratiques d'ajustement des quotas pour les charges de travail GKE volumineuses
Cette section fournit des consignes concernant l'ajustement des quotas pour les ressources Google Cloud utilisées par les charges de travail GKE. Ajustez les quotas de vos projets en fonction des consignes suivantes. Pour savoir comment gérer votre quota à l'aide de la console Google Cloud, consultez la page Les quotas et leur utilisation.
Quotas et bonnes pratiques Compute Engine
Les clusters GKE s'exécutant en mode Autopilot et en mode standard utilisent des ressources Compute Engine pour exécuter vos charges de travail. Contrairement aux ressources du plan de contrôle Kubernetes, qui sont gérées en interne par Google Cloud, vous pouvez gérer et évaluer les quotas Compute Engine utilisés par vos workflows.
Les quotas Compute Engine, pour les ressources aussi bien que les API, sont partagés par tous les clusters GKE hébergés dans le même projet et la même région. Les mêmes quotas sont également partagés avec d'autres ressources Compute Engine non liées à GKE (telles que les instances de VM autonomes ou les groupes d'instances).
Les valeurs de quota par défaut peuvent prendre en charge plusieurs centaines de nœuds de calcul et nécessiter un ajustement pour les charges de travail plus importantes. Toutefois, en tant qu'administrateur de plate-forme, vous pouvez ajuster de manière proactive les quotas Compute Engine pour vous assurer que vos clusters GKE disposent de ressources suffisantes. Vous devez également prendre en compte les besoins futurs en ressources pour évaluer ou ajuster les valeurs de quota.
Quotas de ressources Compute Engine utilisées par les nœuds de calcul GKE
Le tableau suivant répertorie les quotas pour les ressources Compute Engine les plus courantes utilisées par les nœuds de calcul GKE. Ces quotas sont configurés par projet et par région. Les quotas doivent couvrir la taille maximale combinée des nœuds de calcul GKE utilisés par votre charge de travail, ainsi que les autres ressources Compute Engine non liées à GKE.
| Quota de ressources | Description |
|---|---|
| CPU | Nombre de processeurs utilisés par l'ensemble des nœuds de calcul de tous les clusters. |
| Types de processeurs | Nombre de chaque type de processeur spécifique utilisé par l'ensemble des nœuds de calcul de tous les clusters. |
| Instances de VM | Nombre total de nœuds de calcul. Ce quota est automatiquement calculé comme étant 10 fois le nombre de processeurs. |
| Instances par réseau VPC | Nombre total de nœuds de calcul connectés au réseau VPC. |
| Disque persistant standard (Go) | Taille totale des disques de démarrage persistants standards associés à tous les nœuds de calcul. |
| Disque persistant SSD (Go) | Taille totale des disques de démarrage persistants SSD associés à tous les nœuds de calcul. |
| SSD local (Go) | Taille totale des disques éphémères SSD locaux associés à tous les nœuds de calcul. |
Veillez à ajuster également les quotas utilisés par les ressources requises par votre charge de travail, telles que les GPU, les adresses IP ou les ressources préemptives.
Quotas pour les appels d'API Compute Engine
Les clusters volumineux ou évolutifs nécessitent un plus grand nombre d'appels d'API Compute Engine. GKE effectue ces appels d'API Compute Engine au cours d'activités telles que :
- La vérification de l'état des ressources de calcul
- L'ajout ou la suppression de nouveaux nœuds du cluster
- L'ajout ou la suppression de nouveaux pools de nœuds
- L'étiquetage périodique des ressources
Lorsque vous planifiez votre architecture de cluster à grande échelle, nous vous recommandons de procéder comme suit :
- Observez l'historique de la consommation des quotas.
- Ajustez les quotas selon vos besoins tout en conservant un tampon raisonnable. Vous pouvez vous référer aux bonnes pratiques recommandées suivantes comme point de départ et ajuster les quotas en fonction des besoins de votre charge de travail.
- Comme les quotas sont configurés par région, ajustez-les uniquement dans les régions où vous prévoyez d'exécuter des charges de travail importantes.
Le tableau suivant répertorie les quotas pour les appels d'API Compute Engine. Ces quotas sont configurés par projet, indépendamment pour chaque région. Les quotas sont partagés par tous les clusters GKE hébergés dans le même projet et dans la même région.
| Quota d'API | Description | Bonnes pratiques |
|---|---|---|
| Requêtes par minute et par région | Ces appels permettent à GKE d'effectuer diverses vérifications par rapport à l'état des différentes ressources de calcul. |
Pour les projets et les régions comportant plusieurs centaines de nœuds dynamiques, définissez cette valeur sur 3 500. Pour les projets et les régions comportant plusieurs milliers de nœuds hautement dynamiques, définissez cette valeur sur 6 000. |
| Requêtes de lecture par minute et par région | Ces appels permettent à GKE de surveiller l'état des instances de VM (nœuds). |
Pour les projets et les régions comportant plusieurs centaines de nœuds, définissez cette valeur sur 12 000. Pour les projets et les régions comportant des milliers de nœuds, définissez cette valeur sur 20 000. |
| Requêtes List par minute et par région | Ces appels sont utilisés par GKE pour surveiller l'état des groupes d'instances (pools de nœuds). |
Pour les projets et les régions comportant plusieurs centaines de nœuds dynamiques, ne modifiez pas la valeur par défaut qui est suffisante. Pour les projets et les régions comportant des milliers de nœuds hautement dynamiques, définissez cette valeur sur 2 500 dans plusieurs pools de nœuds. |
| Requêtes de provenance de liste d'instances par minute et par région | Ces appels permettent à GKE d'obtenir des informations sur l'exécution d'instances de VM (nœuds). |
Pour les projets et les régions comportant des milliers de nœuds hautement dynamiques, définissez cette valeur sur 6 000. |
| Requêtes de lecture par minute et par région | Ces appels permettent à GKE d'obtenir des informations sur les opérations de l'API Compute Engine en cours. |
Pour les projets et les régions comportant des milliers de nœuds hautement dynamiques, définissez cette valeur sur 3 000. |
Quotas et bonnes pratiques pour l'API Cloud Logging et l'API Cloud Monitoring
Suivant la configuration de votre cluster, les charges de travail volumineuses exécutées sur les clusters GKE peuvent générer un volume important d'informations de diagnostic. Lorsque vous dépassez les quotas de l'API Cloud Logging ou de l'API Cloud Monitoring, des données de journalisation et de surveillance peuvent être perdues. Nous vous recommandons de configurer la verbosité des journaux et d'ajuster les quotas de l'API Cloud Logging et de l'API Cloud Monitoring pour capturer les informations de diagnostic générées. Managed Service pour Prometheus utilise les quotas de Cloud Monitoring.
Chaque charge de travail étant différente, nous vous recommandons de procéder comme suit :
- Observez l'historique de la consommation des quotas.
- Ajustez les quotas ou ajustez la configuration de la journalisation et de la surveillance si nécessaire. Conservez un tampon raisonnable pour les problèmes inattendus.
Le tableau suivant répertorie les quotas pour les appels à l'API Cloud Logging et à l'API Cloud Monitoring. Ces quotas sont configurés par projet et sont partagés par tous les clusters GKE hébergés dans le même projet.
| Service | Quotas | Description | Bonnes pratiques |
|---|---|---|---|
| API Cloud Logging | Requêtes d'écriture par minute | GKE utilise ce quota lors de l'ajout d'entrées aux fichiers journaux stockés dans Cloud Logging. |
Le taux d'insertion de journaux dépend de la quantité de journaux générés par les pods de votre cluster. Augmentez votre quota en fonction du nombre de pods, de la verbosité de la journalisation des applications et de la configuration de la journalisation. Pour en savoir plus, consultez la page Gérer les journaux GKE. |
| API Cloud Monitoring | Requêtes d'ingestion de séries temporelles par minute |
GKE utilise ce quota lors de l'envoi de métriques Prometheus à Cloud Monitoring :
|
Surveillez et ajustez ce quota selon vos besoins. Pour en savoir plus, consultez la page Gérer les métriques GKE. |
Quotas de nœuds GKE et bonnes pratiques
GKE accepte jusqu'à 15 000 nœuds dans un seul cluster avec le quota par défaut défini sur 5 000 nœuds. Ce quota est défini séparément pour chaque cluster GKE et non par projet comme les autres quotas. Si vous prévoyez d'effectuer un scaling de votre cluster au-delà de 5 000 nœuds, procédez comme suit :
- Identifiez le cluster que vous souhaitez faire évoluer au-delà de 5 000 nœuds.
- Assurez-vous que votre charge de travail respecte les limites du cluster et les quotas GKE après le scaling.
- Veillez à augmenter les quotas Compute Engine en fonction de votre charge de travail adaptée.
- Assurez-vous que le type de disponibilité de votre cluster est régional et que l'isolation du réseau est privée.
- Demandez une augmentation du quota de nœuds par cluster en créant une demande d'assistance.
L'équipe GKE vous contactera pour vous assurer que votre charge de travail respecte les bonnes pratiques d'évolutivité et est prête à évoluer au-delà de 5 000 nœuds sur un seul cluster.
Bonnes pratiques pour éviter les autres limites pour les charges de travail volumineuses
Limiter le nombre de clusters utilisant l'appairage de réseaux VPC par réseau et par emplacement
Vous pouvez créer jusqu'à 75 clusters privés utilisant l'appairage de réseaux VPC dans le même réseau VPC pour chaque emplacement (les zones et les régions sont traitées comme des emplacements distincts). Les tentatives de création de clusters supplémentaires au-delà de la limite échouent avec une erreur semblable à celle-ci :
CREATE operation failed. Could not trigger cluster creation:
Your network already has the maximum number of clusters: (75) in location us-central1.
Les clusters privés GKE utilisent l'appairage de réseaux VPC pour fournir une communication interne entre le serveur d'API Kubernetes (géré par Google) et les nœuds privés ne disposant que d'adresses internes.
Pour résoudre ce problème, vous pouvez utiliser des clusters utilisant la connectivité Private Service Connect (PSC). Les clusters avec connectivité PSC offrent la même isolation qu'un cluster privé, sans la limite des 75 clusters. Les clusters basés sur PSC n'utilisent pas l'appairage de réseaux VPC et ne sont pas affectés par la limite du nombre d'appairages VPC.
Vous pouvez utiliser les instructions fournies dans la section Réutilisation de l'appairage de réseaux VPC pour déterminer si vos clusters utilisent l'appairage de réseaux VPC.
Pour éviter d'atteindre la limite lors de la création de clusters, procédez comme suit :
- Créez un cluster PSC à l'aide du paramètre
no-enable-private-nodeslors de la création du cluster. - Configurez l'isolation pour que les pools de nœuds deviennent privés en utilisant le paramètre
enable-private-nodespour chaque pool de nœuds. - Vous pouvez également configurer l'isolation du plan de contrôle à l'aide du paramètre
enable-private-endpointau niveau du cluster. Pour en savoir plus, consultez la page Modifier l'isolation d'un cluster.
Vous pouvez également contacter l'équipe d'assistance Google Cloud pour augmenter la limite de 75 clusters privés associée à l'appairage de réseaux VPC. Ces demandes sont évaluées au cas par cas et, lorsqu'il est possible d'augmenter la limite, une augmentation à un seul chiffre est appliquée.
Étape suivante
- Consultez nos épisodes sur la création de clusters GKE volumineux.