Faire évoluer les clusters GKE sur Bare Metal à la hausse

Comme pour tout cluster Kubernetes, l'évolutivité d'un cluster GKE sur Bare Metal présente de nombreuses dimensions interdépendantes. L'objectif de ce document est de vous aider à comprendre les dimensions clés que vous pouvez ajuster pour faire évoluer vos clusters à la hausse sans perturber vos charges de travail.

Comprendre les limites

GKE sur Bare Metal est un système complexe doté d'une grande surface d'intégration. De nombreuses dimensions affectent l'évolutivité du cluster. Par exemple, le nombre de nœuds ne représente que l'une des nombreuses dimensions sur lesquelles GKE sur une solution Bare Metal peut évoluer. Les autres dimensions incluent le nombre total de pods et de services. Un grand nombre de ces dimensions, telles que le nombre de pods par nœud et le nombre de nœuds par cluster, sont corrélées. Pour en savoir plus sur les dimensions ayant un effet sur l'évolutivité, consultez la section Seuils d'évolutivité de Kubernetes dans la section "Scalability Special Interest Group (SIG)" du dépôt de la communauté Kubernetes sur GitHub.

Les limites d'évolutivité sont également sensibles à la configuration matérielle et de nœud sur laquelle votre cluster s'exécute. Les limites décrites dans ce document sont validées dans un environnement probablement différent du vôtre. Par conséquent, il se peut que vous ne reproduisez pas les mêmes chiffres lorsque l'environnement sous-jacent est le facteur limitant.

Pour en savoir plus sur les limites qui s'appliquent à vos clusters GKE sur Bare Metal, consultez la page Quotas et limites.

Se préparer au scaling

Lorsque vous préparez le scaling de vos clusters GKE sur Bare Metal, tenez compte des exigences et des limites décrites dans les sections suivantes.

Exigences en termes de processeur et de mémoire pour le nœud du plan de contrôle

Le tableau suivant présente la configuration de processeur et de mémoire recommandée pour les nœuds de plan de contrôle pour les clusters exécutant des charges de travail de production:

Nombre de nœuds de cluster Processeurs recommandés pour le plan de contrôle Mémoire recommandée pour le plan de contrôle
1-50 8 cœurs 32 Gio
51 à 100 16 cœurs 64 Gio

Nombre de pods et de services

Le nombre de pods et de services que vous pouvez avoir dans vos clusters est contrôlé par les paramètres suivants:

CIDR des pods et nombre maximal de nœuds

Le nombre total d'adresses IP réservées aux pods de votre cluster est l'un des facteurs limitant le scaling à la hausse de votre cluster. Associé au paramètre "Nombre maximal de pods par nœud", ce paramètre détermine le nombre maximal de nœuds que vous pouvez avoir dans votre cluster avant de risquer d'épuiser les adresses IP de vos pods.

Réfléchissez aux éléments suivants :

  • Le nombre total d'adresses IP réservées aux pods de votre cluster est spécifié par clusterNetwork.pods.cidrBlocks, qui accepte une plage d'adresses IP spécifiée dans la notation CIDR. Par exemple, la valeur préremplie 192.168.0.0/16 spécifie une plage de 65 536 adresses IP allant de 192.168.0.0 à 192.168.255.255.

  • Le nombre maximal de pods pouvant s'exécuter sur un seul nœud est spécifié dans nodeConfig.podDensity.maxPodsPerNode.

  • Selon le paramètre du nombre maximal de pods par nœud, GKE sur une solution Bare Metal provisionne environ deux fois plus d'adresses IP pour le nœud. Ces adresses IP supplémentaires permettent d'éviter toute réutilisation accidentelle des adresses IP de pods dans un court laps de temps.

  • La division du nombre total d'adresses IP de pods par le nombre d'adresses IP de pods provisionnées sur chaque nœud vous permet d'obtenir le nombre total de nœuds que vous pouvez avoir dans votre cluster.

