Cette page décrit l'architecture des clusters Google Kubernetes Engine (GKE) qui exécutent vos charges de travail conteneurisées. Cette page vous permet d'en savoir plus sur le plan de contrôle, les nœuds et la façon dont les différents composants du cluster GKE interagissent entre eux.
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 Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.
Avant de lire cette page, assurez-vous de connaître l'architecture des clusters Kubernetes.
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 :
Ce schéma montre les composants suivants :
- Plan de contrôle : géré par GKE. Exécute le serveur d'API Kubernetes, les contrôleurs de charge de travail, le programmateur Kubernetes et le stockage de l'état du cluster.
- Nœuds : gérés par GKE en mode Autopilot et par les clients en mode Standard. Tous vos pods s'exécutent dans des nœuds.
- Autres services Google Cloud : disponibles pour l'intégration à 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
kubectlou la consoleGoogle 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 :
Plan de contrôle et base de données d'état du cluster
Le projet Kubernetes Open Source utilise etcd comme base de données de stockage pour toutes les données de cluster par défaut. L'état du cluster est conservé dans un magasin clé-valeur qui contient des informations sur l'état de chaque objet d'API Kubernetes de votre cluster. Par exemple, la base de données d'état du cluster stocke chaque secret, ConfigMap et déploiement.
Les clusters GKE stockent l'état du cluster dans l'un des magasins de clés/valeurs suivants :
- etcd : GKE stocke l'état du cluster dans des instances etcd qui s'exécutent sur chaque machine virtuelle (VM) du plan de contrôle.
- Spanner : GKE stocke l'état du cluster dans Spanner. La base de données Spanner ne s'exécute pas dans le plan de contrôle du cluster.
Quel que soit le type de base de données, chaque cluster GKE diffuse l'API etcd dans le plan de contrôle. Le serveur d'API Kubernetes utilise l'API etcd pour communiquer avec la base de données d'état du cluster de backend.
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 des dépôts Artifact Registry dans le domaine pkg.dev ou gcr.io. 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 du dépôt Artifact 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'étatGoogle Cloud .
Déployez vos applications dans plusieurs régions pour qu'elles restent disponibles en cas de panne régionale.
À 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.
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 |
|---|---|---|
| Cycle de vie | Entièrement géré par GKE, y compris :
|
GKE gère les éléments suivants :
Vous pouvez gérer les éléments suivants :
|
| 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. |