Évolutivité

Cette page décrit les bonnes pratiques à employer pour la création, la configuration et l'exploitation de clusters Anthos clusters on VMware (GKE On-Prem) afin de gérer les charges de travail qui approchent des limites d'évolutivité Kubernetes.

Limites d'évolutivité

Tenez compte des limites suivantes lorsque vous concevez vos applications sur Anthos clusters on VMware :

Comprendre les limites

Étant donné que'Anthos clusters on VMware est un système complexe avec une grande surface d'intégration, l'évolutivité des clusters implique de nombreuses dimensions inter-connectées. Par exemple, Anthos clusters on VMware peut évoluer en termes de nombre de nœuds, de pods ou de services. Le développement simultané de plusieurs dimensions peut entraîner des problèmes, même au sein des clusters plus petits. Par exemple, si vous planifiez 110 pods par nœud dans un cluster de 500 nœuds, vous pouvez excéder le seuil de pods, de pods par nœud et de nœuds.

Pour plus d'informations, consultez la page Seuils d'évolutivité de Kubernetes.

Les limites d'évolutivité sont également sensibles à la configuration et au matériel vSphere d'exécution de votre cluster. Ces limites sont validées dans un environnement qui est très probablement différent du vôtre. Par conséquent, vous ne pouvez pas reproduire les chiffres exacts lorsque l'environnement sous-jacent constitue le facteur limitant.

Préparer l'évolutivité

Lorsque vous préparez le scaling de vos clusters d'administrateur ou de vos clusters d'utilisateurs, tenez compte des exigences et limitations suivantes.

Exigences concernant le processeur, la mémoire et le stockage

Consultez la page Exigences concernant le processeur, la RAM et l'espace de stockage pour chaque VM.

Exigences concernant les E/S du disque et du réseau

Les charges de travail qui consomment beaucoup de données et certains composants du plan de contrôle sont sensibles à la latence des E/S du disque et du réseau. Par exemple, 500 IOPS séquentielles (par exemple, un disque SSD local classique ou un appareil de stockage en mode bloc virtualisé hautes performances) sont généralement nécessaires pour améliorer les performances et la stabilité d'etcd dans un cluster comportant des dizaines de nœuds et des milliers de pods.

Adresse IP du nœud

Chaque nœud Anthos clusters on VMware nécessite une adresse IP DHCP ou attribuée de manière statique.

Par exemple, 308 adresses IP sont nécessaires dans une configuration avec un cluster d'utilisateur standard comportant 50 nœuds et un cluster d'utilisateur haute disponibilité comportant 250 nœuds.

Le tableau suivant montre la répartition des adresses IP :

Type de nœud Nombre d'adresses IP
VM du plan de contrôle pour le cluster d'administrateur 1
VM de nœuds supplémentaires pour le cluster d'administrateur 3
VM du plan de contrôle pour le cluster d'utilisateur 1 (standard) 1
VM de nœuds pour le cluster d'utilisateur 1 50
VM du plan de contrôle pour le cluster d'utilisateur 2 (haute disponibilité) 3
VM de nœuds pour le cluster d'utilisateur 2 250
Total 308

Exécuter de nombreux clusters d'utilisateurs dans un cluster d'administrateur

Pour préparer l'exécution de nombreux clusters d'utilisateurs dans un cluster d'administrateur, procédez comme suit lors de la création du cluster d'administrateur :

Bloc CIDR de pod dans le cluster d'administrateur

Le bloc CIDR du pod est le bloc CIDR pour tous les pods d'un cluster d'administrateur. Il est configuré via le champ network.podCIDR de admin-cluster.yaml.

À partir de cette plage, des blocs /24 plus petits sont attribués à chaque nœud. Si vous avez besoin d'un cluster d'administrateur à N nœuds, vous devez vous assurer que ce bloc est suffisamment grand pour accepter N/24 blocs.

Le tableau suivant décrit le nombre maximal de nœuds compatibles avec différentes tailles de blocs CIDR de pods :

Taille du bloc CIDR des pods Nombre maximal de nœuds compatibles
/18 64
/17 128
/16 256
/15 512

Le bloc CIDR de pod par défaut d'un cluster d'administrateur est 192.168.0.0/16, qui accepte 256 nœuds.

