Images de nœuds

Cette page décrit les images de nœuds disponibles pour les nœuds Google Kubernetes Engine (GKE). Pour découvrir comment choisir une image de nœud, reportez-vous à la page Spécifier une image de nœud.

Présentation

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.

Images de nœuds disponibles

GKE propose les options d'images de nœuds suivantes pour votre cluster :

Container-Optimized OS

L'image de nœud Container-Optimized OS de Google est basée sur une version récente du noyau Linux et optimisée pour améliorer la sécurité des nœuds. Sa maintenance est assurée par une équipe Google capable de corriger rapidement les failles de sécurité et d'améliorer les fonctionnalités. L'image Container-Optimized OS offre 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.

Ubuntu

L'image de nœud Ubuntu a été validée vis-à-vis des exigences de GKE relatives aux images de nœuds. Vous devez utiliser l'image 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.

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.

Images de nœud containerd

Containerd est un bloc fondamental et le composant principal de l'environnement d'exécution de Docker. Deux images d'OS utilisent containerd comme environnement d'exécution principal des conteneurs, directement intégré à Kubernetes : cos_containerd et ubuntu_containerd.

Pour effectuer un débogage ou dépanner le nœud, vous pouvez interagir avec containerd à l'aide de l'outil de ligne de commande portable crictl conçu pour les environnements d'exécution de conteneurs Kubernetes. crictl offre des fonctionnalités courantes telles que l'affichage des conteneurs et des images, la consultation des journaux et l'exécution de commandes dans les conteneurs. Reportez-vous au guide de l'utilisateur de crictl pour accéder à la liste complète des fonctionnalités compatibles et aux informations d'utilisation.

containerd sur Container-Optimized OS (cos_containerd)

cos_containerd est une variante de l'image Container-Optimized OS, où containerd correspond à l'environnement d'exécution des conteneurs, directement intégré à Kubernetes.

Pour plus d'informations, consultez la page Utiliser Container-Optimized OS avec containerd.

containerd sur Ubuntu (ubuntu_containerd)

ubuntu_containerd est une variante de l'image Ubuntu qui utilise containerd en tant qu'environnement d'exécution de conteneur.

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), cloud-init, Docker, Kubelet et Toolbox.
/var/lib/cloud
  • accessible en écriture
  • exécutable
  • sans état
  • tmpfs
Ce chemin d'accès est le répertoire de travail du package cloud-init.
/etc
  • accessible en écriture
  • non-exécutable
  • sans état
  • tmpfs
/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
  • accessible en écriture
  • non-exécutable
  • sans état
  • tmpfs
/tmp est 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 situés 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 ?
Google Compute Engine
Disque persistant (EXT4 ou XFS)
Oui – Entièrement testé/compatible
(XFS n'est pas compatible.)
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œud

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