Cette page décrit les images de nœuds disponibles pour les nœuds Google Kubernetes Engine (GKE).
Les nœuds GKE Autopilot utilisent toujours Container-Optimized OS avec containerd (cos_containerd
), qui est le système d'exploitation de nœud recommandé. Si vous utilisez GKE Standard, vous pouvez choisir l'image du système d'exploitation devant s'exécuter sur chaque nœud lors de la création du cluster ou du pool de nœuds. Vous pouvez également mettre à niveau un cluster standard existant pour utiliser une autre image de nœud. Pour savoir comment définir l'image du nœud, consultez la page Spécifier une image de nœud.
Images de nœuds disponibles
GKE propose les options d'images de nœuds suivantes par système d'exploitation pour votre cluster :
OS | Images de nœuds |
---|---|
Container-Optimized OS |
|
Ubuntu |
|
Windows Server |
|
Container-Optimized OS
Les images de nœuds Container-Optimized OS de Google sont basées sur une version récente du noyau Linux et optimisées pour améliorer la sécurité des nœuds. Les images Container-Optimized OS sont maintenues par une équipe Google capable de corriger rapidement les failles de sécurité des images et d'améliorer les fonctionnalités. Les images Container-Optimized OS offrent une compatibilité, une sécurité et une stabilité accrues par rapport aux autres images.
Pour en savoir plus sur le projet et la famille d'images, consultez la section Projets sources des images de nœuds.
Variantes de Container-Optimized OS
Deux environnements d'exécution de conteneur sont fournis avec Container-Optimized OS. Les images sont identiques, à l'exception du choix de l'environnement d'exécution du conteneur.
- Container-Optimized OS avec containerd (
cos_containerd
) : l'imagecos_containerd
utilise containerd comme environnement d'exécution de conteneur directement intégré à Kubernetes. Les clusters GKE Autopilot utilisent toujours cette image. Pour en savoir plus, consultez la page Images de nœuds containerd. - Container-Optimized OS avec Docker (
cos
) : l'imagecos
utilise l'environnement d'exécution du conteneur Docker.
Ubuntu
Les images de nœud Ubuntu ont été validées vis-à-vis des exigences de GKE relatives aux images de nœuds. Vous devez utiliser les images de nœud Ubuntu si vos nœuds nécessitent la compatibilité avec les packages XFS, CephFS ou Debian.
Pour en savoir plus sur le projet d'image et la famille, consultez la section Compatibilité des fonctionnalités par système d'exploitation.
Variantes d'Ubuntu
Deux environnements d'exécution de conteneur sont fournis avec Ubuntu. Les images sont identiques, à l'exception du choix de l'environnement d'exécution du conteneur.
Ubuntu avec containerd (
ubuntu_containerd
) : l'imageubuntu_containerd
utilise containerd comme environnement d'exécution de conteneur. Pour en savoir plus, consultez la page Images de nœuds containerd.Ubuntu avec Docker (
ubuntu
) : l'imageubuntu
utilise Docker comme environnement d'exécution du conteneur.
Windows Server
Lorsque vous créez un cluster à l'aide de pools de nœuds Windows Server, vous pouvez utiliser une image de nœud de type Windows Server SAC (Semi-Annual Channel ou canal semi-annuel) ou LTSC (Long-term Servicing Channel ou canal de maintenance à long terme). Toutes les images de nœud sont des images Windows Server Datacenter Core. Un cluster peut comporter plusieurs pools de nœuds Windows Server utilisant différentes versions de Windows Server. En revanche, chaque pool de nœuds ne peut utiliser qu'une seule version de Windows Server. Pour en savoir plus, consultez la page Choisir votre image de nœud Windows.
Deux environnements d'exécution de conteneurs sont proposés avec les images de nœuds des options LTSC et SAC Windows Server : Docker et containerd. Les images sont identiques, à l'exception du choix de l'environnement d'exécution du conteneur.
Images de l'environnement d'exécution containerd (disponibles dans GKE version 1.21 et ultérieures) :
Option LTSC Windows Server avec containerd
windows_ltsc_containerd
) : l'imagewindows_ltsc_containerd
utilise containerd comme environnement d'exécution de conteneur. Actuellement, ce type d'image correspond à deux images de nœuds : Windows Server 2022 et Windows Server 2019. Vous pouvez créer des pools de nœuds Windows LTSC2022 via la commande CLI avec l'optionwindows-os-version
.Pour en savoir plus sur la création de pools de nœuds Windows Server 2022, consultez la page Créer des pools de nœuds Windows.
Pour en savoir plus sur les images de nœuds containerd, consultez Images de nœuds containerd.
Option SAC Windows Server avec Containerd (
windows_sac_containerd
) : l'imagewindows_sac_containerd
utilise Containerd comme environnement d'exécution de conteneur.Pour en savoir plus, consultez la page Images de nœuds containerd.
Images de l'environnement d'exécution Docker (disponibles dans GKE 1.16 et versions ultérieures) :
- Option LTSC Windows Server avec Docker (
windows_ltsc
) : l'imagewindows_ltsc
utilise Docker comme environnement d'exécution de conteneur. - Option SAC Windows Server avec Docker (
windows_sac
) : l'imagewindows_sac
utilise Docker comme environnement d'exécution du conteneur.
- Option LTSC Windows Server avec Docker (
Pour en savoir plus sur le projet d'image et la famille, consultez la section Compatibilité des fonctionnalités par système d'exploitation.
Comparaison d'images de nœuds Linux
Les sections suivantes comparent les aspects opérationnels des images de nœuds Container-Optimized OS et Ubuntu, en particulier :
- Gestion de packages logiciels
- Initialisation du système
- Collecte de journaux
- Organisation du système de fichiers
- Compatibilité avec les pilotes de stockage
Gestionnaire de packages logiciels
Les images de nœuds cos
et cos_containerd
utilisent un système de fichiers racine minimal avec compatibilité intégrée de l'environnement d'exécution de conteneurs Docker (containerd), qui sert également de gestionnaire de packages pour les logiciels à installer sur l'hôte. L'image Ubuntu utilise le gestionnaire de packages APT.
Gérer les logiciels sur Container-Optimized OS
L'image Container-Optimized OS ne fournit pas de logiciel de gestion de packages tel que apt-get
. Vous ne pouvez pas installer de logiciels arbitraires sur les nœuds à l'aide de mécanismes classiques. À la place, vous devez créer une image de conteneur contenant le logiciel dont vous avez besoin.
Sur les clusters standards, à des fins de débogage uniquement, Container-Optimized OS fournit CoreOS Toolbox pour l'installation et l'exécution d'outils de débogage courants, tels que ping
, psmisc
ou pstree
.
Pour plus d'informations sur le débogage des nœuds Container-Optimized OS, consultez les guides pratiques sur Container-Optimized OS.
Gérer les logiciels sur Ubuntu
L'image Ubuntu utilise le gestionnaire de packages APT. La commande apt-get
vous permet d'installer des packages sur ces images. Par exemple, pour installer des packages ceph
, procédez comme suit :
sudo apt-get update
sudo apt-get install ceph
Initialisation du système
Les images de nœuds Container-Optimized OS et Ubuntu utilisent toutes deux systemd
pour gérer les ressources et les services du système durant le processus d'initialisation.
Ces deux images de nœuds utilisent des fichiers de service systemd pour définir les services
sur le nœud, et systemd.targets
pour regrouper les cibles d'initialisation via des dépendances.
Collecte de journaux
Les images de nœuds Container-Optimized OS et Ubuntu utilisent systemd-journald
pour collecter des journaux pour l'ensemble du système.
Afficher les journaux sur Container-Optimized OS et Ubuntu
Pour afficher les journaux sur un nœud avec l'image Container-Optimized OS ou Ubuntu, vous devez exécuter la commande journalctl
. Par exemple, pour afficher les journaux du daemon containerd :
sudo journalctl -u containerd
Pour afficher les journaux de kubelet :
sudo journalctl -u kubelet
Organisation du système de fichiers
L'image de nœud Ubuntu utilise la structure Linux standard de système de fichiers.
La structure du système de fichiers dans l'image de nœud Container-Optimized OS est optimisée pour améliorer la sécurité des nœuds. L'espace disque d'amorçage est divisé en trois types de partitions :
- Partition racine, installée en lecture seule
- Partitions avec état, accessibles en écriture et avec état
- Partitions sans état, accessibles en écriture, mais dont le contenu ne persiste pas après un redémarrage
Lorsque vous utilisez Container-Optimized OS, tenez compte du partitionnement si vous exécutez vos propres services ayant certaines exigences concernant l'organisation du système de fichiers en dehors des conteneurs.
Travailler avec le système de fichiers de Container-Optimized OS
Vous trouverez ci-dessous la liste des chemins du système de fichiers dans l'image de nœud Container-Optimized OS, ainsi que leurs propriétés et leur utilisation recommandée :
Chemin | Propriétés | Objectif |
---|---|---|
/ |
|
Le système de fichiers racine est utilisé en lecture seule pour préserver son intégrité. Le noyau vérifie l'intégrité du système de fichiers racine lors du démarrage et refuse de démarrer en cas d'erreur. |
/home /var |
|
Ces chemins d'accès sont destinés à stocker des données qui sont conservées pendant toute la durée de vie du disque de démarrage. Ils sont installés à partir de /mnt/stateful_partition . |
/var/lib/google /var/lib/docker /var/lib/toolbox |
|
Ces chemins d'accès sont des répertoires de travail pour les packages Compute Engine (par exemple, le service de gestion des comptes), Docker et Toolbox, respectivement. |
/var/lib/cloud |
|
Ce chemin correspond au répertoire de travail du package cloud-init . |
/etc |
|
Contient généralement votre configuration (par exemple, les services systemd définis via cloud-init ). Il est judicieux d'enregistrer l'état souhaité de vos instances dans cloud-init , car cloud-init est appliqué lors de la création, ainsi que lors du redémarrage d'une instance. |
/tmp |
|
Généralement utilisé comme espace de travail et ne doit pas être utilisé pour stocker des données persistantes. |
/mnt/disks |
|
Vous pouvez installer des disques persistants dans des répertoires sous /mnt/disks . |
Compatibilité avec les pilotes de stockage
Chaque image de nœud diffère par le type de plug-ins de stockage compatibles. Les termes suivants décrivent le niveau de compatibilité d'une image de nœud avec un pilote de stockage donné :
- Oui – Entièrement testé/compatible : ce plug-in de stockage est entièrement compatible et testé avec l'image de nœud spécifiée.
- Oui – Tests limités : ce plug-in de stockage fonctionne avec l'image de nœud spécifiée, mais n'a été testé que de manière limitée. Un comportement inattendu n'est pas à exclure. Pour Container-Optimized OS, ces plug-ins seront à terme testés de manière exhaustive et entièrement compatibles.
- Non compatible : ce plug-in de stockage n'a pas été testé ou utilisé avec l'image de nœud spécifiée et GKE ne peut fournir aucune garantie de fonctionnement. Il n'est pas prévu de tester ce plug-in de stockage.
- Non : ce plug-in de stockage ne fonctionne pas avec l'image de nœud spécifiée en raison d'une limitation inhérente au système d'exploitation du nœud ou à Google Cloud.
Le tableau suivant décrit la compatibilité de chaque image de nœud GKE avec certains plug-ins de stockage courants.
Type de volume | Fonctionne-t-il sur Container-Optimized OS (cos ) ? |
Fonctionne-t-il sur Ubuntu ? |
---|---|---|
Compute Engine Disque persistant (EXT4 ou XFS) |
Oui – Entièrement testé/compatible (XFS n'est compatible qu'avec cos-85 et versions ultérieures). Consultez les notes de version de GKE. | Oui – Entièrement testé/compatible |
NFSv3 | Oui – Entièrement testé/compatible | Oui – Entièrement testé/compatible |
NFSv4 | Oui – Entièrement testé/compatible | Oui – Entièrement testé/compatible |
CephFS | Non | Oui - Tests limités (Le pilote n'est pas installé par défaut. Vous devez installer le client ceph , de préférence via DaemonSet .) |
Cinder | Non | Non |
Fibre Channel | Non | Non |
Flocker | Non compatible | Non compatible |
iSCSI | Non | Non |
RBD | Non | Non |
Modifications de VM de nœuds
Les modifications sur les disques de démarrage des VM de nœuds ne persistent pas lors de la recréation de nœuds. Ces derniers sont recréés au cours des tâches de mise à niveau manuelle, de mise à niveau automatique, de réparation automatique et d'autoscaling. En outre, les nœuds sont recréés lorsque vous activez une fonctionnalité qui nécessite la recréation du nœud, par exemple l'utilisation de GKE Sandbox, de la visibilité intranœud et des nœuds protégés.
Si vous souhaitez conserver les modifications lors de la recréation des nœuds, utilisez un DaemonSet.
Il n'est pas recommandé de gérer les logiciels critiques fournis par une image de nœud, tels que le noyau ou l'environnement d'exécution du conteneur (que ce soit containerd
ou docker
). Les images de nœuds sont testées de manière approfondie et la modification des logiciels critiques fournis dans l'image de nœud place le nœud dans un état inconnu et non testable.
Les nœuds GKE Autopilot ne permettent pas de modifier le logiciel du nœud.
Mapper les versions d'image de nœud Container-Optimized OS aux versions de correctif GKE
GKE publie un mappage JSON des versions de correctif GKE aux versions des images de nœuds Container-Optimized OS :
Vous pouvez utiliser ce mappage pour passer à une version spécifique de GKE pour obtenir une version d'image spécifique. Par exemple, si votre cluster a besoin d'une certaine fonctionnalité ou d'une certaine correction à partir d'une version d'image, vous pouvez rechercher le mappage et mettre à niveau votre cluster vers une version GKE spécifique pour obtenir la version de l'image Container-Optimized OS avec les modifications. Pour en savoir plus sur les versions des images Container-Optimized OS, consultez la note de version de Container-Optimized OS.
Cette liste est mise à jour environ toutes les semaines. Pour connaître la fraîcheur des informations, consultez le champ creation_time
dans le fichier JSON.
Notes de version des images de nœuds
Container-Optimized OS
Google fournit une documentation complète sur le système d'exploitation Container-Optimized OS :
Ubuntu
Google met régulièrement à jour les images Ubuntu disponibles sur les nœuds de votre cluster. Reportez-vous aux notes de version de GKE pour obtenir des informations sur ces mises à jour. Vous y trouverez en particulier un lien vers un fichier manifeste répertoriant les packages installés par défaut.
Problèmes connus
Réinitialisations aléatoires des connexions sur les nœuds GKE utilisant Container-Optimized OS avec l'environnement d'exécution Docker
Le nœud GKE qui utilise Container-Optimized OS avec Docker (cos
) peut rencontrer des problèmes de réinitialisation aléatoire de connexion TCP lorsque deux pods sur le même nœud communiquent via un service Kubernetes ClusterIP.
Les versions suivantes de GKE sont affectées :
- 1.20.5-gke.100 (ou versions ultérieures)
Pour résoudre le problème, utilisez l'une des options suivantes :
- Migrer depuis Docker vers des images de nœuds containerd
- Activez la visibilité intranœud pour le cluster.
Projets sources de l'image de nœud
Les images de nœuds disponibles pour les clusters GKE sont contenues dans les projets sources suivants :
- Images Container-Optimized OS :
gke-node-images
- Images Ubuntu :
ubuntu-os-gke-cloud
- Images Windows Server :
gke-windows-node-images
Outre les projets sources répertoriés ci-dessus, GKE utilise également les projets sources suivants pour une utilisation exclusive par l'équipe GKE :
ubuntu-os-gke-cloud-private
(réservé à une utilisation exclusive par l'équipe GKE)ubuntu-os-gke-cloud-devel
(réservé à une utilisation exclusive par l'équipe GKE)
Vous devrez peut-être connaître les noms des projets sources lors de la configuration des clusters hautement sécurisés. Les projets sources répertoriés sont susceptibles d'être modifiés.