Chapitre 8. Red Hat Enterprise Linux CoreOS (RHCOS)
8.1. À propos du RHCOS
Red Hat Enterprise Linux CoreOS (RHCOS) représente la nouvelle génération de la technologie de système d'exploitation de conteneur à usage unique en offrant les normes de qualité de Red Hat Enterprise Linux (RHEL) avec des fonctions de mise à niveau automatisées et à distance.
RHCOS est pris en charge uniquement en tant que composant d'OpenShift Container Platform 4.12 pour toutes les machines OpenShift Container Platform. RHCOS est le seul système d'exploitation pris en charge pour les machines du plan de contrôle d'OpenShift Container Platform, ou machines maîtresses. Bien que RHCOS soit le système d'exploitation par défaut de toutes les machines de cluster, vous pouvez créer des machines de calcul, également appelées machines de travail, qui utilisent RHEL comme système d'exploitation. Il existe deux façons générales de déployer RHCOS dans OpenShift Container Platform 4.12 :
- Si vous installez votre cluster sur une infrastructure prévue par le programme d'installation, les images RHCOS sont téléchargées sur la plateforme cible pendant l'installation. Les fichiers de configuration Ignition appropriés, qui contrôlent la configuration RHCOS, sont également téléchargés et utilisés pour déployer les machines.
- Si vous installez votre cluster sur une infrastructure que vous gérez, vous devez suivre la documentation d'installation pour obtenir les images RHCOS, générer les fichiers de configuration Ignition et utiliser les fichiers de configuration Ignition pour provisionner vos machines.
8.1.1. Principales caractéristiques du RHCOS
La liste suivante décrit les principales caractéristiques du système d'exploitation RHCOS :
- Based on RHEL: Le système d'exploitation sous-jacent est principalement constitué de composants RHEL. Les mesures de qualité, de sécurité et de contrôle qui soutiennent RHEL soutiennent également RHCOS. Par exemple, le logiciel RHCOS se présente sous la forme de paquets RPM, et chaque système RHCOS démarre avec un noyau RHEL et un ensemble de services gérés par le système init systemd.
- Controlled immutability: Bien qu'il contienne des composants RHEL, RHCOS est conçu pour être géré de manière plus étroite qu'une installation RHEL par défaut. La gestion est effectuée à distance depuis le cluster OpenShift Container Platform. Lorsque vous configurez vos machines RHCOS, vous ne pouvez modifier que quelques paramètres système. Cette immuabilité contrôlée permet à OpenShift Container Platform de stocker le dernier état des systèmes RHCOS dans le cluster afin d'être toujours en mesure de créer des machines supplémentaires et d'effectuer des mises à jour basées sur les dernières configurations RHCOS.
CRI-O container runtime: Bien que RHCOS contienne des fonctionnalités permettant d'exécuter les conteneurs formatés OCI et libcontainer dont Docker a besoin, il intègre le moteur de conteneurs CRI-O au lieu du moteur de conteneurs Docker. En se concentrant sur les fonctionnalités nécessaires aux plateformes Kubernetes, telles que OpenShift Container Platform, CRI-O peut offrir une compatibilité spécifique avec les différentes versions de Kubernetes. CRI-O offre également une empreinte plus petite et une surface d'attaque réduite par rapport aux moteurs de conteneurs qui offrent un ensemble plus large de fonctionnalités. Pour l'instant, CRI-O est le seul moteur disponible dans les clusters d'OpenShift Container Platform.
CRI-O peut utiliser le runtime runC ou crun pour démarrer et gérer les conteneurs. Pour plus d'informations sur l'activation de crun, voir la documentation relative à la création d'un CR
ContainerRuntimeConfig.
La prise en charge du moteur d'exécution de conteneur crun est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.
Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.
-
Set of container tools: Pour les tâches telles que la construction, la copie et la gestion des conteneurs, RHCOS remplace l'outil Docker CLI par un ensemble compatible d'outils de conteneurs. L'outil CLI podman prend en charge de nombreuses fonctionnalités d'exécution de conteneurs, telles que l'exécution, le démarrage, l'arrêt, l'énumération et la suppression de conteneurs et d'images de conteneurs. L'outil CLI skopeo permet de copier, d'authentifier et de signer des images. Vous pouvez utiliser l'outil CLI
crictlpour travailler avec les conteneurs et les pods du moteur de conteneurs CRI-O. Bien que l'utilisation directe de ces outils dans RHCOS soit déconseillée, vous pouvez les utiliser à des fins de débogage. -
rpm-ostree upgrades: RHCOS propose des mises à jour transactionnelles à l'aide du système
rpm-ostree. Les mises à jour sont fournies au moyen d'images de conteneurs et font partie du processus de mise à jour d'OpenShift Container Platform. Lors du déploiement, l'image du conteneur est extraite et écrite sur le disque, puis le chargeur de démarrage est modifié pour démarrer avec la nouvelle version. La machine redémarre dans la mise à jour de manière continue pour s'assurer que la capacité du cluster est minimalement impactée. bootupd firmware and bootloader updater: Les gestionnaires de paquets et les systèmes hybrides tels que
rpm-ostreene mettent pas à jour le micrologiciel ou le chargeur de démarrage. Avecbootupd, les utilisateurs de RHCOS ont accès à un outil de mise à jour indépendant de toute distribution et de tout système qui gère les mises à jour du micrologiciel et du chargeur de démarrage dans les modes de démarrage UEFI et BIOS hérités qui fonctionnent sur des architectures modernes, telles que x86_64, ppc64le et aarch64.Pour plus d'informations sur l'installation de
bootupd, voir la documentation de Updating the bootloader using bootupd.-
Updated through the Machine Config Operator: Dans OpenShift Container Platform, le Machine Config Operator gère les mises à niveau du système d'exploitation. Au lieu de mettre à niveau des paquets individuels, comme c'est le cas avec les mises à niveau
yum,rpm-ostreefournit des mises à niveau du système d'exploitation en tant qu'unité atomique. Le déploiement du nouveau système d'exploitation est mis en scène pendant les mises à niveau et entre en vigueur au prochain redémarrage. Si un problème survient lors de la mise à niveau, un simple retour en arrière et un redémarrage ramènent le système à l'état précédent. Les mises à niveau du RHCOS dans OpenShift Container Platform sont effectuées lors des mises à jour des clusters.
Pour les systèmes RHCOS, la disposition du système de fichiers rpm-ostree présente les caractéristiques suivantes :
-
/usrest l'endroit où sont stockés les binaires et les bibliothèques du système d'exploitation et est en lecture seule. Nous ne sommes pas favorables à sa modification. -
/etc,/boot,/varsont accessibles en écriture sur le système mais ne doivent être modifiés que par l'opérateur de la configuration de la machine. -
/var/lib/containersest l'emplacement de stockage du graphique pour les images des conteneurs.
8.1.2. Choix de la configuration de RHCOS
RHCOS est conçu pour se déployer sur un cluster OpenShift Container Platform avec un minimum de configuration de la part de l'utilisateur. Dans sa forme la plus basique, cela consiste à :
- Commencer par une infrastructure provisionnée, comme sur AWS, ou provisionner soi-même l'infrastructure.
-
Fournir quelques informations, telles que les informations d'identification et le nom du cluster, dans un fichier
install-config.yamllors de l'exécution deopenshift-install.
Parce que les systèmes RHCOS dans OpenShift Container Platform sont conçus pour être entièrement gérés à partir du cluster OpenShift Container Platform par la suite, il est déconseillé de modifier directement une machine RHCOS. Bien qu'un accès direct limité au cluster de machines RHCOS puisse être réalisé à des fins de débogage, vous ne devriez pas configurer directement les systèmes RHCOS. Au lieu de cela, si vous avez besoin d'ajouter ou de modifier des fonctionnalités sur vos nœuds OpenShift Container Platform, envisagez d'apporter des modifications de la manière suivante :
- Kubernetes workload objects, such as DaemonSet and Deployment: Si vous devez ajouter des services ou d'autres fonctionnalités de niveau utilisateur à votre cluster, envisagez de les ajouter en tant qu'objets de charge de travail Kubernetes. Garder ces fonctionnalités en dehors des configurations de nœuds spécifiques est le meilleur moyen de réduire le risque de casser le cluster lors des mises à niveau ultérieures.
- Day-2 customizations: Dans la mesure du possible, mettez en place une grappe sans personnaliser les nœuds de la grappe et apportez les modifications nécessaires aux nœuds après la mise en place de la grappe. Ces modifications sont plus faciles à suivre ultérieurement et risquent moins d'interrompre les mises à jour. La création de configurations de machines ou la modification des ressources personnalisées de l'opérateur sont des moyens d'effectuer ces personnalisations.
-
Day-1 customizations: Pour les personnalisations que vous devez mettre en œuvre lors du démarrage du cluster, il existe des moyens de modifier votre cluster afin que les changements soient mis en œuvre lors du premier démarrage. Les personnalisations du jour 1 peuvent être effectuées par le biais des configurations Ignition et des fichiers manifestes pendant
openshift-installou en ajoutant des options de démarrage pendant les installations ISO fournies par l'utilisateur.
Voici des exemples de personnalisations que vous pouvez effectuer dès le premier jour :
- Kernel arguments: Si des fonctionnalités ou des réglages particuliers du noyau sont nécessaires sur les nœuds lors du premier démarrage de la grappe.
- Disk encryption: Si vos besoins en matière de sécurité exigent que le système de fichiers racine des nœuds soit crypté, par exemple avec la prise en charge FIPS.
- Kernel modules: Si un périphérique particulier, tel qu'une carte réseau ou une carte vidéo, ne dispose pas d'un module utilisable par défaut dans le noyau Linux.
- Chronyd: Si vous souhaitez fournir des paramètres d'horloge spécifiques à vos nœuds, tels que l'emplacement des serveurs de temps.
Pour accomplir ces tâches, vous pouvez augmenter le processus openshift-install pour inclure des objets supplémentaires tels que les objets MachineConfig. Les procédures qui aboutissent à la création de configurations de machines peuvent être transmises à l'opérateur de configuration de machines une fois que la grappe est en place.
-
Les fichiers de configuration d'Ignition générés par le programme d'installation contiennent des certificats qui expirent après 24 heures et qui sont renouvelés à ce moment-là. Si le cluster est arrêté avant le renouvellement des certificats et qu'il est redémarré après l'expiration des 24 heures, le cluster récupère automatiquement les certificats expirés. L'exception est que vous devez approuver manuellement les demandes de signature de certificat (CSR) de
node-bootstrapperen attente pour récupérer les certificats de kubelet. Pour plus d'informations, consultez la documentation relative à Recovering from expired control plane certificates. - Il est recommandé d'utiliser les fichiers de configuration Ignition dans les 12 heures suivant leur génération, car le certificat de 24 heures tourne entre 16 et 22 heures après l'installation du cluster. En utilisant les fichiers de configuration Ignition dans les 12 heures, vous pouvez éviter l'échec de l'installation si la mise à jour du certificat s'exécute pendant l'installation.
8.1.3. Choisir comment déployer RHCOS
Les différences entre les installations RHCOS pour OpenShift Container Platform sont basées sur le fait que vous déployez sur une infrastructure provisionnée par le programme d'installation ou par l'utilisateur :
- Installer-provisioned: Certains environnements cloud offrent des infrastructures préconfigurées qui vous permettent de mettre en place un cluster OpenShift Container Platform avec une configuration minimale. Pour ces types d'installations, vous pouvez fournir des configurations Ignition qui placent le contenu sur chaque nœud afin qu'il soit présent lorsque le cluster démarre pour la première fois.
- User-provisioned: Si vous provisionnez votre propre infrastructure, vous disposez d'une plus grande flexibilité dans la manière d'ajouter du contenu à un nœud RHCOS. Par exemple, vous pouvez ajouter des arguments de noyau lorsque vous démarrez le programme d'installation ISO RHCOS pour installer chaque système. Cependant, dans la plupart des cas où la configuration est requise sur le système d'exploitation lui-même, il est préférable de fournir cette configuration par le biais d'une configuration Ignition.
La fonction Ignition ne fonctionne que lorsque le système RHCOS est configuré pour la première fois. Ensuite, les configurations d'allumage peuvent être fournies ultérieurement en utilisant la configuration de la machine.
8.1.4. À propos d'Ignition
Ignition est l'utilitaire utilisé par RHCOS pour manipuler les disques lors de la configuration initiale. Il effectue des tâches courantes sur les disques, notamment le partitionnement des disques, le formatage des partitions, l'écriture de fichiers et la configuration des utilisateurs. Au premier démarrage, Ignition lit sa configuration à partir du média d'installation ou de l'emplacement que vous avez spécifié et applique la configuration aux machines.
Que vous installiez votre cluster ou que vous y ajoutiez des machines, Ignition effectue toujours la configuration initiale des machines du cluster OpenShift Container Platform. La majeure partie de la configuration réelle du système se produit sur chaque machine elle-même. Pour chaque machine, Ignition prend l'image RHCOS et démarre le noyau RHCOS. Les options de la ligne de commande du noyau identifient le type de déploiement et l'emplacement du disque RAM initial activé par Ignition (initramfs).
8.1.4.1. Comment fonctionne l'allumage
Pour créer des machines en utilisant Ignition, vous avez besoin de fichiers de configuration Ignition. Le programme d'installation d'OpenShift Container Platform crée les fichiers de configuration Ignition dont vous avez besoin pour déployer votre cluster. Ces fichiers sont basés sur les informations que vous fournissez au programme d'installation directement ou par le biais d'un fichier install-config.yaml.
La façon dont Ignition configure les machines est similaire à la façon dont des outils comme cloud-init ou Linux Anaconda kickstart configurent les systèmes, mais avec quelques différences importantes :
- Ignition fonctionne à partir d'un disque RAM initial qui est séparé du système sur lequel vous effectuez l'installation. Ignition peut donc repartitionner les disques, configurer les systèmes de fichiers et apporter d'autres modifications au système de fichiers permanent de la machine. En revanche, cloud-init s'exécute dans le cadre d'un système d'initialisation de la machine lorsque le système démarre, de sorte qu'il n'est pas aussi facile d'apporter des modifications fondamentales à des éléments tels que les partitions de disque. Avec cloud-init, il est également difficile de reconfigurer le processus de démarrage lorsque vous êtes au milieu du processus de démarrage du nœud.
- Ignition est destiné à initialiser les systèmes, et non à modifier les systèmes existants. Après l'initialisation d'une machine et l'exécution du noyau à partir du système installé, l'opérateur de configuration de machine du cluster OpenShift Container Platform complète toute la configuration future de la machine.
- Au lieu de réaliser un ensemble défini d'actions, Ignition met en œuvre une configuration déclarative. Il vérifie que toutes les partitions, fichiers, services et autres éléments sont en place avant le démarrage de la nouvelle machine. Il effectue ensuite les modifications, comme la copie de fichiers sur le disque, qui sont nécessaires pour que la nouvelle machine réponde à la configuration spécifiée.
- Une fois qu'Ignition a fini de configurer une machine, le noyau continue de tourner mais abandonne le disque RAM initial et pivote vers le système installé sur le disque. Tous les nouveaux services et autres fonctionnalités du système démarrent sans qu'il soit nécessaire de redémarrer le système.
- Comme Ignition confirme que toutes les nouvelles machines répondent à la configuration déclarée, vous ne pouvez pas avoir une machine partiellement configurée. Si la configuration d'une machine échoue, le processus d'initialisation ne se termine pas et Ignition ne démarre pas la nouvelle machine. Votre cluster ne contiendra jamais de machines partiellement configurées. Si Ignition ne peut pas se terminer, la machine n'est pas ajoutée au cluster. Vous devez ajouter une nouvelle machine à la place. Ce comportement permet d'éviter le cas difficile du débogage d'une machine lorsque les résultats d'une tâche de configuration échouée ne sont pas connus jusqu'à ce que quelque chose qui en dépende tombe en panne à une date ultérieure.
- Si un problème avec une configuration Ignition fait échouer la configuration d'une machine, Ignition n'essaiera pas d'utiliser la même configuration pour configurer une autre machine. Par exemple, un échec pourrait résulter d'une configuration Ignition composée d'une configuration parent et d'une configuration enfant qui veulent toutes deux créer le même fichier. Dans ce cas, un échec empêcherait d'utiliser à nouveau cette configuration Ignition pour configurer une autre machine jusqu'à ce que le problème soit résolu.
- Si vous avez plusieurs fichiers de configuration Ignition, vous obtenez une union de cet ensemble de configurations. Ignition étant déclaratif, des conflits entre les fichiers de configuration pourraient empêcher Ignition de configurer la machine. L'ordre des informations dans ces fichiers n'a pas d'importance. Ignition triera et implémentera chaque paramètre de la manière la plus logique possible. Par exemple, si un fichier a besoin d'un répertoire à plusieurs niveaux de profondeur et qu'un autre fichier a besoin d'un répertoire le long de ce chemin, le dernier fichier est créé en premier. Ignition trie et crée tous les fichiers, répertoires et liens par profondeur.
- Parce qu'Ignition peut démarrer avec un disque dur complètement vide, il peut faire quelque chose que cloud-init ne peut pas faire : configurer des systèmes sur du métal nu à partir de zéro en utilisant des fonctionnalités telles que le démarrage PXE. Dans le cas du bare metal, la configuration Ignition est injectée dans la partition de démarrage afin qu'Ignition puisse la trouver et configurer le système correctement.
8.1.4.2. La séquence d'allumage
Le processus d'ignition d'une machine RHCOS dans un cluster OpenShift Container Platform comprend les étapes suivantes :
- La machine obtient son fichier de configuration Ignition. Les machines du plan de contrôle obtiennent leurs fichiers de configuration Ignition à partir de la machine de démarrage, et les machines de travail obtiennent les fichiers de configuration Ignition à partir d'une machine du plan de contrôle.
- Ignition crée des partitions de disque, des systèmes de fichiers, des répertoires et des liens sur la machine. Il prend en charge les matrices RAID, mais pas les volumes LVM.
-
Ignition monte la racine du système de fichiers permanent dans le répertoire
/sysrootde l'initramfs et commence à travailler dans ce répertoire/sysroot. - Ignition configure tous les systèmes de fichiers définis et les configure pour qu'ils soient montés de manière appropriée au moment de l'exécution.
-
Ignition exécute les fichiers temporaires
systemdpour remplir les fichiers requis dans le répertoire/var. - Ignition exécute les fichiers de configuration Ignition pour configurer les utilisateurs, les fichiers unitaires systemd et d'autres fichiers de configuration.
- L'allumage démonte tous les composants du système permanent qui ont été montés dans l'initramfs.
- Ignition démarre le processus init de la nouvelle machine, qui démarre à son tour tous les autres services de la machine qui s'exécutent pendant le démarrage du système.
À la fin de ce processus, la machine est prête à rejoindre le cluster et ne nécessite pas de redémarrage.