Par exemple, si le CIDR de votre pod est 192.168.0.0/17, vous disposez d'un total de 32 768 adresses IP (2(32-17) = 215 = 32 768). Si vous définissez le nombre maximal de pods par nœud sur 250, GKE sur Bare Metal provisionne une plage d'environ 500 adresses IP, ce qui équivaut à un bloc CIDR /23 (2(32-23) = 29 = 512). Ainsi, le nombre maximal de nœuds dans ce cas est de 64 (215 adresses par cluster divisé par 29 adresses/nœud = 2(15-9) nœuds/cluster = 26 = 64 nœuds/cluster.

clusterNetwork.pods.cidrBlocks et nodeConfig.podDensity.maxPodsPerNode étant immuables, réfléchissez bien à la croissance future de votre cluster afin d'éviter de manquer de capacité de nœuds. Pour connaître les valeurs maximales recommandées pour les pods par cluster, les pods par nœud et les nœuds par cluster sur la base des tests, consultez la section Limites.

CIDR des services

Le bloc CIDR des services peut être mis à jour pour ajouter d'autres services à mesure que vous faites évoluer le cluster. En revanche, vous ne pouvez pas réduire la plage CIDR des services. Pour plus d'informations, consultez la section Augmenter la plage du réseau du service.

Ressources réservées aux daemons système

Par défaut, GKE sur Bare Metal réserve automatiquement des ressources sur un nœud pour les daemons système, tels que sshd ou udev. Les ressources de processeur et de mémoire sont réservées sur un nœud pour les daemons système afin que ces daemons disposent des ressources dont ils ont besoin. Sans cette fonctionnalité, les pods peuvent potentiellement consommer la plupart des ressources d'un nœud, ce qui empêche les daemons système d'effectuer leurs tâches.

Plus précisément, GKE sur Bare Metal réserve 80 millicores de processeur (80 mCPU) et 280 mébioctets (280 Mio) de mémoire sur chaque nœud aux daemons système. Notez que l'unité de processeur mCPU correspond au millième de cœur. Ainsi, 80/1 000 ou 8 % d'un cœur sur chaque nœud sont réservés aux daemons système. La quantité de ressources réservées est faible et n'a pas d'impact significatif sur les performances des pods. Cependant, le kubelet d'un nœud peut évincer des pods si leur utilisation du processeur ou de la mémoire dépasse les quantités qui leur ont été allouées.

Mise en réseau avec MetalLB

Nous vous recommandons d'augmenter le nombre d'enceintes MetalLB pour traiter les aspects suivants:

  • Bande passante: toute la bande passante du cluster pour les services d'équilibrage de charge dépend du nombre de locuteurs et de la bande passante de chaque nœud d'enceinte. L'augmentation du trafic réseau nécessite davantage de haut-parleurs.

  • Tolérance aux pannes: un nombre plus élevé d'enceintes réduit l'impact global d'une défaillance d'une seule enceinte.

MetalLB nécessite une connectivité de couche 2 entre les nœuds d'équilibrage de charge. Dans ce cas, vous pouvez être limité par le nombre de nœuds avec une connectivité de couche 2 où vous pouvez placer des haut-parleurs MetalLB.

Planifiez soigneusement le nombre d'enceintes MetalLB que vous souhaitez avoir dans votre cluster et déterminez le nombre de nœuds de couche 2 dont vous avez besoin. Pour en savoir plus, consultez la page Problèmes d'évolutivité de MetalLB.

Par ailleurs, lorsque vous utilisez le mode d'équilibrage de charge groupé, les nœuds du plan de contrôle doivent également se trouver sous le même réseau de couche 2. Cette restriction ne s'applique pas à l'équilibrage de charge manuel. Pour en savoir plus, consultez la section Mode Équilibreur de charge manuel.

Exécuter un grand nombre de nœuds, de pods et de services

L'ajout de nœuds, de pods et de services permet de faire évoluer votre cluster à la hausse. Les sections suivantes présentent des paramètres et configurations supplémentaires à prendre en compte lorsque vous augmentez le nombre de nœuds, de pods et de services dans votre cluster. Pour en savoir plus sur les limites de ces dimensions et leurs relations entre elles, consultez Limites.

Créer un cluster sans kube-proxy

Pour créer un cluster hautes performances pouvant évoluer afin d'utiliser un grand nombre de services et de points de terminaison, nous vous recommandons de créer le cluster sans kube-proxy. Sans kube-proxy, le cluster utilise GKE Dataplane V2 en mode kube-proxy-replacement. Ce mode évite la consommation de ressources requise pour conserver un grand nombre de règles iptables.

Vous ne pouvez pas désactiver l'utilisation de kube-proxy pour un cluster existant. Cette configuration doit être définie lors de la création du cluster. Pour obtenir des instructions et plus d'informations, consultez la section Créer un cluster sans kube-proxy.

Configuration CoreDNS

Cette section décrit les aspects de CoreDNS qui affectent l'évolutivité de vos clusters.

DNS du pod

Par défaut, les clusters GKE sur Bare Metal injectent des pods avec un élément resolv.conf semblable à celui-ci:

nameserver KUBEDNS_CLUSTER_IP
search <NAMESPACE>.svc.cluster.local svc.cluster.local cluster.local c.PROJECT_ID.internal google.internal
options ndots:5

L'option ndots:5 signifie que les noms d'hôte comportant moins de cinq points ne sont pas considérés comme un nom de domaine complet. Le serveur DNS ajoute tous les domaines de recherche spécifiés avant de rechercher le nom d'hôte demandé à l'origine, qui ordonne les recherches comme suit lors de la résolution de google.com:

  1. google.com.NAMESPACE.svc.cluster.local
  2. google.com.svc.cluster.local
  3. google.com.cluster.local
  4. google.com.c.PROJECT_ID.internal
  5. google.com.google.internal
  6. google.com

Chacune des résolutions est effectuée pour IPv4 (enregistrement A) et IPv6 (enregistrement AAAA), ce qui donne lieu à 12 requêtes DNS pour chaque requête non FQDN, ce qui amplifie considérablement le trafic DNS. Pour atténuer ce problème, nous vous recommandons de déclarer le nom d'hôte à rechercher en tant que nom de domaine complet en ajoutant un point final (google.com.). Cette déclaration doit être effectuée au niveau de la charge de travail de l'application. Pour en savoir plus, consultez la page de manuel de resolv.conf.

IPv6

Si le cluster n'utilise pas IPv6, il est possible de réduire de moitié le nombre de requêtes DNS en éliminant la recherche d'enregistrements AAAA sur le serveur DNS en amont. Si vous avez besoin d'aide pour désactiver les recherches AAAA, contactez Cloud Customer Care.

Pool de nœuds dédié

En raison de la nature critique des requêtes DNS dans le cycle de vie des applications, nous vous recommandons d'utiliser des nœuds dédiés pour le déploiement coredns. Ce déploiement relève d'un domaine de défaillance différent de celui des applications normales. Si vous avez besoin d'aide pour configurer des nœuds dédiés pour le déploiement coredns, contactez Cloud Customer Care.

Problèmes d'évolutivité avec MetalLB

MetalLB s'exécute en mode actif-passif, ce qui signifie qu'à tout moment, une seule enceinte MetalLB diffuse une adresse IP virtuelle LoadBalancer spécifique.

Basculement

Avant la version 1.28.0 de GKE sur Bare Metal, à grande échelle, le basculement de MetalLB pouvait prendre beaucoup de temps et présenter un risque de fiabilité pour le cluster.

Limites de connexion

Si une adresse IP virtuelle LoadBalancer particulière, telle qu'un service d'entrée, attend près de 30 000 connexions simultanées, ou plus, il est probable que le nœud de haut-parleur qui gère l'adresse IP virtuelle épuise les ports disponibles. En raison d'une limite d'architecture, MetalLB n'a aucune atténuation pour ce problème. Envisagez de passer à l'équilibrage de charge groupé avec BGP avant de créer le cluster ou d'utiliser une autre classe d'entrée. Pour en savoir plus, consultez la section Configuration de l'entrée.

Haut-parleurs de l'équilibreur de charge

Par défaut, GKE sur Bare Metal utilise le même pool de nœuds de l'équilibreur de charge pour le plan de contrôle et le plan de données. Si vous ne spécifiez pas de pool de nœuds d'équilibreur de charge (loadBalancer.nodePoolSpec), le pool de nœuds du plan de contrôle (controlPlane.nodePoolSpec) est utilisé.

Pour augmenter le nombre de locuteurs lorsque vous utilisez le pool de nœuds du plan de contrôle pour l'équilibrage de charge, vous devez augmenter le nombre de machines du plan de contrôle. Pour les déploiements de production, nous vous recommandons d'utiliser trois nœuds de plan de contrôle pour la haute disponibilité. Augmenter le nombre de nœuds de plan de contrôle au-delà de trois pour accueillir d'autres intervenants peut ne pas être une bonne utilisation de vos ressources.

Configuration de l'Ingress

Si vous prévoyez près de 30 000 connexions simultanées dans une seule adresse IP virtuelle de service LoadBalancer, MetalLB ne sera peut-être pas compatible.

Vous pouvez envisager d'exposer l'adresse IP virtuelle par le biais d'autres mécanismes, tels que F5 BIG-IP. Vous pouvez également créer un cluster en utilisant l'équilibrage de charge groupé avec BGP, qui n'a pas la même limite.

Ajuster les composants Cloud Logging et Cloud Monitoring

Dans les grands clusters, en fonction des profils d'application et du modèle de trafic, les configurations de ressources par défaut pour les composants Cloud Logging et Cloud Monitoring peuvent ne pas être suffisantes. Pour obtenir des instructions sur l'ajustement des demandes et des limites de ressources pour les composants d'observabilité, consultez la page Configurer les ressources des composants Stackdriver.

En particulier, les métriques kube-state-metrics dans les clusters comportant un grand nombre de services et de points de terminaison peuvent entraîner une utilisation excessive de la mémoire à la fois sur le kube-state-metrics lui-même et sur le gke-metrics-agent du même nœud. L'utilisation des ressources de "metrics-server" peut également évoluer en termes de nœuds, de pods et de services. Si vous rencontrez des problèmes de ressources sur ces composants, contactez Cloud Customer Care.

Utiliser sysctl pour configurer votre système d'exploitation

Nous vous recommandons d'ajuster la configuration du système d'exploitation pour vos nœuds afin de l'adapter au cas d'utilisation de votre charge de travail. Les paramètres fs.inotify.max_user_watches et fs.inotify.max_user_instances qui contrôlent le nombre d'inotifier les ressources doivent souvent être ajustés. Par exemple, si vous voyez des messages d'erreur semblables à ce qui suit, vous pouvez essayer de vérifier si ces paramètres doivent être réglés:

The configured user limit (128) on the number of inotify instances has been reached

ENOSPC: System limit for number of file watchers reached...

Le réglage varie généralement selon le type de charge de travail et la configuration matérielle. Vous pouvez consulter les bonnes pratiques spécifiques en matière de système d'exploitation auprès de votre fournisseur de système d'exploitation.

Bonnes pratiques

Cette section décrit les bonnes pratiques à suivre pour faire évoluer votre cluster à la hausse.

Mettre à l'échelle une dimension à la fois

Pour minimiser les problèmes et faciliter le rollback des modifications, n'ajustez pas plus d'une dimension à la fois. La mise à l'échelle simultanée de plusieurs dimensions peut entraîner des problèmes, même dans les clusters plus petits. Par exemple, si vous essayez d'augmenter le nombre de pods programmés par nœud à 110 tout en passant à 250 le nombre de nœuds du cluster, cela risque d'échouer, car le nombre de pods, le nombre de pods par nœud et le nombre de nœuds sont trop étendus.

Effectuer le scaling de clusters par étapes

Le scaling à la hausse d'un cluster peut nécessiter une utilisation intensive des ressources. Pour réduire le risque d'échec des opérations de cluster ou d'interruption des charges de travail des clusters, nous vous déconseillons d'essayer de créer des clusters volumineux avec de nombreux nœuds en une seule opération.

Créer des clusters hybrides ou autonomes sans nœuds de calcul

Si vous créez un cluster hybride ou autonome volumineux comportant plus de 50 nœuds de calcul, il est préférable de créer d'abord un cluster à haute disponibilité avec des nœuds de plan de contrôle, puis d'effectuer un scaling progressif à la hausse. L'opération de création de cluster utilise un cluster d'amorçage, qui n'est pas à haute disponibilité et qui est donc moins fiable. Une fois le cluster hybride ou autonome à haute disponibilité créé, vous pouvez l'utiliser pour effectuer un scaling à la hausse et passer à d'autres nœuds.

Augmenter le nombre de nœuds de calcul par lot

Si vous étendez un cluster à davantage de nœuds de calcul, il est préférable de procéder par étapes. Nous vous recommandons de ne pas ajouter plus de 20 nœuds à la fois. Cela est particulièrement vrai pour les clusters qui exécutent des charges de travail critiques.

Activer l'extraction d'images parallèles

Par défaut, kubelet extrait les images en série, l'une après l'autre. Si la connexion en amont à votre serveur de registre d'images est de mauvaise qualité, une mauvaise extraction d'image peut bloquer toute la file d'attente pour un pool de nœuds donné.

Pour limiter ce problème, nous vous recommandons de définir serializeImagePulls sur false dans la configuration de kubelet personnalisée. Pour obtenir des instructions et plus d'informations, consultez la section Configurer les paramètres d'extraction d'images du kubelet. L'activation de l'extraction d'images parallèles peut entraîner des pics de consommation de bande passante réseau ou d'E/S disque.

Affiner les demandes et les limites de ressources des applications

Dans les environnements denses, les charges de travail des applications peuvent être supprimées. Kubernetes utilise le mécanisme référencé pour classer les pods en cas d'éviction.

Pour paramétrer les ressources de votre conteneur, une bonne pratique consiste à utiliser la même quantité de mémoire pour les demandes et les limites de ressources, ainsi qu'à fixer une limite d'utilisation du processeur plus importante ou indéterminée. Pour en savoir plus, consultez la page Préparer des applications Kubernetes basées sur le cloud dans le Centre d'architecture cloud.

Faire appel à un partenaire de stockage

Pour les déploiements à grande échelle, nous vous recommandons de faire appel à l'un des partenaires de stockage GDCV Ready. Il est important de vérifier les informations suivantes auprès du partenaire de stockage concerné:

  • Les déploiements de stockage respectent les bonnes pratiques concernant les aspects de stockage, tels que la haute disponibilité, les paramètres de priorité, les affinités de nœuds, ainsi que les demandes et limites de ressources.
  • La version de stockage est qualifiée pour la version de GKE sur Bare Metal spécifique.
  • Le fournisseur de stockage peut prendre en charge le déploiement à grande échelle que vous souhaitez déployer.

Configurer les clusters pour la haute disponibilité

Il est important d'auditer votre déploiement à grande échelle et de vous assurer que les composants critiques sont configurés pour la haute disponibilité dans la mesure du possible. GKE sur Bare Metal est compatible avec les options de déploiement haute disponibilité pour tous les types de clusters. Pour en savoir plus, consultez la section Choisir un modèle de déploiement. Pour obtenir des exemples de fichiers de configuration de cluster de déploiements haute disponibilité, consultez la section Exemples de configuration de cluster.

Il est également important d'auditer d'autres composants, y compris:

  • Fournisseur de stockage
  • Webhooks de cluster

Surveiller l'utilisation des ressources

Cette section fournit quelques recommandations de base concernant la surveillance pour les clusters à grande échelle.

Surveiller les métriques d'utilisation de près

Il est essentiel de surveiller l'utilisation des nœuds et des composants système individuels, et de s'assurer qu'ils disposent d'une marge confortable. Pour connaître les fonctionnalités de surveillance standards disponibles par défaut, consultez la section Utiliser des tableaux de bord prédéfinis.

Surveiller la consommation de la bande passante

Surveillez attentivement la consommation de la bande passante pour vous assurer que le réseau n'est pas saturé, ce qui entraîne une dégradation des performances de votre cluster.

Améliorer les performances d'etcd

La vitesse du disque est essentielle à la performance et à la stabilité d'etcd. Un disque lent augmente la latence des requêtes etcd, ce qui peut entraîner des problèmes de stabilité du cluster. Pour améliorer les performances du cluster, GKE sur une solution Bare Metal stocke les objets Event dans une instance etcd dédiée distincte. L'instance etcd standard utilise /var/lib/etcd comme répertoire de données et le port 2379 pour les requêtes client. L'instance etcd-events utilise /var/lib/etcd-events comme répertoire de données et le port 2382 pour les requêtes client.

Nous vous recommandons d'utiliser un disque dur SSD pour vos magasins etcd. Pour des performances optimales, installez des disques distincts sur /var/lib/etcd et /var/lib/etcd-events. L'utilisation de disques dédiés garantit que les deux instances etcd ne partagent pas d'E/S de disque.

La documentation d'etcd fournit des recommandations matérielles supplémentaires pour garantir les meilleures performances d'etcd lors de l'exécution de vos clusters en production.

Pour vérifier les performances de votre etcd et de votre disque, utilisez les métriques de latence des E/S etcd suivantes dans l'explorateur de métriques :

  • etcd_disk_backend_commit_duration_seconds : la durée doit être inférieure à 25 millisecondes pour le 99e centile (p99).
  • etcd_disk_wal_fsync_duration_seconds : la durée doit être inférieure à 10 millisecondes pour le 99e centile (p99).

Pour en savoir plus sur les performances d'etcd, consultez Que signifie l'avertissement d'etcd "L'application des entrées a pris trop de temps" et Que signifie l'avertissement etcd "échec d'envoyer la pulsation à l'heure" ?.

Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.

Étape suivante