Images de nœuds

Cette page décrit les images de nœuds disponibles pour les nœuds Google Kubernetes Engine (GKE).

Lorsque vous créez un cluster ou un pool de nœuds GKE, vous pouvez choisir l'image du système d'exploitation devant s'exécuter sur chaque nœud. Vous pouvez également mettre à niveau un cluster existant vers un type d'image de nœud différent. 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 d'image et la famille, consultez la section Compatibilité des fonctionnalités par système d'exploitation.

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. Pour plus d'informations, consultez la section Utiliser des images 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 plus d'informations, consultez la section Utiliser des images Containerd.

  • Ubuntu avec Docker (ubuntu) : l'image ubuntu utilise Docker comme environnement d'exécution du conteneur.

Options LTSC et SAC de 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.

Ces images ne sont disponibles que pour les clusters dont la version est 1.16.8-gke.9 ou ultérieure.

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.

À 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 Docker :

sudo journalctl -u docker

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 Platform.

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.

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.

Étapes suivantes