Architecture du cluster GKE

Autopilot Standard

---

Cette page présente l'architecture d'un cluster Google Kubernetes Engine (GKE). Vos charges de travail Kubernetes conteneurisées s'exécutent toutes dans un cluster GKE.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui définissent les solutions informatiques et l'architecture du système. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud, consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Un cluster GKE se compose d'un plan de contrôle et de machines de calcul appelées nœuds. Le plan de contrôle et les nœuds constituent le système d'orchestration de clusters Kubernetes. GKE Autopilot gère l'ensemble de l'infrastructure sous-jacente des clusters, y compris le plan de contrôle, les nœuds et tous les composants du système. Si vous utilisez le mode GKE Standard, GKE gère le plan de contrôle et les composants du système, et vous gérez les nœuds. Le schéma suivant illustre l'architecture d'un cluster GKE :

À propos du plan de contrôle

Le plan de contrôle exécute des processus tels que le serveur d'API Kubernetes, le programmeur et les contrôleurs de ressources principales. GKE gère le cycle de vie du plan de contrôle, de la création à la suppression du 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 plan de contrôle via des appels d'API Kubernetes. Le plan de contrôle exécute le processus du serveur d'API Kubernetes (kube-apiserver) pour gérer les requêtes API. Vous pouvez effectuer des appels d'API Kubernetes de différentes manières :

• Appels directs : HTTP/gRPC
• Appels indirects : clients de ligne de commande Kubernetes tels que kubectl ou la console Google Cloud.

Le processus du serveur d'API est le centre de toutes les communications pour le cluster. Tous les composants de cluster internes, tels que les nœuds, les processus système et les contrôleurs d'application, agissent en tant que clients du serveur d'API.

Les requêtes API indiquent à Kubernetes l'état souhaité pour les objets de votre cluster. Kubernetes tente de maintenir en permanence cet état. Kubernetes vous permet de configurer des objets dans l'API de manière impérative ou de manière déclarative.

Pour en savoir plus sur la gestion des objets dans Kubernetes, consultez les pages suivantes :

• Comprendre les objets Kubernetes
• Gestion d'objets Kubernetes

Interaction du plan de contrôle et des nœuds

Le plan de contrôle gère ce qui s'exécute sur tous les nœuds du cluster. Le plan de contrôle planifie les charges de travail et gère leur cycle de vie, leur mise à l'échelle et leurs mises à niveau. 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 entre eux à l'aide des API Kubernetes.

Interactions du plan de contrôle avec Artifact Registry

Lorsque vous créez ou mettez à jour un cluster, GKE extrait des images de conteneur pour le logiciel système Kubernetes s'exécutant sur le plan de contrôle et les nœuds à partir du pkg.dev Artifact Registry ou du gcr.io de Container Registry. Une panne affectant ces registres peut entraîner l'échec des actions suivantes :

• Création d'un cluster
• Mises à niveau des versions des clusters

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.

Si la panne pkg.dev Artifact Registry ou gcr.io Container Registry est régionale, nous pouvons rediriger les requêtes vers une zone ou une région non touchée par la panne.

Pour vérifier l'état des services Google Cloud, accédez au tableau de bord d'état de Google Cloud.

Bonne pratique :

Déployez vos applications dans plusieurs régions pour qu'elles restent disponibles en cas de pannes régionales.

Attention : Container Registry est obsolète et son abandon est planifié. Les organisations n'ayant pas utilisé Container Registry avant le 8 janvier 2024 disposeront par défaut des nouveaux dépôts gcr.io hébergés sur Artifact Registry. Depuis le 15 mai 2024, les projets Google Cloud qui n'utilisaient pas Container Registry précédemment n'accepteront que l'hébergement et la gestion des images dans Artifact Registry pour le domaine gcr.io.

L'arrêt de Container Registry est prévu pour le 18 mars 2025. Pour en savoir plus sur cet arrêt, consultez la page Abandon de Container Registry.

À propos des nœuds

Les nœuds sont des machines de calcul qui exécutent vos applications en conteneurs et d'autres charges de travail. Les machines individuelles sont des machines virtuelles (VM) Compute Engine créées par GKE. Le plan de contrôle gère et reçoit les mises à jour de l'état déclaré par chaque nœud.

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.

GKE exécute également un certain nombre de conteneurs système qui s'exécutent en tant qu'agents par nœud, appelés DaemonSets, qui fournissent des fonctionnalités telles que la collecte de journaux et la connectivité réseau au sein des clusters.

Bonne pratique :

Utilisez stdout pour les applications conteneurisées, car stdout permet à votre plate-forme de gérer les journaux d'application.

La gestion des nœuds varie en fonction du mode de fonctionnement du cluster, comme suit :

Composant de nœud	Mode Autopilot	Mode standard
Lifecycle	Entièrement géré par GKE, y compris : Mises à niveau automatiques Réparations automatiques Vérifications d'état Scaling automatique des nœuds Création et suppression de nœuds Redimensionner Ajout de libellés pour la séparation des charges de travail.	GKE gère les éléments suivants : Mises à niveau automatiques Réparations automatiques Vérifications d'état Vous pouvez gérer les éléments suivants : Configuration du scaling automatique des nœuds Mises à jour de version manuelles Modifications de la configuration (par exemple, les libellés et le redimensionnement) Création et suppression des pools de nœuds
Visibilité	Affichez les nœuds à l'aide de kubectl. Les machines virtuelles Compute Engine sous-jacentes qui ne sont pas visibles ni accessibles dans gcloud CLI ou la console Google Cloud.	Affichez les nœuds à l'aide de kubectl, de gcloud CLI et de la console Google Cloud. Affichez les VM Compute Engine sous-jacentes et accédez-y.
Connectivité	Aucune connexion directe aux VM sous-jacentes.	Connectez-vous à des VM sous-jacentes à l'aide de SSH.
Système d'exploitation du nœud (OS)	Gérés par GKE. Tous les nœuds utilisent Container-Optimized OS avec containerd (cos_containerd).	Choisissez un système d'exploitation pour vos nœuds.
Sélection du matériel de la machine	Demandez des classes de calcul dans les pods en fonction du cas d'utilisation. GKE gère la configuration, la planification, la quantité et le cycle de vie des machines.	Choisissez et configurez les types de machines Compute Engine lorsque vous créez des pools de nœuds. Configurez les paramètres de dimensionnement, de scaling, de quantité, de planification et d'emplacement en fonction des besoins.