Faire évoluer les clusters Google Distributed Cloud

Comme tout cluster Kubernetes, l'évolutivité du cluster Google Distributed Cloud comporte de nombreuses dimensions interdépendantes. Ce document vise à vous aider à comprendre les principales dimensions que vous pouvez ajuster pour faire évoluer vos clusters sans perturber vos charges de travail.

Comprendre les limites

Google Distributed Cloud est un système complexe, doté d'une grande surface d'intégration. De nombreuses dimensions affectent l'évolutivité des clusters. Par exemple, le nombre de nœuds ne représente que l'un des nombreux aspects sur lesquels Google Distributed Cloud peut évoluer. Les autres dimensions incluent le nombre total de pods et de services. Bon nombre de ces dimensions, comme le nombre de pods par nœud et le nombre de nœuds par cluster, sont interdépendantes. Pour en savoir plus sur les dimensions qui ont un impact sur l'évolutivité, consultez les seuils d'évolutivité de Kubernetes dans la section du groupe d'intérêt spécial (SIG) sur l'évolutivité du dépôt de la communauté Kubernetes sur GitHub.

Les limites d'évolutivité sont également sensibles à la configuration du matériel et des nœuds sur lesquels votre cluster s'exécute. Les limites décrites dans ce document sont validées dans un environnement qui est très probablement différent du vôtre. Par conséquent, vous ne pourrez peut-être pas reproduire les mêmes chiffres lorsque l'environnement sous-jacent constitue le facteur limitant.

Pour en savoir plus sur les limites qui s'appliquent à vos clusters Google Distributed Cloud, consultez la page Quotas et limites.

Préparer l'évolutivité

Lorsque vous préparez le scaling de vos clusters Google Distributed Cloud, 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 du plan de contrôle des clusters exécutant des charges de travail de production :

Nombre de nœuds de cluster CPU du plan de contrôle recommandés 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 du pod 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 limitants de l'extension de votre cluster. Ce paramètre, associé au paramètre de nombre maximal de pods par nœud, 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é avec clusterNetwork.pods.cidrBlocks, qui utilise une plage d'adresses IP spécifiée au format CIDR. Par exemple, la valeur préremplie 192.168.0.0/16 spécifie une plage de 65 536 adresses IP, de 192.168.0.0 à 192.168.255.255.

  • Le nombre maximal de pods pouvant être exécutés sur un même nœud est spécifié avec nodeConfig.podDensity.maxPodsPerNode.

  • En fonction du paramètre du nombre maximal de pods par nœud, Google Distributed Cloud provisionne environ deux fois plus d'adresses IP sur le nœud. Les adresses IP supplémentaires permettent d'éviter la réutilisation involontaire des adresses IP des pods sur une courte période.

  • En divisant le nombre total d'adresses IP de pod par le nombre d'adresses IP de pod provisionnées sur chaque nœud, vous obtenez 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, Google Distributed Cloud provisionne une plage d'environ 500 adresses IP, ce qui équivaut à peu près à un bloc CIDR /23 (2(32-23) = 29 = 512). Le nombre maximal de nœuds dans ce cas est donc de 64 (215 adresses/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 sont immuables. Planifiez donc soigneusement la croissance future de votre cluster pour éviter de manquer de capacité sur les 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 en fonction des tests, consultez la section Limites.

CIDR des services

Vous pouvez mettre à jour le CIDR de votre service pour ajouter d'autres services à mesure que vous faites évoluer votre cluster. Vous ne pouvez toutefois pas réduire la plage CIDR du service. Pour en savoir plus, consultez la section Augmenter la portée du réseau de services.

Ressources réservées aux daemons système

Par défaut, Google Distributed Cloud réserve automatiquement des ressources sur un nœud pour les démons 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, Google Distributed Cloud réserve 80 millicores de processeur (80 mCPU) et 280 mégaoctets (280 Mio) de mémoire sur chaque nœud pour les daemons système. Notez que l'unité de processeur mCPU correspond à un millième de cœur. Par conséquent, 80/1 000 ou 8 % d'un cœur sur chaque nœud est réservé aux démons système. La quantité de ressources réservées est faible et n'a pas d'impact significatif sur les performances du pod. Toutefois, le kubelet sur un nœud peut expulser 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