Dans un cluster d'administrateur comportant 50 clusters d'utilisateur haute disponibilité (chaque cluster utilisateur dispose de trois nœuds de plan de contrôle), vous disposez d'un nœud de plan de contrôle de cluster d'administrateur, de deux nœuds de modules complémentaires de cluster d'administrateur et de 150 nœuds de plan de contrôle de cluster utilisateur. Le nombre total de nœuds est inférieur à 256. Par conséquent, le bloc CIDR par défaut du pod peut accepter jusqu'à 50 clusters d'utilisateur haute disponibilité.

Bloc CIDR de service dans le cluster administrateur

Le bloc CIDR de service est le bloc CIDR pour tous les services d'un cluster d'administrateur. Il est configuré via le champ network.serviceCIDR du fichier admin-cluster.yaml.

Le tableau suivant décrit le nombre maximal de services compatibles avec différentes tailles de bloc CIDR de services :

Taille du bloc CIDR des services Nombre maximal de services compatibles
/24 256
/23 512
/22 1 024

La valeur par défaut est 10.96.232.0/24, compatible avec 256 services.

Chaque cluster d'utilisateur utilise cinq services, tandis que le plan de contrôle du cluster administrateur utilise 13 services. Par conséquent, pour exécuter 50 clusters d'utilisateur, vous devez modifier le bloc CIDR de service dans le cluster administrateur pour utiliser une plage /23.

Cloud Logging et Cloud Monitoring

Cloud Logging et Cloud Monitoring vous aident à effectuer le suivi de vos ressources.

L'utilisation du processeur et de la mémoire des composants Cloud Logging et Cloud Monitoring déployés dans un cluster d'administrateur évolue en fonction du nombre de clusters d'utilisateur.

Le tableau suivant indique le nombre de processeurs et la quantité de mémoire du nœud de cluster d'administrateur nécessaires à l'exécution d'un grand nombre de clusters d'utilisateur :

Nombre de clusters d'utilisateurs Processeur du nœud de cluster d'administrateur Mémoire du nœud de cluster d'administrateur
Entre 0 et 10 4 processeurs 16 Go
Entre 11 et 20 4 processeurs 32 Go
Entre 20 et 50 4 processeurs 90 Go

Par exemple, s'il existe 2 nœuds de cluster d'administrateur, chacun comportant quatre processeurs et 16 Go de mémoire, vous pouvez exécuter entre 0 et 10 clusters d'utilisateur. Pour créer plus de 20 clusters d'utilisateur, vous devez d'abord redimensionner la mémoire du nœud de cluster d'administrateur de 16 Go à 90 Go.

Pour modifier la mémoire du nœud de module complémentaire du cluster d'administrateur, modifiez la configuration MachineDeployment :

  1. Exécutez la commande suivante :

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG edit machinedeployment gke-admin-node

    Où ADMIN_CLUSTER_KUBECONFIG représente le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

  2. Définissez le champ spec.template.spec.providerSpec.value.machineVariables.memory sur 32768.

  3. Enregistrez la modification. Les nœuds du cluster d'administrateur sont recréés avec une quantité de mémoire de 32 Go.

GKE Hub

Par défaut, vous pouvez enregistrer 15 clusters d'utilisateur au maximum. Si vous souhaitez enregistrer davantage de clusters dans GKE Hub, vous pouvez demander une augmentation de quota dans la console Google Cloud.

Exécuter de nombreux nœuds et pods dans un cluster d'utilisateur

Lorsque vous vous apprêtez à exécuter plusieurs nœuds et pods dans un cluster d'utilisateur, procédez comme suit lors de la création de ce cluster.

Bloc CIDR de pod dans le cluster utilisateur

Il s'agit du bloc CIDR de tous les pods d'un cluster d'utilisateur. Il est configuré via le champ network.podCIDR de user-cluster.yaml.

Dans cette plage, un bloc /24 plus petit est attribué à chaque nœud. Si vous avez besoin d'un cluster à N nœuds, vous devez vous assurer que ce bloc est suffisamment grand pour accepter N/24 blocs.

Le tableau suivant décrit le nombre maximal de nœuds compatibles avec différentes tailles de blocs CIDR de pods :

Taille du bloc CIDR des pods Nombre maximal de nœuds compatibles
/18 64
/17 128
/16 256
/15 512

Le bloc CIDR des pods par défaut est 192.168.0.0/16, compatible avec 256 nœuds. Par exemple, pour créer un cluster comportant 500 nœuds, vous devez modifier le bloc CIDR du pod dans le cluster utilisateur afin d'utiliser une plage /15.

Bloc CIDR de service dans le cluster utilisateur

