Cette page décrit les bonnes pratiques à employer pour la création, la configuration et l'exploitation de clusters créés à l'aide de Google Distributed Cloud (logiciel uniquement) pour VMware afin de gérer les charges de travail qui approchent des limites d'évolutivité Kubernetes.
Règles du nom du cluster
Pour chaque projet Google Cloud :
- Chaque cluster d'utilisateur doit avoir un nom unique parmi tous les clusters d'administrateur qui se trouvent au sein d'un même projet Google Cloud.
Limites d'évolutivité
Tenez compte des limites suivantes lorsque vous concevez vos applications :
Chaque cluster d'administrateur prend en charge jusqu'à 100 clusters d'utilisateur, y compris des clusters haute disponibilité et standards, à l'aide du mode d'équilibrage de charge groupé (Seesaw ou MetalLB) ou du mode d'équilibrage de charge intégré (F5).
Chaque cluster d'utilisateur accepte jusqu'à :
500 nœuds utilisant le mode d'équilibrage de charge groupé (Seesaw ou MetalLB), ou 250 nœuds utilisant le mode d'équilibrage de charge intégré (F5)
15 000 pods
500 services LoadBalancer utilisant le mode d'équilibrage de charge groupé (Seesaw ou MetalLB), ou 250 services LoadBalancers utilisant le mode d'équilibrage de charge intégré (F5)
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
Google Distributed Cloud est un système complexe doté d'une grande surface d'intégration. L'évolutivité des clusters implique donc de nombreuses dimensions interreliées. Par exemple, Google Distributed Cloud peut évoluer en fonction du 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 nécessite une adresse IP DHCP ou attribuée de manière statique.
Par exemple, 307 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 | 3 |
| VM du plan de contrôle pour le cluster d'utilisateur 1 (standard) | 1 |
| VM de nœud de calcul 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 de calcul pour le cluster d'utilisateur 2 | 250 |
| Total | 307 |
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 tous vos clusters d'utilisateurs ont Controlplane V2 activé, votre cluster d'administrateur ne comporte que trois nœuds et il y a beaucoup d'adresses IP de pod disponibles. Toutefois, chaque fois que vous créez un cluster d'utilisateurs qui utilise kubeception au lieu de Controlplane V2, un ou trois nœuds sont ajoutés au cluster d'administrateur :
Chaque cluster d'utilisateur kubeception à haute disponibilité ajoute trois nœuds au cluster d'administrateur.
Chaque cluster d'utilisateur kubeception standard ajoute un nœud au cluster d'administrateur.
Si vous avez besoin d'un cluster d'administrateur à N nœuds, vous devez vous assurer que le bloc CIDR du pod est suffisamment grand pour accepter N blocs /24.
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 100 clusters utilisateur kubeception haute disponibilité, vous disposez de trois nœuds de plan de contrôle de cluster d'administrateur et de 300 nœuds de plan de contrôle de cluster d'utilisateur. Le nombre total de nœuds est de 303 (plus de 256). Par conséquent, vous devez mettre à jour le bloc CIDR du pod sur /15 pour prendre en charge jusqu'à 100 clusters d'utilisateur kubeception haute disponibilité.
Pour configurer le bloc CIDR du pod, définissez le champ network.podCIDR dans le fichier de configuration du cluster d'administrateur.
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 six services, tandis que le plan de contrôle du cluster d'administrateur utilise 14 services. Par conséquent, pour exécuter 100 clusters d'utilisateur kubeception, vous devez modifier le bloc CIDR de service dans le cluster d'administrateur pour utiliser une plage /22.
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 kubeception.
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 kubeception :
| Nombre de clusters d'utilisateurs kubeception | 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 |
| 20 à 100 | 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 kubeception. 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.
GKE Hub
Par défaut, vous pouvez enregistrer jusqu'à 250 clusters avec des adhésions globales par flotte. Si vous souhaitez enregistrer davantage de clusters dans GKE Hub, vous pouvez demander une augmentation de quota dans la console Google Cloud :
Pour en savoir plus sur les quotas de cluster basés sur les paramètres d'appartenance, consultez la section Quotas d'allocation.
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 |
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 processeur et la mémoire requis par un nœud de plan de contrôle du cluster d'utilisateur en fonction de la taille du cluster d'utilisateur :
| Nombre de nœuds de cluster d'utilisateur | Processeur du nœud du plan de contrôle | Mémoire du nœud de plan de contrôle |
|---|---|---|
| 0 à 20 | 3 CPU | 5 Go |
| 21 à 75 | 3 CPU | 6 Go |
| 76 à 250 | 4 processeurs | 8 Go |
| 251 à 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/observabilityCela é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
Google Distributed Cloud adapte automatiquement les composants système des clusters d'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.
Google Distributed Cloud effectue automatiquement un scaling vertical en faisant évoluer les demandes/limites de ressources 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.
Google Distributed Cloud effectue automatiquement un scaling horizontal dans les clusters d'administrateur et les clusters d'utilisateurs en ajustant le nombre d'instances répliquées des composants système suivants :
core-dns est la solution DNS utilisée pour la détection de services. Elle s'exécute en tant que déploiement sur les nœuds de calcul de cluster d'utilisateur. Google Distributed Cloud applique automatiquement un scaling au nombre d'instances répliqué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
Nnœuds etCcœurs, vous pouvez vous attendre àmax(N/16, C/256)d'instances dupliquées.calico-typha est un composant qui rend la mise en réseau des pods possible. Elle s'exécute en tant que déploiement sur les nœuds de calcul de cluster d'utilisateur. Google Distributed Cloud adapte automatiquement le nombre d'instances répliqué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 Istio ingress-gateway est le composant qui rend les entrées de cluster possibles. Il s'exécute 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, Google Distributed Cloud utilise l'autoscaler horizontal de pods pour faire évoluer le nombre d'instances répliquées en fonction de l'utilisation du processeur (deux instances répliquées minimum et cinq instances répliquées maximum).
Le proxy réseau konectivity (KNP) fournit un proxy au niveau TCP pour la sortie des nœuds de plan de contrôle du cluster d'utilisateur. Il tunnelise l'utilisateur kube-apiserver qui sort le trafic destiné aux nœuds du cluster d'utilisateur. L'agent Ktonctivity s'exécute en tant que déploiement sur les nœuds de calcul du cluster d'utilisateur. Google Distributed Cloud adapte automatiquement le nombre d'instances répliquées de l'agent Konnectivity en fonction du nombre de nœuds du cluster.
Nombre de nœuds (N) Nombre d'instances dupliquées de l'agent konnectivity 1 <= N <= 6 N 6 < N < 10 6 10 <= N < 100 8 N >= 100 12 ou plus
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 :
- Suivez la configuration matérielle requise pour etcd.
- Utilisez un stockage SSD ou une mémoire de stockage flash.
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_secondsetcd_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 du nœud, 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.