Architecture d'un cluster

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 :

GKE provisionne, gère et exploite l'ensemble du plan de contrôle zonal, et ne provisionne que les nœuds.

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. Toutes les interactions avec le cluster sont effectuées 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 est chargé de décider ce qui sera exécuté sur tous les nœuds du cluster. Cela peut inclure la programmation des charges de travail, telles que des applications en conteneur, et la gestion du cycle de vie, de la mise à l'échelle et des 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 également à l'aide des API Kubernetes.

Interactions du plan de contrôle avec le registre de conteneurs gcr.io

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 du registre gcr.io dans Container Registry. Une panne affectant le registre gcr.io 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 zonale ou régionale du registre gcr.io, 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 Docker qui constituent les charges de travail de votre cluster. Ceux-ci incluent l'environnement d'exécution Docker 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 Docker 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. En tant que tel, vous remarquerez peut-être une disparité entre les ressources totales de votre nœud (comme 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 effectuer une demande de 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 :

kubectl describe node node-name | grep Allocatable -B 7 -A 6

où node-name est le nom du nœud à inspecter.

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 Go de mémoire
  • 20 % des 4 Go de mémoire suivants (jusqu'à 8 Go)
  • 10 % des 8 Go de mémoire suivants (jusqu'à 16 Go)
  • 6 % des 112 Go de mémoire suivants (jusqu'à 128 Go)
  • 2 % de toute la mémoire au-delà de 128 Go
.

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

Le tableau suivant indique la quantité de mémoire et de ressources de processeur pouvant être allouée à la programmation des charges de travail Linux d'un cluster pour chaque type de machine de nœud standard.

Type de machine Capacité de la mémoire (Go) Mémoire pouvant être allouée (Go) Capacité du processeur (cœurs) Processeur pouvant être alloué (cœurs)
c2-standard-4 16 13,3 4 3,92
c2-standard-8 32 28,6 8 7,91
c2-standard-16 64 58,7 16 15,89
c2-standard-30 120 111,2 30 29,89
c2-standard-60 240 228,4 60 59,85
e2-micro 1 0,62 2 0,941
e2-small 2 1,35 2 0,941
e2-medium (par défaut) 4 2,76 2 0,941
e2-standard-2 8 6,1 2 1,93
e2-standard-4 16 13,3 4 3,92
e2-standard-8 32 28,6 8 7,91
e2-standard-16 64 58,7 16 15,89
e2-highmem-2 16 13,3 2 1,93
e2-highmem-4 32 28,6 4 3,92
e2-highmem-8 64 58,7 8 7,91
e2-highmem-16 128 118,6 16 15,89
e2-highcpu-2 2 1,5 2 1,93
e2-highcpu-4 4 2,9 4 3,92
e2-highcpu-8 8 6,1 8 7,91
e2-highcpu-16 16 13,3 16 15,89
g1-small 1,7 1,2 1 0,94
m1-megamem-96 1 433,6 1 414,7 96 95,69
m1-ultramem-40 961 942,1 40 39,85
m1-ultramem-80 1 922 1 903,1 80 79,77
m1-ultramem-160 3 844 3 825,1 160 159,69
m1-ultramem-208 5 888 5 869,1 208 207,69
m1-ultramem-416 11776 11 757,1 416 415,69
n1-standard-1 3,75 2,7 1 0,94
n1-standard-2 7,5 5,7 2 1,93
n1-standard-4 15 12,3 4 3,92
n1-standard-8 30 26,6 8 7,91
n1-standard-16 60 54,7 16 15,89
n1-standard-32 120 111,2 32 31,85
n1-standard-64 240 228,4 64 63,77
n1-standard-96 360 346,4 96 95,69
n1-highmem-2 13 10,7 2 1,93
n1-highmem-4 26 22,8 4 3,92
n1-highmem-8 52 47,2 8 7,91
n1-highmem-16 104 96 16 15,89
n1-highmem-32 208 197,4 32 31,85
n1-highmem-64 416 400,8 64 63,77
n1-highmem-96 624 605,1 96 95,69
n1-highcpu-2 1,8 1,3 2 1,93
n1-highcpu-4 3,6 2,6 4 3,92
n1-highcpu-8 7,2 5,5 8 7,91
n1-highcpu-16 14,4 11,9 16 15,89
n1-highcpu-32 28,8 25,3 32 31,85
n1-highcpu-64 57,6 52,5 64 63,77
n1-highcpu-96 86,4 79,6 96 95,69
n2-standard-2 8 6,1 2 1,93
n2-standard-4 16 13,3 4 3,92
n2-standard-8 32 28,6 8 7,91
n2-standard-16 64 58,7 16 15,89
n2-standard-32 128 118,6 32 31,85
n2-standard-48 192 182,6 48 47,85
n2-standard-64 256 244,4 64 63,77
n2-standard-80 320 308,4 80 79,77
n2-highmem-2 16 13,3 2 1,93
n2-highmem-4 32 28,6 4 3,92
n2-highmem-8 64 58,7 8 7,91
n2-highmem-16 128 118,6 16 15,89
n2-highmem-32 256 244,4 32 31,85
n2-highmem-48 384 370,4 48 47,85
n2-highmem-64 512 496,8 64 63,77
n2-highmem-80 640 621,1 80 79,77
n2-highcpu-2 2 1,5 2 1,93
n2-highcpu-4 4 2,9 4 3,92
n2-highcpu-8 8 6,1 8 7,91
n2-highcpu-16 16 13,3 16 15,89
n2-highcpu-32 32 28,6 32 31,85
n2-highcpu-48 48 44,6 48 47,85
n2-highcpu-64 64 58,7 64 63,77
n2-highcpu-80 80 74,7 80 79,77
n2d-standard-2 8 6,1 2 1,93
n2d-standard-4 16 13,3 4 3,92
n2d-standard-8 32 28,6 8 7,91
n2d-standard-16 64 58,7 16 15,89
n2d-standard-32 128 118,6 32 31,85
n2d-standard-48 192 182,6 48 47,85
n2d-standard-64 256 244,4 64 63,77
n2d-standard-80 320 308,4 80 79,77
n2d-standard-96 384 370,4 96 95,69
n2d-standard-128 512 496,8 128 127,69
n2d-standard-224 896 877,1 224 223,69
n2d-highmem-2 16 13,3 2 1,93
n2d-highmem-4 32 28,6 4 3,92
n2d-highmem-8 64 58,7 8 7,91
n2d-highmem-16 128 118,6 16 15,89
n2d-highmem-32 256 244,4 32 31,85
n2d-highmem-48 384 370,4 48 47,85
n2d-highmem-64 512 496,8 64 63,77
n2d-highmem-80 640 621,1 80 79,77
n2d-highmem-96 780 761,1 96 95,69
n2d-highcpu-2 2 1,5 2 1,93
n2d-highcpu-4 4 2,9 4 3,92
n2d-highcpu-8 8 6,1 8 7,91
n2d-highcpu-16 16 13,3 16 15,89
n2d-highcpu-32 32 28,6 32 31,85
n2d-highcpu-48 48 44,6 48 47,85
n2d-highcpu-64 64 58,7 64 63,77
n2d-highcpu-80 80 74,7 80 79,77
n2d-highcpu-96 96 89,2 96 95,69
n2d-highcpu-128 128 118,6 128 127,69
n2d-highcpu-224 224 213,4 224 223,69

1 GKE a décidé de réduire les ressources de processeur pouvant être allouées pour planifier des charges de travail utilisateur (appelées ressources attribuables aux nœuds) sur les types de machines e2-micro, e2-small et e2-medium. Pour en savoir plus, consultez les notes de version de GKE.

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. En fonction de sa taille, une partie du disque de démarrage est réservée à l'utilisation du système.

Le stockage éphémère peut utiliser la capacité totale du disque de démarrage, à l'exception d'une partie réservée à l'utilisation du système et un seuil d'éviction. La taille totale réservée dépend de la taille du disque de démarrage selon la formule suivante :

10% * BOOT-DISK-CAPACITY + Min(50% * BOOT-DISK-CAPACITY, 6K + 35% * BOOT-DISK-CAPACITY, 100G)

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 :

Graphique illustrant l'augmentation du stockage éphémère avec la capacité du disque de démarrage. La relation est approximativement linéaire.