Le bloc CIDR de service est le bloc CIDR de tous les services d'un cluster d'utilisateur. Il est configuré via le champ network.serviceCIDR du fichier user-cluster.yaml.

Le tableau suivant décrit le nombre maximal de services compatibles avec différentes tailles de bloc CIDR de services :

Taille du bloc CIDR des services Nombre maximal de services compatibles
/21 2 048
/20 4 096
/19 8 192
/18 16 384

La valeur par défaut est 10.96.0.0/20, compatible avec 4 096 services. Le bloc CIDR de service par défaut vous permet de créer un cluster avec 500 services, soit le nombre maximal de services de type LoadBalancer que Anthos clusters on VMware accepte sur un cluster utilisateur.

Nœuds du plan de contrôle du cluster d'utilisateur

L'utilisation de la mémoire des composants du plan de contrôle du cluster d'utilisateur évolue en fonction du nombre de nœuds du cluster d'utilisateur.

Le tableau suivant indique le nombre de processeurs et la quantité de mémoire du nœud de cluster d'administrateur nécessaires à l'exécution d'un grand nombre de clusters d'utilisateur :

Nombre de nœuds Processeur du nœud du plan de contrôle du cluster d'utilisateur Mémoire du nœud du plan de contrôle du cluster utilisateur
Entre 0 et 250 4 processeurs 8 Go
Entre 250 et 500 4 processeurs 16 Go

Par exemple, pour créer plus de 250 nœuds dans un cluster d'utilisateur, vous devez utiliser des nœuds du plan de contrôle du cluster utilisateur avec au moins 16 Go de mémoire.

Les spécifications du nœud du plan de contrôle du cluster utilisateur peuvent être modifiées via le champ masterNode de user-cluster.yaml.

Dataplane V2

Pour les clusters d'utilisateur de 500 nœuds utilisant Dataplane V2, nous recommandons 120 Go de mémoire et 32 cœurs de processeur pour les nœuds du plan de contrôle du cluster utilisateur.

Cloud Logging et Cloud Monitoring

Cloud Logging et Cloud Monitoring vous aident à effectuer le suivi de vos ressources.

L'utilisation du processeur et de la mémoire des agents au sein du cluster déployés dans un cluster d'utilisateur évolue en fonction du nombre de nœuds et de pods d'un cluster d'utilisateur.

Les composants Cloud Logging et Cloud Monitoring, tels que prometheus-server et stackdriver-prometheus-sidecar ont une utilisation différente des ressources mémoire et de processeur en fonction du nombre de nœuds et de pods. Avant de faire évoluer votre cluster à la hausse, définissez les demandes et limites de ressources en fonction de l'utilisation moyenne estimée de ces composants. Le tableau suivant présente l'utilisation moyenne estimée de chaque composant :

Nombre de nœuds Nom du conteneur Utilisation estimée du processeur Utilisation estimée de la mémoire
0 pod/nœud 30 pods/nœud 0 pod/nœud 30 pods/nœud
Entre 3 et 50 prometheus-server 100 m 390 m 650M 1.3G
stackdriver-prometheus-sidecar 100 m 340 m 1.5G 1.6G
Entre 51 et 100 prometheus-server 160 m 500 m 1.8G 5.5G
stackdriver-prometheus-sidecar 200 m 500 m 1.9G 5.7G
Entre 101 et 250 prometheus-server 400 m 2 500 m 6.5G 16G
stackdriver-prometheus-sidecar 400 m 1 300 m 7.5G 12G
Entre 250 et 500 prometheus-server 1 200 m 2 600ám 22G 25G
stackdriver-prometheus-sidecar 400 m 2 250 m 65G 78G

Assurez-vous de disposer d'un nombre de nœuds suffisant pour planifier les composants Cloud Logging et Cloud Monitoring. Pour ce faire, vous devez d'abord créer un petit cluster, modifier les ressources des composants Cloud Logging et Cloud Monitoring conformément aux informations du tableau ci-dessus, créer un pool de nœuds pour prendre en charge les composants, puis faire évoluer progressivement le cluster à la hausse.

Vous pouvez choisir de maintenir un pool de nœuds juste assez grand pour les composants Cloud Logging et Cloud Monitoring afin d'éviter que d'autres pods ne soient planifiés dans le pool de nœuds. Pour ce faire, vous devez ajouter les rejets suivants au pool de nœuds :

