Images de nœuds

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), le système d'exploitation de nœuds 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 vers une image de nœud différente. 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'image cos_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'image cos 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'image ubuntu_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'image ubuntu 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 containerdwindows_ltsc_containerd) : l'image windows_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'option windows-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 la page Images de nœuds containerd.

    • Option SAC Windows Server avec Containerd (windows_sac_containerd) : l'image windows_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'image windows_ltsc utilise Docker comme environnement d'exécution de conteneur.
    • Option SAC Windows Server avec Docker (windows_sac) : l'image windows_sac utilise Docker comme environnement d'exécution du conteneur.

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
/
  • lecture seule
  • exécutable
 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
  • accessible en écriture
  • non-exécutable
  • avec état
 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
  • accessible en écriture
  • exécutable
  • avec état
 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
  • accessible en écriture
  • exécutable
  • sans état
  • tmpfs
 Ce chemin correspond au répertoire de travail du package cloud-init.
/etc
  • accessible en écriture
  • non-exécutable
  • sans état
  • tmpfs
 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
  • accessible en écriture
  • non-exécutable
  • sans état
  • tmpfs
 Généralement utilisé comme espace de travail et ne doit pas être utilisé pour stocker des données persistantes.
/mnt/disks
  • accessible en écriture
  • exécutable
  • sans état
  • tmpfs
 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 objet 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 n'autorisent pas la modification logicielle des nœuds.

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 :

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 de l'équipe GKE)
  • ubuntu-os-gke-cloud-devel (réservé à une utilisation exclusive de 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.

Étapes suivantes