Vous pouvez augmenter le nombre de speakers MetalLB pour résoudre les aspects suivants :

  • Bande passante : la bande passante totale du cluster pour les services d'équilibrage de charge dépend du nombre de nœuds de diffusion et de la bande passante de chaque nœud de speaker. Un trafic réseau plus important nécessite davantage de speakers.

  • Tolérance aux pannes : plus il y a de speakers, moins l'impact global d'une défaillance d'un seul speaker est important.

MetalLB nécessite des connectivités 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 sur lesquels vous pouvez placer des speakers MetalLB.

Prévoyez soigneusement le nombre de speakers 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 section 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 sur le même réseau de couche 2. L'équilibrage de charge manuel ne présente pas cette restriction. Pour en savoir plus, consultez la section Mode d'équilibrage de charge manuel.

Exécuter de nombreux nœuds, pods et services

Ajouter des nœuds, des pods et des services permet de faire évoluer votre cluster. Les sections suivantes décrivent certains 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 leur relation les unes avec les autres, consultez la section Limites.

Créer un cluster sans kube-proxy

Pour créer un cluster hautes performances pouvant évoluer pour 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 gérer 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 configurée 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 de CoreDNS

Cette section décrit les aspects de CoreDNS qui ont une incidence sur la scalabilité de vos clusters.

DNS du pod

