Cette page décrit les bonnes pratiques à adopter pour créer, configurer et exploiter des clusters GKE On-Prem capables de fonctionner avec des charges de travail qui approchent des limites d'évolutivité de Kubernetes.
Limites d'évolutivité
Tenez compte des limites suivantes lorsque vous concevez vos applications sur GKE On-Prem :
Chaque cluster d'administrateur accepte jusqu'à 20 clusters d'utilisateur (haute disponibilité et standards).
Chaque cluster d'utilisateur accepte jusqu'à :
250 nœuds ;
7 500 pods ;
500 services LoadBalancer en mode d'équilibrage de charge groupé (Seesaw) ou 250 services LoadBalancer en 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
GKE On-Prem 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, GKE On-Prem 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 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 GKE On-Prem 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 des pods par défaut vous permet de créer un cluster avec 250 nœuds, ce qui correspond au nombre maximal de nœuds acceptés par GKE On-Prem 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 des services par défaut vous permet de créer un cluster avec 500 services, ce qui correspond au nombre maximal de services acceptés par GKE On-Prem 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 demander une augmentation de quota dans Google 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 :
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.
Définissez le champ
spec.template.spec.providerSpec.value.machineVariables.memorysur32768.Enregistrez la modification. Les nœuds du cluster d'administrateur sont recréés avec une quantité de mémoire de 32 Go.
Effectuer un autoscaling pour les composants système
GKE On-Prem applique un scaling automatique aux 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.
GKE On-Prem 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 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.
GKE On-Prem effectue automatiquement un scaling horizontal en faisant évoluer 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 GKE On-Prem. Elle s'exécute en tant que déploiement sur les nœuds de calcul de cluster d'utilisateur. GKE On-Prem applique un scaling automatique au 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 depuis la version GKE On-Prem 1.4 afin de pouvoir gérer 1 500 requêtes simultanées par seconde.
calico-typha est un composant qui rend la mise en réseau des pods possible dans GKE On-Prem. Elle s'exécute en tant que déploiement sur les nœuds de calcul de cluster d'utilisateur. GKE On-Prem applique un scaling automatique au 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, GKE On-Prem 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 :
- 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_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 du nœud GKE On-Prem, 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.