Un cluster est la base de Google Kubernetes Engine (GKE) : les objets Kubernetes qui représentent vos applications en conteneur s'exécutent tous au-dessus d'un cluster.
Dans GKE, un cluster contient au moins un plan de contrôle et plusieurs machines de nœuds de calcul appelés nœuds. Ce plan de contrôle et ces machines de nœuds exécutent le système d'orchestration de cluster Kubernetes.
Le schéma suivant présente l'architecture d'un cluster zonal dans GKE.
Plan de contrôle
Le plan de contrôle exécute les processus du plan de contrôle, y compris le serveur d'API Kubernetes, le programmeur et les contrôleurs de ressources principales. Le cycle de vie du plan de contrôle est géré par GKE lorsque vous créez ou supprimez un cluster. Cela inclut les mises à niveau de la version de Kubernetes exécutées sur le plan de contrôle, que GKE effectue automatiquement ou manuellement à votre demande si vous préférez effectuer une mise à niveau antérieure à la programmation automatique.
Plan de contrôle et API Kubernetes
Le plan de contrôle est le point de terminaison unifié pour votre cluster. Vous interagissez avec le cluster via des appels d'API Kubernetes, et le plan de contrôle exécute le processus du serveur d'API Kubernetes pour traiter ces requêtes. Vous pouvez effectuer des appels d'API Kubernetes directement via HTTP/gRPC, ou indirectement, en exécutant des commandes à partir du client de la ligne de commande Kubernetes (kubectl) ou en interagissant avec l'interface utilisateur dans Cloud Console.
Le processus du serveur d'API est le centre de toutes les communications pour le cluster. Tous les processus de cluster internes (tels que les nœuds de cluster, le système et les composants, les contrôleurs d'application) agissent comme des clients du serveur d'API. Le serveur d'API est l'unique "source d'informations" pour l'ensemble du cluster.
Interaction du plan de contrôle et des nœuds
Le plan de contrôle décide ce qui s'exécute sur tous les nœuds du cluster. Le plan de contrôle planifie les charges de travail, telles que les applications en conteneur, et gère le cycle de vie, la mise à l'échelle et les mises à niveau des charges de travail. Le plan de contrôle gère également les ressources réseau et de stockage pour ces charges de travail.
Le plan de contrôle et les nœuds communiquent à l'aide des API Kubernetes.
Interactions du plan de contrôle avec Artifact Registry et Container Registry
Lorsque vous créez ou mettez à jour un cluster, les images de conteneur du logiciel Kubernetes s'exécutant sur le plan de contrôle (et les nœuds) sont extraites d'pkg.devArtifact Registry ou gcr.io de Container Registry. Une panne affectant ces registres peut être à l'origine des types de défaillance suivants :
- La création de clusters échouera pendant la panne.
- La mise à niveau des clusters échouera pendant la panne.
- Des interruptions dans la charge de travail peuvent se produire même sans intervention de l'utilisateur, en fonction de la nature et de la durée de la panne.
En cas de panne régionale du pkg.dev Artifact Registry ou du gcr.io Container Registry, Google peut rediriger les requêtes vers une zone ou une région non touchée par la panne.
Pour vérifier l'état actuel des services Google Cloud, accédez au tableau de bord d'état de Google Cloud.
Nœuds
Un cluster contient généralement un ou plusieurs nœuds, qui sont les machines de calcul qui exécutent vos applications en conteneur et d'autres charges de travail. Les machines individuelles sont des instances de VM Compute Engine que GKE crée pour vous lorsque vous créez un cluster.
Chaque nœud est géré à partir du plan de contrôle, qui reçoit des mises à jour sur l'état déclaré par chaque nœud. Vous pouvez exercer un contrôle manuel sur le cycle de vie des nœuds ou laisser GKE effectuer des réparations automatiques et des mises à niveau automatiques sur les nœuds de votre cluster.
Un nœud exécute les services nécessaires pour être compatible avec les conteneurs qui constituent les charges de travail de votre cluster. Ceux-ci incluent l'environnement d'exécution et l'agent de nœud Kubernetes (kubelet) qui communique avec le plan de contrôle et est responsable du démarrage et de l'exécution des conteneurs programmés sur ce nœud.
Dans GKE, il existe également un certain nombre de conteneurs spéciaux qui s'exécutent en tant qu'agents par nœud pour fournir des fonctionnalités telles que la collecte de journaux et la connectivité réseau au sein du cluster.
Type de machine à nœuds
Chaque nœud correspond à un type de machine Compute Engine standard. Le type par défaut est e2-medium. Vous pouvez sélectionner un type de machine différent lorsque vous créez un cluster.
Images de l'OS du nœud
Chaque nœud exécute une image d'OS spécialisée pour exécuter vos conteneurs. Vous pouvez spécifier l'image d'OS qui sera utilisée par vos clusters et pools de nœuds.
Configuration minimale de la plate-forme du processeur
Lorsque vous créez un cluster ou un pool de nœuds, vous pouvez spécifier une plate-forme de processeur de référence pour ses nœuds. Le choix d'une plate-forme de processeur spécifique peut être avantageux pour les charges de travail avancées ou intensives. Pour plus d'informations, reportez-vous à la section Configuration minimale de la plate-forme du processeur.
Ressources pouvant être allouées aux nœuds
Certaines des ressources d'un nœud sont nécessaires pour exécuter les composants de nœud GKE et Kubernetes requis pour que ce nœud fonctionne dans le cadre de votre cluster. Pour cette raison, vous remarquerez peut-être une disparité entre les ressources totales de votre nœud (spécifiées dans la documentation sur le type de machine) et les ressources pouvant être allouées dans le nœud dans GKE.
Étant donné que les types de machine plus volumineux exécutent généralement plus de conteneurs (et donc, plus de pods), la quantité de ressources que GKE réserve aux composants Kubernetes est augmentée pour les machines plus volumineuses. Les nœuds Windows Server nécessitent plus de ressources qu'un nœud Linux classique. Les nœuds nécessitent des ressources supplémentaires pour tenir compte de l'exécution du système d'exploitation Windows et des composants Windows Server qui ne peuvent pas être exécutés dans des conteneurs.
Vous pouvez demander des ressources pour vos pods ou limiter leur utilisation de ressources. Pour savoir comment demander ou limiter l'utilisation des ressources pour les pods, consultez la section Gérer les ressources pour les conteneurs.
Pour inspecter les ressources pouvant être allouées aux nœuds disponibles dans un cluster, exécutez la commande suivante, en remplaçant NODE_NAME par le nom du nœud que vous souhaitez inspecter :
kubectl describe node NODE_NAME | grep Allocatable -B 7 -A 6
La sortie affichée contient des champs Capacity et Allocatable avec des mesures pour le stockage éphémère, la mémoire, et le processeur.
Seuil d'éviction
Pour déterminer la quantité de mémoire disponible pour les pods, vous devez également tenir compte du seuil d'éviction. GKE réserve sur chaque nœud une mémoire supplémentaire de 100 Mio pour l'éviction des kubelet.
Mémoire et ressources de processeur pouvant être allouées
Les ressources pouvant être attribuées sont calculées de la manière suivante :
ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD
Pour les ressources de mémoire, GKE réserve les éléments suivants :
- 255 Mio de mémoire pour les machines dotées de moins de 1 Go de mémoire
- 25 % des 4 premiers Gio de mémoire
- 20 % des 4 Gio suivants (jusqu'à 8 Gio)
- 10 % des 8 Gio de mémoire suivants (jusqu'à 16 Gio)
- 6 % des 112 Gio suivants de mémoire (jusqu'à 128 Gio)
- 2 % de toute la mémoire au-delà de 128 Gio
Pour les ressources du processeur, GKE réserve les éléments suivants :
- 6 % du premier cœur
- 1 % du cœur suivant (jusqu'à 2 cœurs)
- 0,5 % des 2 cœurs suivants (jusqu'à 4 cœurs)
- 0,25 % de tous les cœurs au-delà de 4 cœurs
Ressources de stockage éphémère locales pouvant être allouées
À partir de la version 1.10 de GKE, vous pouvez gérer vos ressources de stockage éphémère locales de la même manière que vos ressources de processeur et de mémoire. Pour savoir comment faire en sorte que vos pods spécifient les requêtes et les limites de stockage éphémère, et comment les traiter, consultez la section Stockage éphémère local dans la documentation de Kubernetes.
GKE configure généralement ses nœuds avec un seul système de fichiers et une analyse périodique. Le stockage éphémère peut également être sauvegardé par des disques SSD locaux. Dans les deux cas, une partie du système de fichiers est réservée à l'utilisation de kubelet. La partie restante, appelée stockage éphémère local pouvant être alloué, peut être utilisée en tant que ressources de stockage éphémère.
La quantité du système de fichiers réservée à kubelet et aux autres composants du système est donnée par :
EVICTION-THRESHOLD + SYSTEM-RESERVATION
Stockage éphémère sauvegardé par le disque de démarrage
Par défaut, le stockage éphémère est secondé par le disque de démarrage des nœuds. Dans ce cas, le seuil d'élimination et la taille de la réserve système sont fournis par les formules suivantes :
EVICTION-THRESHOLD = 10% * BOOT-DISK-CAPACITY
SYSTEM-RESERVATION = Min(50% *
BOOT-DISK-CAPACITY, 6GB + 35% * BOOT-DISK-CAPACITY, 100 GB)
Pour obtenir une représentation approximative de la quantité d'espace de stockage éphémère pouvant être allouée à mesure que la capacité du disque de démarrage augmente, consultez le graphique suivant :
Stockage éphémère sauvegardé par les disques SSD locaux
L'espace réservé au système dépend du nombre de disques SSD locaux :
| Nombre de disques SSD locaux | SYSTEM-RESERVATION
(Go) |
|---|---|
| 1 | 50 |
| 2 | 75 |
| 3 ou plus | 100 |
Le seuil d'éviction est semblable au stockage éphémère sauvegardé par le disque de démarrage :
EVICTION-THRESHOLD = 10% * NUM-LOCAL-SSDS * 375 GB
La capacité de chaque disque SSD local est de 375 Go. Pour en savoir plus, consultez la documentation Compute Engine sur l'ajout de disques SSD locaux.