Par défaut, les clusters Google Distributed Cloud injectent des pods avec un resolv.conf semblable à l'exemple suivant :

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 des noms de domaine complets (FQDN). Le serveur DNS ajoute tous les domaines de recherche spécifiés avant de rechercher le nom d'hôte demandé à l'origine, ce qui permet de classer 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 recherches est effectuée pour IPv4 (enregistrement A) et IPv6 (enregistrement AAAA), ce qui génère 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 à la fin (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é les requêtes DNS en éliminant la recherche d'enregistrement 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 les cycles 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 d'échec 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é de MetalLB

MetalLB s'exécute en mode actif-passif, ce qui signifie qu'à un moment donné, il n'y a qu'un seul speaker MetalLB qui sert une adresse IP virtuelle LoadBalancer particulière.

Basculement

Avant la version 1.28.0 de Google Distributed Cloud, à 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, tel qu'un service Ingress, attend près de 30 000 connexions simultanées ou plus, il est probable que le nœud de speaker qui gère l'adresse IP virtuelle épuise les ports disponibles. En raison d'une limite d'architecture, MetalLB ne peut pas atténuer ce problème. Envisagez de passer à l'équilibrage de charge groupé avec BGP avant de créer un cluster ou d'utiliser une autre classe d'entrée. Pour en savoir plus, consultez la page Configuration d'entrée.

Speakers de l'équilibreur de charge

Par défaut, Google Distributed Cloud utilise le même pool de nœuds d'équilibrage 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 speakers 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 une haute disponibilité. Augmenter le nombre de nœuds du plan de contrôle au-delà de trois pour accueillir des speakers supplémentaires n'est pas forcément une bonne manière d'utiliser vos ressources.

Configuration d'Ingress

Si vous prévoyez près de 30 000 connexions simultanées vers une seule adresse IP virtuelle de service LoadBalancer, il est possible que MetalLB ne soit pas en mesure de les gérer.

Vous pouvez envisager d'exposer l'IP virtuelle via d'autres mécanismes, tels que F5 BIG-IP. Vous pouvez également créer un cluster à l'aide de l'équilibrage de charge groupé avec BGP, qui ne présente pas la même limitation.

Ajuster les composants Cloud Logging et Cloud Monitoring

Dans les grands clusters, selon les profils d'application et le schéma de trafic, les configurations de ressources par défaut des composants Cloud Logging et Cloud Monitoring peuvent ne pas être suffisantes. Pour savoir comment ajuster les demandes et limites de ressources pour les composants d'observabilité, consultez la section Configurer les ressources des composants Stackdriver.

En particulier, kube-state-metrics dans les clusters avec un grand nombre de services et de points de terminaison peut 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 sur le 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 de vos nœuds pour qu'elle corresponde au mieux à votre cas d'utilisation de la charge de travail. Les paramètres fs.inotify.max_user_watches et fs.inotify.max_user_instances qui contrôlent le nombre de ressources inotify doivent souvent être affinés. Par exemple, si vous voyez des messages d'erreur comme celui-ci, vous pouvez essayer de voir si ces paramètres doivent être ajustés :

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

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

L'ajustement varie généralement en fonction des types de charges de travail et de la configuration matérielle. Vous pouvez consulter les bonnes pratiques spécifiques à l'OS auprès de votre fournisseur.

Bonnes pratiques

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

Écheller une dimension à la fois

Pour minimiser les problèmes et faciliter l'annulation des modifications, n'ajustez pas plusieurs dimensions à la fois. L'ajustement simultané de plusieurs dimensions peut entraîner des problèmes, même au sein de clusters plus petits. Par exemple, si vous essayez d'augmenter le nombre de pods planifiés par nœud à 110 tout en augmentant le nombre de nœuds du cluster à 250, cette opération ne fonctionnera probablement pas, car le nombre de pods, le nombre de pods par nœud et le nombre de nœuds seront trop étendus.

Faire évoluer progressivement les clusters

L'ajustement à la hausse d'un cluster peut être gourmand en ressources. Pour réduire le risque de défaillance des opérations de cluster ou de perturbation des charges de travail de cluster, nous vous déconseillons de tenter de créer de grands clusters 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 grand cluster hybride ou autonome avec plus de 50 nœuds de calcul, il est préférable de créer d'abord un cluster à haute disponibilité (HD) avec des nœuds de plan de contrôle, puis d'augmenter progressivement la capacité. L'opération de création de cluster utilise un cluster d'amorçage, qui n'est pas haute disponibilité et est donc moins fiable. Une fois le cluster hybride ou autonome à haute disponibilité créé, vous pouvez l'utiliser pour augmenter le nombre de 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 le faire 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 les extractions d'images en parallèle

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

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

Ajuster les demandes et les limites de ressources de l'application

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 Préparer des applications Kubernetes basées sur le cloud dans Cloud Architecture Center.

Utiliser un partenaire de stockage

Nous vous recommandons d'utiliser l'un des partenaires de stockage GDC Ready pour les déploiements à grande échelle. Il est important de confirmer les informations suivantes auprès du partenaire de stockage concerné:

  • Les déploiements de stockage suivent les bonnes pratiques concernant les aspects de stockage, tels que la haute disponibilité, le paramétrage des priorités, les affinités de nœuds, ainsi que les demandes et les limites de ressources.
  • La version de stockage est qualifiée par la version spécifique de Google Distributed Cloud.
  • Le fournisseur de stockage peut prendre en charge l'échelle élevée que vous souhaitez déployer.

Configurer des 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. Google Distributed Cloud accepte les options de déploiement HD 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 HD, 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 des recommandations de base pour la surveillance des clusters à grande échelle.

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

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 de sécurité confortable. Pour connaître les fonctionnalités de surveillance standards disponibles par défaut, consultez Utiliser des tableaux de bord prédéfinis.

Surveiller la consommation de bande passante

Surveillez de près la consommation de bande passante pour vous assurer que le réseau n'est pas saturé, ce qui entraînerait 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, Google Distributed Cloud stocke les objets Événement dans une instance etcd distincte et dédiée. 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 espaces de stockage 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 les E/S sur disque.

La documentation d'etcd fournit des recommandations matérielles supplémentaires pour garantir les meilleures performances 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 de l'etcd, consultez les pages Que signifie l'avertissement etcd "Appliquer les entrées a pris trop de temps" ? et Que signifie l'avertissement etcd "Échec de l'envoi de pulsations dans les temps" ?.

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

Vous pouvez également consulter la page Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris les suivantes:

  • Conditions requises pour ouvrir une demande d'assistance.
  • Des outils pour vous aider à résoudre les problèmes, tels que la configuration de votre environnement, les journaux et les métriques.
  • Composants compatibles.

Étape suivante