Cette page décrit les bonnes pratiques à suivre lors de la planification et la conception de clusters de très grande taille.
Pourquoi planifier les clusters GKE volumineux
Chaque système informatique, y compris Kubernetes, présente certaines limites architecturales. Le dépassement de ces limites peut avoir une incidence sur les performances de votre cluster ou même, dans certains cas, entraîner des temps d'arrêt. Suivez les bonnes pratiques et exécutez les actions recommandées pour vous assurer que vos clusters exécutent vos charges de travail de manière fiable à grande échelle.
Bonnes pratiques pour la division des charges de travail entre plusieurs clusters
Vous pouvez exécuter vos charges de travail sur un seul cluster volumineux. Cette approche est plus facile à gérer, plus économique et offre une meilleure utilisation des ressources qu'une infrastructure à plusieurs clusters. Toutefois, dans certains cas, vous devez envisager de diviser votre charge de travail entre plusieurs clusters :
- Consultez les cas d'utilisation de multicluster pour en savoir plus sur les exigences générales et les scénarios d'utilisation de plusieurs clusters.
- De plus, du point de vue de l'évolutivité, vous pouvez diviser votre cluster lorsqu'il risque de dépasser l'une des limites décrites dans la section ci-dessous ou l'un des quotas GKE. En réduisant les risques liés au dépassement de limites de GKE, vous réduisez les risques de temps d'arrêt ou d'autres problèmes de fiabilité.
Si vous décidez de diviser votre cluster, utilisez la gestion de parc pour simplifier la gestion d'un parc multicluster.
Limites et bonnes pratiques
Pour vous assurer que votre architecture est compatible avec les clusters GKE à grande échelle, passez en revue les limites suivantes et les bonnes pratiques associées. Le dépassement de ces limites peut entraîner une dégradation des performances du cluster ou des problèmes de fiabilité.
Ces bonnes pratiques s'appliquent à tout cluster Kubernetes par défaut sans extension installée. L'extension des clusters Kubernetes à l'aide de webhooks ou de définitions de ressources personnalisées (CRD) est une pratique courante, mais susceptible de limiter votre capacité à faire évoluer le cluster.
Le tableau suivant prolonge les quotas et limites principaux de GKE. Vous devez également vous familiariser avec les limites de Kubernetes Open Source pour les clusters à grande échelle.
Les exigences de version GKE mentionnées dans le tableau s'appliquent à la fois aux nœuds et au plan de contrôle.
| Limites de GKE | Description | Bonnes pratiques |
|---|---|---|
| Taille de la base de données etcd | La taille maximale de la base de données etcd est de 6 Go. Si vous exécutez un cluster très volumineux comportant des dizaines de milliers de ressources, vos instances etcd peuvent dépasser cette limite. Vous pouvez vérifier le niveau d'utilisation de vos clusters dans la console Google Cloud. | Si vous dépassez cette limite, GKE peut signaler vos instances etcd comme non opérationnelles. Le plan de contrôle des clusters ne répond alors plus.
Si vous dépassez cette limite, contactez l'assistance Google Cloud. |
| Taille totale des objets etcd par type | La taille totale de tous les objets d'un type de ressource donné ne doit pas dépasser 800 Mo. Par exemple, vous pouvez créer 750 Mo d'instances de pods et 750 Mo de secrets, mais vous ne pouvez pas créer 850 Mo de secrets. Si vous créez plus de 800 Mo d'objets, cela peut empêcher l'initialisation de Kubernetes ou des contrôleurs personnalisés et provoquer des interruptions. |
La taille totale de l'ensemble des objets de chaque type stockés dans etcd doit rester inférieure à 800 Mo. Cela s'applique particulièrement aux clusters utilisant de nombreux secrets ou ConfigMaps de grande taille, ou un grand nombre de CRD. |
| Nombre de services pour les clusters dans lesquels GKE Dataplane V2 n'est pas activé | Les performances des iptables utilisées par kube-proxy se dégradent dans les cas suivants :
Cette limite est supprimée lorsque GKE Dataplane V2 est activé. |
Le nombre de services du cluster doit être inférieur à 10 000. Pour en savoir plus, consultez la section Exposer des applications à l'aide de services. |
| Nombre de services par espace de noms | Le nombre de variables d'environnement générées pour les services peut dépasser les limites du shell. Cela peut entraîner le plantage des pods au démarrage. |
Le nombre de services par espace de noms doit être inférieur à 5 000. Vous pouvez désactiver le remplissage de ces variables d'environnement. Consultez la documentation pour savoir comment définir Pour en savoir plus, consultez la section Exposer des applications à l'aide de services. |
| Nombre de pods derrière un seul service pour les clusters où GKE Dataplane V2 n'est pas activé |
Chaque nœud exécute un proxy kube-proxy qui utilise des requêtes watch pour surveiller les modifications apportées aux services. Plus le cluster est volumineux, plus le volume de données associées au changement traité par l'agent est important. Cela est particulièrement visible pour les clusters de plus de 500 nœuds. Les informations sur les points de terminaison sont réparties entre plusieurs Les objets Endpoint sont toujours disponibles pour les composants, mais tout point de terminaison dépassant 1 000 pods est automatiquement tronqué. |
Le nombre de pods derrière un seul service doit être inférieur à 10 000. Pour en savoir plus, consultez la section Exposer des applications à l'aide de services. |
| Nombre de pods derrière un même service pour les clusters sur lesquels GKE Dataplane V2 est activé |
GKE Dataplane V2 contient des limites sur le nombre de pods exposés par un seul service. La même limite s'applique aux clusters Autopilot, car ils utilisent GKE Dataplane V2. |
Dans GKE 1.23 et versions antérieures, veillez à ce que le nombre de pods derrière un seul service soit inférieur à 1 000. Dans GKE 1.24 et versions ultérieures, veillez à ce que le nombre de pods derrière un seul service soit inférieur à 10 000. Pour en savoir plus, consultez la section Exposer des applications à l'aide de services. |
| Enregistrements DNS par service sans adresse IP de cluster |
Le nombre d'enregistrements DNS par service sans adresse IP de cluster est limité pour kube-dns et Cloud DNS. |
Le nombre d'enregistrements DNS par service headless (ou "service sans tête) doit être inférieur à 1000 pour kube-dns et à 3500/2000 (IPv4/IPv6) pour Cloud DNS. |
| Nombre total de points de terminaison de service | Le nombre de points de terminaison pour l'ensemble des services peut atteindre les limites. Cela peut augmenter la latence de programmation ou entraîner une impossibilité de programmer de nouveaux points de terminaison. |
Le nombre total de points de terminaison dans l'ensemble des services doit rester inférieur à 260 000. GKE Dataplane V2, qui est le plan de données par défaut pour GKE, repose sur des cartes eBPF actuellement limitées à 260 000 points de terminaison sur l'ensemble des services. |
| Nombre d'objets de l'autoscaler horizontal de pods par cluster |
Chaque autoscaler horizontal de pods (HPA) est traité toutes les 15 secondes. Plus de 300 objets HPA peuvent entraîner une dégradation linéaire des performances. |
Respectez les limites liées au nombre d'objets HPA. Vous risquez sinon de rencontrer une dégradation linéaire de la fréquence du traitement HPA. Par exemple, dans GKE 1.22 avec 2 000 objets HPA, un seul objet HPA sera traité à nouveau toutes les minutes et 40 secondes. Pour en savoir plus, consultez les sections Effectuer un autoscaling basé sur l'utilisation des ressources et Autoscaling horizontal des pods. |
| Nombre de pods par nœud | GKE possède une limite stricte de 256 pods par nœud. Cela suppose une moyenne de deux conteneurs ou moins par pod. Si vous augmentez le nombre de conteneurs par pod, cette limite peut être inférieure, car GKE alloue plus de ressources par conteneur. |
Nous vous recommandons d'utiliser des nœuds de calcul dotés d'au moins un processeur virtuel par tranche de 10 pods. Pour en savoir plus, consultez la section Mettre à jour manuellement un cluster ou un pool de nœuds. |
| Taux des modifications de pods |
Kubernetes possède des limites internes qui ont un impact sur la vitesse de création ou de suppression des pods (taux de perte de pods) en réponse aux requêtes de scaling. Des facteurs supplémentaires, tels que la suppression d'un pod faisant partie d'un service, peuvent également avoir un impact sur ce taux de perte de pods. Pour les clusters comportant jusqu'à 500 nœuds, vous pouvez vous attendre à un taux moyen de 20 pods créés par seconde et de 20 pods supprimés par seconde. Pour les clusters de plus de 500 nœuds, vous pouvez vous attendre à un taux moyen de 100 pods créés par seconde et de 100 pods supprimés par seconde. |
Prenez en compte la limite du taux de création et de suppression des pods lorsque vous planifiez le scaling de vos charges de travail. Les pods ont le même débit de suppression que d'autres types de ressources (par exemple, EndpointSlices). Vous pouvez réduire le débit de suppression lorsque vous définissez des pods dans le cadre d'un service. Pour permettre à l'autoscaler de cluster de supprimer efficacement les pods des nœuds sous-utilisés, évitez les PodDisruptionBudgets trop restrictifs et les longs délais de grâce pour l'arrêt. Les tolérances génériques sont également déconseillées, car elles peuvent entraîner la planification des charges de travail sur des nœuds en cours de suppression. |
| Nombre de requêtes watch ouvertes | Les nœuds créent une requête "watch" pour chaque secret et ConfigMaps que vous configurez pour les pods. La quantité combinée d'observations créées par l'ensemble Des nœuds peut générer une charge importante sur le plan de contrôle du cluster. Le fait d'avoir plus de 200 000 requêtes "watch" par cluster peut affecter le délai d'initialisation du cluster. Ce problème peut entraîner le redémarrage fréquent du plan de contrôle. |
Définissez des nœuds plus importants pour réduire la probabilité et la gravité des problèmes causés par un grand nombre de requêtes "watch". Une densité de pods plus élevée (moins de nœuds, mais de plus grande taille) peut réduire le nombre de requêtes "watch" et atténuer la gravité du problème. Pour en savoir plus, consultez la Comparaison des séries de machines. |
| Nombre de secrets par cluster si le chiffrement des secrets au niveau de la couche d'application est activé | Lorsque le chiffrement des secrets au niveau de la couche d'application est activé, un cluster doit déchiffrer tous les secrets lors son démarrage. Si vous stockez plus de 30 000 secrets, votre cluster peut devenir instable lors du démarrage ou des mises à niveau, ce qui entraîne des interruptions des charges de travail. | Stockez moins de 30 000 secrets lorsque vous utilisez le chiffrement des secrets au niveau de la couche d'application. Pour en savoir plus, consultez la section Chiffrer les secrets au niveau de la couche d'application. |
| Bande passante de journal par nœud |
Le nombre maximal de journaux envoyés par chaque nœud à l'API Cloud Logging est limité. La limite par défaut varie entre 100 kbit/s et 500 kbit/s en fonction de la charge. Vous pouvez augmenter la limite à 10 Mbit/s en déployant une configuration d'agent de journalisation à haut débit. Si vous dépassez cette limite, les entrées de journal peuvent être supprimées. |
Configurez Logging pour qu'il respecte les limites par défaut ou configurez un agent de journalisation à haut débit. Pour en savoir plus, consultez la section Augmenter le débit de l'agent de journalisation. |
| Limites de Sauvegarde pour GKE |
Vous pouvez utiliser Sauvegarde pour GKE pour sauvegarder et restaurer vos charges de travail GKE. Ce service est soumis à des limites que vous devez prendre en compte lorsque vous définissez vos plans de sauvegarde. |
Consultez les limites de Sauvegarde pour GKE. S'il est possible que votre charge de travail dépasse ces limites, nous vous recommandons de créer plusieurs plans de sauvegarde pour partitionner votre sauvegarde et respecter les limites. |
| Limites de Config Connector |
Vous pouvez utiliser Config Connector pour gérer les ressources Google Cloud via Kubernetes. Config Connector propose deux modes de fonctionnement :
|
Chaque instance Config Connector dispose d'une demande de ressources processeur de 0,1 et d'une limite de mémoire de 512 Mo. Par conséquent, elle ne s'adapte pas bien à une grande quantité de ressources gérées. Nous vous recommandons de ne pas avoir plus de 25 000 ressources Google Cloud par instance Config Connector. Cette limite n'est fournie qu'à titre de référence, car la quantité de mémoire utilisée dépend du type de ressource et des cas d'utilisation spécifiques. Lorsque vous gérez un plus grand nombre de ressources gérées, nous vous recommandons d'utiliser le mode Espace de noms pour limiter le nombre de ressources gérées par chaque instance Config Connector. Nous vous recommandons d'utiliser jusqu'à 500 espaces de noms avec Config Connector en mode Espace de noms.
Chaque instance Config Connector ouvre de nombreuses connexions de surveillance au kube-apiserver. Un grand nombre de ces instances peuvent surcharger le plan de contrôle du cluster GKE, en particulier lors des mises à niveau du plan de contrôle, lorsque les connexions de surveillance doivent être réinitialisées. Nous recommandons d'utiliser plusieurs clusters GKE afin de gérer le nombre de ressources qui n'ont pas pu être divisées afin de respecter les limites spécifiées ci-dessus. Pour en savoir plus, consultez la page Consignes relatives à l'évolutivité de Config Controller. |