Version 1.6. Cette version n'est plus compatible, comme indiqué dans la politique de compatibilité avec les versions d'Anthos. Pour obtenir les derniers correctifs et mises à jour pour les failles de sécurité, les expositions et les problèmes affectant Anthos Clusters on VMware (GKE On-Prem), passez à une version compatible. Vous trouverez la version la plus récente ici.

Évolutivité

Cette page décrit les bonnes pratiques 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 :

  • Chaque cluster d'administrateur accepte jusqu'à 20 clusters d'utilisateur (haute disponibilité et standards).

  • Chaque cluster d'utilisateur accepte jusqu'à :

  • Vous pouvez créer 110 pods par nœud au maximum (chaque pod peut comporter un à deux conteneurs). Cela inclut les pods exécutant des services système complémentaires.

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 250 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 vous préparez à effectuer un scaling, tenez compte des exigences et des limites concernant l'infrastructure vSphere, la mise en réseau Kubernetes, GKE Hub, Cloud Logging et Cloud Monitoring.

Infrastructure vSphere

Cette section traite des exigences à connaître concernant le processeur, la mémoire, l'espace de stockage, les E/S du disque et du réseau, et les adresses IP des nœuds en cas de scaling.

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

Les exigences suivantes s'appliquent aux VM du plan de contrôle :

  • Le plan de contrôle et les nœuds supplémentaires du cluster d'administrateur peuvent accepter jusqu'à 20 clusters d'utilisateur (haute disponibilité et standards). Par conséquent, aucun réglage n'est requis sur le cluster d'administrateur.

  • La configuration par défaut de la VM du plan de contrôle pour le cluster d'utilisateur (4 processeurs, 8 Go de mémoire et 40 Go d'espace de stockage) est la configuration minimale requise pour exécuter jusqu'à 250 nœuds dans un cluster d'utilisateur.

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

Mise en réseau Kubernetes

Cette section traite des exigences à connaître concernant le bloc CIDR des pods et les services Kubernetes en cas de scaling.

Bloc CIDR des pods

Il s'agit du bloc CIDR de tous les pods d'un cluster d'utilisateur. À partir de cette plage, des blocs /24 plus petits sont attribués à 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
/19 32
/18 64
/17 128
/16 256

Le bloc CIDR des pods par défaut est 192.168.0.0/16, compatible avec 256 nœuds. Le bloc CIDR par défaut des pods vous permet de créer un cluster avec 250 nœuds, ce qui correspond au nombre maximal de nœuds acceptés par Anthos clusters on VMware dans un cluster d'utilisateur.

Services Kubernetes

Cette section traite des exigences à connaître concernant le bloc CIDR des services et l'équilibreur de charge en cas de scaling.

Bloc CIDR des services

Le bloc CIDR de service est le bloc CIDR de tous les services d'un cluster d'utilisateur. Les services décrits dans cette section font référence aux services Kubernetes avec le type LoadBalancer.

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
/20 4 096
/19 8 192
/18 16 384

La valeur par défaut est 10.96.0.0/12, compatible avec 1 048 576 services. Le bloc CIDR par défaut des services vous permet de créer un cluster avec 500 services, ce qui correspond au nombre maximal de services acceptés par Anthos clusters on VMware dans un cluster d'utilisateur.

Équilibreur de charge

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 250 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.

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 effectuer une demande d'augmentation de quota dans Cloud Console.

Cloud Logging et Cloud Monitoring

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

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

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, stackdriver-prometheus-sidecar et stackdriver-log-aggregator, 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, 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 stackdriver-log-aggregator 150 m 170 m 1.6G 1.7G
prometheus-server 100 m 390 m 650M 1.3G
stackdriver-prometheus-sidecar 100 m 340 m 1.5G 1.6G
Entre 51 et 100 stackdriver-log-aggregator 220 m 1 100 m 1.6G 1.8G
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 stackdriver-log-aggregator 450 m 1 800 m 1.7G 1.9G
prometheus-server 400 m 2 500 m 6.5G 16G
stackdriver-prometheus-sidecar 400 m 1 300 m 7.5G 12G

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.

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

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

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 10 clusters d'utilisateur, vous devez d'abord redimensionner la mémoire du nœud de cluster d'administrateur de 16 Go à 32 Go.

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

  1. Exécutez la commande suivante :

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

    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.

Dataplane V2

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

Effectuer un autoscaling pour les composants système

Anthos clusters on VMware adapte automatiquement les composants système du cluster 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 250 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.

  • Anthos clusters on VMware effectue automatiquement un scaling horizontal 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 comportant N nœuds et de C cœurs, vous pouvez attendre (N/16, C/256) instances dupliquées maximum. Notez que kube-dns a été mis à jour, car Anthos clusters on VMware 1.4 supporte jusqu'à 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 en fonction du nombre de nœuds du cluster. Il existe une instance dupliquée de calico-typha dans un cluster comportant moins de 200 nœuds, et 2 instances dupliquées dans un cluster comportant 200 nœuds 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 à 250 nœuds, pensez à le faire évoluer progressivement (faites-le passer à 80, puis à 160, puis à 250), afin 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.