taints:
  - effect: NoSchedule
    key: node-role.gke.io/observability

Cela évite que d'autres composants ne soient planifiés sur le pool de nœuds et empêche que les charges de travail d'utilisateur ne soient éliminées en raison de la consommation des ressources des composants Cloud Monitoring.

Équilibreur de charge

Les services décrits dans cette section font référence aux services Kubernetes avec le type LoadBalancer.

Il existe une limite sur le nombre de nœuds de cluster et de services que vous pouvez configurer sur votre équilibreur de charge.

Pour l'équilibrage de charge groupé (Seesaw), il existe également une limite sur le nombre de vérifications de l'état. Le nombre de vérifications de l'état dépend du nombre de nœuds et du nombre de services locaux de trafic. Un service local de trafic est un service dont le paramètre externalTrafficPolicy est défini sur Local.

Le tableau suivant décrit le nombre maximal de services, de nœuds et de vérifications de l'état pour l'équilibrage de charge groupé (Seesaw) et l'équilibrage de charge intégré (F5) :

Équilibrage de charge groupé (Seesaw) Équilibrage de charge intégré (F5)
Nombre maximal de services 500 2502
Nombre maximal de nœuds 500 2502
Nombre maximal de vérifications d'état N + (L * N) <= 10 000, où N correspond au nombre de nœuds et L correspond au nombre de services locaux de trafic1 N/A2

1 Par exemple, supposons que vous ayez 100 nœuds et 99 services locaux de trafic. Dans ce cas, le nombre de vérifications de l'état est de 100 + (99 * 100) = 10 000, ce qui correspond à la limite de 10 000.

2 Pour en savoir plus, consultez la documentation de F5. Ce nombre est influencé par des facteurs tels que votre numéro de modèle matériel F5, le processeur/la mémoire de votre instance virtuelle et vos licences.

Effectuer un autoscaling pour les composants système

Anthos clusters on VMware adapte automatiquement les composants système du cluster utilisateur en fonction du nombre de nœuds, sans qu'il soit nécessaire de modifier les configurations. Vous pouvez utiliser les informations de cette section pour planifier vos ressources.

  • Anthos clusters on VMware effectue automatiquement un scaling vertical en mettant à l'échelle les requêtes et les limitations de mémoire et de processeur des composants système suivants à l'aide de addon-resizer :

    • kube-state-metrics est un déploiement exécuté sur des nœuds de calcul de cluster qui écoute le serveur d'API Kubernetes et génère des métriques sur l'état des objets. Les demandes et limites de ressources mémoire et de processeur évoluent en fonction du nombre de nœuds.

      Le tableau suivant décrit les demandes/limites de ressources définies par le système en fonction du nombre de nœuds dans un cluster :

      Nombre de nœuds Demande/limite de ressources de processeur (millicores) approximative1 Demande/limite de ressources mémoire (mébioctets) approximative1
      Entre 3 et 5 105 110
      Entre 6 et 500 100 + num_nodes (nombre de nœuds) 100 + (2 * num_nodes (nombre de nœuds)

      1 Il existe une marge de plus ou moins 5 % pour réduire le nombre de redémarrages du composant lors du scaling.

      Par exemple, dans un cluster comportant 50 nœuds, la demande/limite de ressources de processeur est définie sur 150 m/150 m, et la requête/limite de mémoire est définie sur 200 Mio/200 Mio. Dans un cluster comportant 250 nœuds, la demande/limite de ressources de processeur est définie sur 350 m/350 m, et la demande/limite de ressources mémoire est définie sur 600 Mio.

    • metrics-server est un déploiement exécuté sur des nœuds de calcul de cluster qui est utilisé par les pipelines d'autoscaling intégrés à Kubernetes. Les demandes et limites de ressources mémoire et de processeur évoluent en fonction du nombre de nœuds.

  • Anthos clusters on VMware effectue automatiquement un scaling horizontal dans les clusters d'administrateur et les clusters d'utilisateurs en ajustant le nombre d'instances dupliquées des composants système suivants :

    • kube-dns est la solution DNS utilisée pour la détection de services dans Anthos clusters on VMware. Elle s'exécute en tant que déploiement sur les nœuds de calcul de cluster d'utilisateur. Anthos clusters on VMware adapte automatiquement le nombre d'instances dupliquées en fonction du nombre de nœuds et de cœurs de processeur du cluster. À chaque ajout/suppression de 16 nœuds ou de 256 cœurs, une instance dupliquée est augmentée/réduite. Si vous disposez d'un cluster de N nœuds et C cœurs, vous pouvez vous attendre à max(N/16, C/256) d'instances dupliquées. Notez que kube-dns accepte 1 500 requêtes simultanées par seconde.

    • calico-typha est un composant permettant la compatibilité des pods dans Anthos clusters on VMware. Elle s'exécute en tant que déploiement sur les nœuds de calcul de cluster d'utilisateur. Anthos clusters on VMware adapte automatiquement le nombre d'instances dupliquées calico-typha en fonction du nombre de nœuds du cluster :

      Nombre de nœuds (N) Nombre d'instances dupliquées calico-typha
      N = 1 1
      1 < N < 200 2
      N >= 200 3 ou plus

    • ingress-gateway/istio-pilot sont les composants qui rendent les entrées de cluster possibles. Ils s'exécutent en tant que déploiement sur les nœuds de calcul de cluster d'utilisateur. Selon la quantité de trafic que la passerelle d'entrée gère, Anthos clusters on VMware utilise l'autoscaler horizontal de pods pour faire évoluer le nombre d'instances dupliquées en fonction de l'utilisation du processeur (deux instances dupliquées minimum et cinq instances dupliquées maximum).

Bonnes pratiques

Cette section décrit les bonnes pratiques relatives au scaling de vos ressources.

Faire évoluer progressivement le cluster

La création d'un nœud Kubernetes implique de cloner le modèle d'image de l'OS du nœud dans un nouveau fichier de disque, ce qui constitue une opération vSphere nécessitant beaucoup d'E/S. Il n'y a pas de séparation d'E/S entre l'opération de clonage et les opérations d'E/S de vos charges de travail. Si trop de nœuds sont créés en même temps, les opérations de clonage prennent beaucoup de temps et peuvent affecter les performances et la stabilité du cluster et des charges de travail existantes.

Assurez-vous de faire évoluer progressivement le cluster en fonction de vos ressources vSphere. Par exemple, pour redimensionner un cluster de 3 à 500 nœuds, envisagez de le redimensionner par étapes de 150 à 350 à 500, ce qui permet de réduire la charge sur l'infrastructure vSphere.

Optimiser les performances d'E/S disque d'etcd

etcd est un espace de stockage de paires clé/valeur utilisé comme espace de stockage de secours de Kubernetes pour toutes les données de cluster. Ses performances et sa stabilité sont essentielles pour maintenir l'état d'un cluster, et sont sensibles à la latence des E/S du disque et du réseau.

  • Optimisez les performances d'E/S du datastore vSphere utilisé pour les VM du plan de contrôle en suivant les recommandations suivantes :

  • Une latence de quelques centaines de millisecondes indique un goulot d'étranglement sur les E/S du disque ou du réseau, et peut entraîner une défaillance de cluster. Surveillez et définissez les seuils d'alertes pour les métriques de latence des E/S suivantes :

    • etcd_disk_backend_commit_duration_seconds
    • etcd_disk_wal_fsync_duration_seconds

Optimiser les performances d'E/S du disque de démarrage des nœuds

Les pods stockent leurs opérations internes de manière éphémère (en enregistrant des fichiers temporaires, par exemple). Le stockage éphémère est utilisé par la couche accessible en écriture, le répertoire des journaux et les volumes emptyDir du conteneur. Le stockage éphémère provient du système de fichiers de nœud d'Anthos clusters on VMware, qui est sauvegardé par le disque de démarrage du nœud.

Comme il n'y a pas de séparation d'E/S de stockage sur les nœuds Kubernetes, les applications qui consomment des E/S très élevées sur leur espace de stockage éphémère peuvent potentiellement entraîner une instabilité des nœuds en privant les composants système, tels que Kubelet et le daemon Docker, de ressources.

Assurez-vous que les caractéristiques de performances d'E/S du datastore sur lequel les disques de démarrage sont provisionnés peuvent fournir les performances appropriées pour l'utilisation du stockage éphémère et du trafic de journalisation par l'application.

Surveiller les conflits de ressources physiques

Veuillez prendre en compte les ratios processeurs virtuel/physique et la sursollicitation de la mémoire. Un ratio ou un conflit de mémoire non optimaux sur les hôtes physiques peut dégrader les performances de la VM. Vous devez surveiller l'utilisation des ressources physiques au niveau de l'hôte et allouer suffisamment de ressources pour exécuter vos clusters volumineux.