Prise en charge des conteneurs en bac à sable pour OpenShift
Guide sur les conteneurs sandboxés d'OpenShift
Résumé
Chapitre 1. {sandboxed-containers-first} {sandboxed-containers-version} notes de mise à jour Copier lienLien copié sur presse-papiers!
1.1. À propos de cette version Copier lienLien copié sur presse-papiers!
Ces notes de version suivent le développement de OpenShift sandboxed containers 1.3 avec Red Hat OpenShift Container Platform 4.12.
Ce produit est entièrement pris en charge et activé par défaut à partir de la version 4.10 d'OpenShift Container Platform.
1.2. Nouvelles fonctionnalités et améliorations Copier lienLien copié sur presse-papiers!
1.2.1. ID du conteneur dans la liste des métriques Copier lienLien copié sur presse-papiers!
Le site sandbox_id avec l'ID du conteneur sandboxé concerné apparaît désormais dans la liste des mesures de la page Metrics de la console Web.
En outre, le processus kata-monitor ajoute désormais trois nouveaux labels aux métriques spécifiques aux katas : cri_uid, cri_name, et cri_namespace. Ces étiquettes permettent de relier les mesures spécifiques aux kata aux charges de travail kubernetes correspondantes.
Pour plus d'informations sur les métriques spécifiques aux katas, voir À propos des métriques des conteneurs sandboxés d'OpenShift.
1.2.2. Disponibilité des conteneurs OpenShift en bac à sable sur AWS bare metal Copier lienLien copié sur presse-papiers!
Auparavant, la disponibilité des conteneurs OpenShift sandboxed sur AWS bare metal était en Technology Preview. Avec cette version, l'installation de conteneurs OpenShift sandboxed sur des clusters AWS bare-metal est entièrement prise en charge.
1.2.3. Prise en charge des conteneurs OpenShift sandboxed sur OpenShift single-node Copier lienLien copié sur presse-papiers!
Les conteneurs OpenShift sandboxed fonctionnent désormais sur les clusters OpenShift à nœud unique lorsque l'opérateur de conteneurs OpenShift sandboxed est installé par Red Hat Advanced Cluster Management (RHACM).
1.3. Mises à jour Copier lienLien copié sur presse-papiers!
Le kataMonitorImage n'est plus nécessaire lors de la création de la ressource personnalisée KataConfig. Cette mise à jour a été implémentée avec OpenShift sandboxed containers 1.3.2, avec une rétrocompatibilité sur toutes les versions de l'opérateur OpenShift sandboxed containers.
1.4. Bug fixes Copier lienLien copié sur presse-papiers!
Auparavant, lors de l'installation de conteneurs OpenShift sandboxed sur OpenShift Container Platform 4.10, le gestionnaire de contrôleur POD ne démarrait pas avec l'erreur suivante :
container has runAsNonRoot and image has non-numeric user (nonroot), cannot verify user is non-rootEn raison de ce problème, le CR
KataConfign'a pas pu être créé et les conteneurs OpenShift sandboxed n'ont pas pu être exécutés.Avec cette version, l'image du conteneur du gestionnaire a été mise à jour pour utiliser un identifiant numérique (499). (KATA-1824)
Auparavant, lors de la création du CR
KataConfiget de l'observation de l'état du pod sous l'espace de nomsopenshift-sandboxed-containers-operator, un grand nombre de redémarrages pour les pods de surveillance était affiché. Les pods de surveillance utilisent une politique SELinux spécifique qui a été installée dans le cadre de l'installation de l'extensionsandboxed-containers. Le module de surveillance a été créé immédiatement. Cependant, la politique SELinux n'était pas encore disponible, ce qui a entraîné une erreur de création de pod, suivie d'un redémarrage du pod.Avec cette version, la politique SELinux est disponible lorsque le module de surveillance est créé, et le module de surveillance passe immédiatement à l'état
Running. (KATA-1338)-
Auparavant, les conteneurs OpenShift sandboxed déployaient une contrainte de contexte de sécurité (SCC) au démarrage qui appliquait une politique SELinux personnalisée qui n'était pas disponible sur les pods Machine Config Operator (MCO). Cela provoquait le passage du pod MCO à l'état
CrashLoopBackOffet l'échec des mises à niveau du cluster. Avec cette version, OpenShift sandboxed containers déploie le SCC lors de la création deKataConfigCR et n'applique plus la politique SELinux personnalisée. (KATA-1373) -
Auparavant, lors de la désinstallation de l'OpenShift sandboxed containers Operator, la ressource personnalisée
sandboxed-containers-operator-sccn'était pas supprimée. Avec cette version, la ressource personnaliséesandboxed-containers-operator-sccest supprimée lors de la désinstallation de l'OpenShift sandboxed containers Operator. (KATA-1569)
1.5. Problèmes connus Copier lienLien copié sur presse-papiers!
Lors de l'utilisation de conteneurs OpenShift sandboxed, si vous définissez des étiquettes SELinux Multi-Category Security (MCS) au niveau du conteneur, le pod ne démarre pas avec l'erreur suivante :
Error: CreateContainer failed: EACCES: Permission denied: unknownLes étiquettes MCS définies au niveau du conteneur ne sont pas appliquées à virtiofsd. Le moteur d'exécution
katan'a pas accès au contexte de sécurité du conteneur lors de la création de la VM.Cela signifie que virtiofsd ne s'exécute pas avec le label SELinux approprié et ne peut pas accéder aux fichiers de l'hôte au nom des conteneurs de la VM ; tous les conteneurs peuvent accéder à tous les fichiers de la VM.
Si vous utilisez des conteneurs OpenShift sandboxed, vous pouvez recevoir des dénis SELinux lors de l'accès aux fichiers ou répertoires montés à partir du volume
hostPathdans un cluster OpenShift Container Platform. Ces refus peuvent se produire même lors de l'exécution de conteneurs sandbox privilégiés, car les conteneurs sandbox privilégiés ne désactivent pas les vérifications SELinux.Le respect de la politique SELinux sur l'hôte garantit une isolation totale du système de fichiers de l'hôte par rapport à la charge de travail en bac à sable par défaut. Cela permet également de renforcer la protection contre les failles de sécurité potentielles du démon
virtiofsdou de QEMU.Si les fichiers ou répertoires montés n'ont pas d'exigences SELinux spécifiques sur l'hôte, vous pouvez utiliser des volumes persistants locaux comme alternative. Les fichiers sont automatiquement réétiquetés sur
container_file_t, conformément à la politique SELinux pour les exécutions de conteneurs. Voir Stockage persistant à l'aide de volumes locaux pour plus d'informations.Le réétiquetage automatique n'est pas une option lorsque les fichiers ou répertoires montés sont censés avoir des étiquettes SELinux spécifiques sur l'hôte. À la place, vous pouvez définir des règles SELinux personnalisées sur l'hôte pour permettre au démon
virtiofsdd'accéder à ces étiquettes spécifiques. (BZ#1904609)Certains conteneurs OpenShift sandboxed Operator pods utilisent les limites de ressources CPU des conteneurs pour augmenter le nombre de CPU disponibles pour le pod. Ces pods peuvent recevoir moins de CPU que ce qui a été demandé. Si la fonctionnalité est disponible à l'intérieur du conteneur, vous pouvez diagnostiquer les problèmes de ressources CPU en utilisant
oc rsh <pod>pour accéder à un pod et en exécutant la commandelscpu:$ lscpuExemple de sortie
CPU(s): 16 On-line CPU(s) list: 0-12,14,15 Off-line CPU(s) list: 13La liste des unités centrales hors ligne changera probablement de manière imprévisible d'une exécution à l'autre.
Comme solution de contournement, vous pouvez utiliser une annotation de pod pour demander des CPU supplémentaires plutôt que de fixer une limite de CPU. Les demandes de CPU qui utilisent l'annotation de pod ne sont pas affectées par ce problème, car la méthode d'allocation du processeur est différente. Plutôt que de fixer une limite de CPU, l'adresse
annotationsuivante doit être ajoutée aux métadonnées du pod :metadata: annotations: io.katacontainers.config.hypervisor.default_vcpus: "16"La progression de l'installation du runtime est affichée dans la section
statusde la ressource personnalisée (CR)kataConfig. Cependant, la progression n'est pas affichée si toutes les conditions suivantes sont remplies :-
Aucun nœud de travail n'est défini. Vous pouvez exécuter
oc get machineconfigpoolpour vérifier le nombre de nœuds de travail dans le pool de configuration de la machine. -
Aucune adresse
kataConfigPoolSelectorn'est spécifiée pour sélectionner les nœuds à installer.
Dans ce cas, l'installation commence sur les nœuds du plan de contrôle car l'opérateur suppose qu'il s'agit d'un cluster convergent où les nœuds ont à la fois des rôles de plan de contrôle et de travailleur. La section
statusdu CRkataConfign'est pas mise à jour pendant l'installation. (KATA-1017)-
Aucun nœud de travail n'est défini. Vous pouvez exécuter
Lors de l'utilisation d'anciennes versions de l'outil Buildah dans les conteneurs OpenShift sandboxed, la construction échoue avec l'erreur suivante :
process exited with error: fork/exec /bin/sh: no such file or directory subprocess exited with status 1Vous devez utiliser la dernière version de Buildah, disponible sur quay.io.
-
Dans l'onglet KataConfig de la console web, si vous cliquez sur Create KataConfig alors que vous êtes dans YAML view, il manque les champs
specdans le YAMLKataConfig. Le fait de passer à Form view puis de revenir à YAML view corrige ce problème et affiche le YAML complet. (KATA-1372) -
Dans l'onglet KataConfig de la console web, un message d'erreur
404: Not foundapparaît si un CRKataConfigexiste déjà ou non. Pour accéder à un CRKataConfigexistant, allez sur Home > Search. Dans la liste Resources, sélectionnez KataConfig. (KATA-1605) La mise à jour des conteneurs OpenShift sandboxed ne met pas automatiquement à jour l'image
KataConfigCR existante. Par conséquent, les pods de surveillance des déploiements précédents ne sont pas redémarrés et continuent de fonctionner avec une imagekataMonitorobsolète.Mettez à jour l'image
kataMonitorà l'aide de la commande suivante :$ oc patch kataconfig example-kataconfig --type merge --patch '{"spec":{"kataMonitorImage":"registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0"}}'Vous pouvez également mettre à jour l'image
kataMonitoren éditant le YAMLKataConfigdans la console web.
1.6. Mises à jour asynchrones de l'errata Copier lienLien copié sur presse-papiers!
Les mises à jour de sécurité, les corrections de bogues et les améliorations pour les conteneurs OpenShift sandboxed 4.12 sont publiées en tant qu'errata asynchrone via le Red Hat Network. Tous les errata d'OpenShift Container Platform 4.12 sont disponibles sur le portail client de Red Hat. Pour plus d'informations sur les errata asynchrones, consultez le cycle de vie d'OpenShift Container Platform.
Les utilisateurs du portail client de Red Hat peuvent activer les notifications d'errata dans les paramètres du compte pour la gestion des abonnements Red Hat (RHSM). Lorsque les notifications d'errata sont activées, les utilisateurs sont notifiés par courriel lorsque de nouveaux errata concernant leurs systèmes enregistrés sont publiés.
Les comptes utilisateurs du portail client Red Hat doivent avoir des systèmes enregistrés et consommer des droits OpenShift Container Platform pour que les courriels de notification d'errata d'OpenShift Container Platform soient générés.
Cette section continuera d'être mise à jour au fil du temps pour fournir des notes sur les améliorations et les corrections de bugs pour les futures versions d'errata asynchrones d'OpenShift sandboxed containers 1.3.
1.6.1. RHSA-2022:6072 - Mise à jour de l'image d'OpenShift sandboxed containers 1.3.0, correction de bogues et avis d'amélioration Copier lienLien copié sur presse-papiers!
Publié : 2022-08-17
La version 1.3.0 d'OpenShift sandboxed containers est maintenant disponible. Cet avis contient une mise à jour pour OpenShift sandboxed containers avec des améliorations et des corrections de bugs.
La liste des corrections de bogues incluses dans la mise à jour est documentée dans l'avis RHSA-2022:6072.
1.6.2. RHSA-2022:7058 - Avis de correction de sécurité et de correction de bogues pour OpenShift sandboxed containers 1.3.1 Copier lienLien copié sur presse-papiers!
Publié : 2022-10-19
La version 1.3.1 d'OpenShift sandboxed containers est maintenant disponible. Cet avis contient une mise à jour pour OpenShift sandboxed containers avec des corrections de sécurité et une correction de bogue.
La liste des corrections de bogues incluses dans la mise à jour est documentée dans l'avis RHSA-2022:7058.
1.6.3. RHBA-2023:0390 - Avis de correction de bogue pour OpenShift sandboxed containers 1.3.2 Copier lienLien copié sur presse-papiers!
Publié : 2023-01-24
La version 1.3.2 d'OpenShift sandboxed containers est maintenant disponible. Cet avis contient une mise à jour pour OpenShift sandboxed containers avec des corrections de bugs.
La liste des corrections de bogues incluses dans la mise à jour est documentée dans l'avis RHBA-2023:0390.
1.6.4. RHBA-2023:0485 - Avis de correction de bogue pour OpenShift sandboxed containers 1.3.3 Copier lienLien copié sur presse-papiers!
Publié : 2023-01-30
La version 1.3.3 d'OpenShift sandboxed containers est maintenant disponible. Cet avis contient une mise à jour pour OpenShift sandboxed containers avec des corrections de bugs et des mises à jour de conteneurs.
La liste des corrections de bogues incluses dans la mise à jour est documentée dans l'avis RHBA-2023:0485.
Chapitre 2. Comprendre les conteneurs de type "sandbox" d'OpenShift Copier lienLien copié sur presse-papiers!
La prise en charge des conteneurs en bac à sable OpenShift pour OpenShift Container Platform vous offre une prise en charge intégrée de l'exécution de Kata Containers en tant que runtime optionnel supplémentaire. Le nouveau runtime prend en charge les conteneurs dans des machines virtuelles (VM) dédiées, ce qui permet d'améliorer l'isolation de la charge de travail. Ceci est particulièrement utile pour effectuer les tâches suivantes :
- Exécuter des charges de travail privilégiées ou non fiables
OpenShift sandboxed containers (OSC) permet d'exécuter en toute sécurité des charges de travail qui nécessitent des privilèges spécifiques, sans avoir à risquer de compromettre les nœuds du cluster en exécutant des conteneurs privilégiés. Les charges de travail qui requièrent des privilèges spéciaux sont les suivantes :
- Les charges de travail qui requièrent des capacités spéciales de la part du noyau, au-delà des capacités par défaut accordées par les runtimes de conteneurs standard tels que CRI-O, par exemple pour accéder à des fonctions de réseau de bas niveau.
- Les charges de travail qui nécessitent des privilèges root élevés, par exemple pour accéder à un appareil physique spécifique. Avec les conteneurs OpenShift sandboxed, il est possible de ne faire passer qu'un appareil spécifique dans la VM, en veillant à ce que la charge de travail ne puisse pas accéder au reste du système ou le configurer de manière erronée.
-
Charges de travail pour l'installation ou l'utilisation des binaires root de
set-uid. Ces binaires accordent des privilèges spéciaux et, en tant que tels, peuvent présenter un risque de sécurité. Avec les conteneurs OpenShift sandboxed, les privilèges supplémentaires sont limités aux machines virtuelles et n'accordent aucun accès spécial aux nœuds du cluster.
Certaines charges de travail peuvent nécessiter des privilèges spécifiquement pour configurer les nœuds du cluster. Ces charges de travail doivent toujours utiliser des conteneurs privilégiés, car leur exécution sur une machine virtuelle les empêcherait de fonctionner.
- Assurer l'isolation du noyau pour chaque charge de travail
-
Les conteneurs en bac à sable d'OpenShift prennent en charge les charges de travail qui nécessitent un réglage personnalisé du noyau (comme
sysctl, des modifications du planificateur ou un réglage du cache) et la création de modules personnalisés du noyau (commeout of treeou des arguments spéciaux). - Partager la même charge de travail entre les locataires
-
Les conteneurs OpenShift sandboxed vous permettent de prendre en charge plusieurs utilisateurs (locataires) de différentes organisations partageant le même cluster OpenShift. Le système vous permet également d'exécuter des charges de travail tierces provenant de plusieurs fournisseurs, telles que des fonctions de réseau de conteneurs (CNF) et des applications d'entreprise. Les CNF tiers, par exemple, peuvent ne pas vouloir que leurs paramètres personnalisés interfèrent avec le réglage des paquets ou avec les variables
sysctldéfinies par d'autres applications. L'exécution à l'intérieur d'un noyau complètement isolé permet d'éviter les problèmes de configuration des "voisins bruyants". - Veiller à l'isolation et à la mise en bac à sable des logiciels de test
-
Vous pouvez utiliser les conteneurs OpenShift sandboxed pour exécuter une charge de travail conteneurisée avec des vulnérabilités connues ou pour gérer un problème dans une application existante. Cette isolation permet également aux administrateurs de donner aux développeurs un contrôle administratif sur les pods, ce qui est utile lorsque le développeur veut tester ou valider des configurations au-delà de celles qu'un administrateur accorderait normalement. Les administrateurs peuvent, par exemple, déléguer en toute sécurité le filtrage des paquets du noyau (eBPF) aux développeurs. Le filtrage des paquets du noyau nécessite les privilèges
CAP_ADMINouCAP_BPFet n'est donc pas autorisé dans une configuration CRI-O standard, car cela donnerait accès à chaque processus sur le nœud de travail de l'hôte du conteneur. De même, les administrateurs peuvent autoriser l'accès à des outils intrusifs tels que SystemTap, ou prendre en charge le chargement de modules de noyau personnalisés au cours de leur développement. - Assurer le confinement des ressources par défaut à travers les limites des machines virtuelles
- Par défaut, les ressources telles que le CPU, la mémoire, le stockage ou le réseau sont gérées de manière plus robuste et sécurisée dans les conteneurs OpenShift sandboxed. Puisque les conteneurs OpenShift sandboxed sont déployés sur des VM, des couches supplémentaires d'isolation et de sécurité donnent un contrôle d'accès plus fin à la ressource. Par exemple, un conteneur errant ne pourra pas allouer plus de mémoire que ce qui est disponible pour la VM. Inversement, un conteneur qui a besoin d'un accès dédié à une carte réseau ou à un disque peut prendre le contrôle total de ce périphérique sans avoir accès aux autres périphériques.
2.1. Plateformes supportées par les conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Vous pouvez installer les conteneurs OpenShift sandboxed sur un serveur bare-metal ou sur une instance bare-metal Amazon Web Services (AWS). Les instances bare-metal proposées par d'autres fournisseurs de cloud ne sont pas prises en charge.
Red Hat Enterprise Linux CoreOS (RHCOS) est le seul système d'exploitation pris en charge pour les conteneurs OpenShift sandboxed. OpenShift sandboxed containers 1.3 fonctionne sur Red Hat Enterprise Linux CoreOS (RHCOS) 8.6.
OpenShift sandboxed containers 1.3 est compatible avec OpenShift Container Platform 4.11.
2.2. OpenShift sandboxed containers termes communs Copier lienLien copié sur presse-papiers!
Les termes suivants sont utilisés dans la documentation.
- Bac à sable
Un bac à sable est un environnement isolé dans lequel des programmes peuvent être exécutés. Dans un bac à sable, vous pouvez exécuter des programmes non testés ou non fiables sans risquer d'endommager la machine hôte ou le système d'exploitation.
Dans le contexte des conteneurs OpenShift sandboxed, le sandboxing est réalisé en exécutant les charges de travail dans un noyau différent à l'aide de la virtualisation, ce qui permet d'améliorer le contrôle des interactions entre plusieurs charges de travail qui s'exécutent sur le même hôte.
- Cosse
Un pod est une construction héritée de Kubernetes et d'OpenShift Container Platform. Il représente les ressources où les conteneurs peuvent être déployés. Les conteneurs s'exécutent à l'intérieur des pods, et les pods sont utilisés pour spécifier les ressources qui peuvent être partagées entre plusieurs conteneurs.
Dans le contexte des conteneurs OpenShift sandboxed, un pod est implémenté comme une machine virtuelle. Plusieurs conteneurs peuvent s'exécuter dans le même pod sur la même machine virtuelle.
- Opérateur de conteneurs en bac à sable OpenShift
Un opérateur est un composant logiciel qui automatise les opérations, c'est-à-dire les actions qu'un opérateur humain pourrait effectuer sur le système.
L'OpenShift sandboxed containers Operator est chargé de gérer le cycle de vie des conteneurs sandboxed sur un cluster. Vous pouvez utiliser l'OpenShift sandboxed containers Operator pour effectuer des tâches telles que l'installation et la suppression de conteneurs sandboxed, les mises à jour logicielles et la surveillance de l'état.
- Conteneurs Kata
- Kata Containers est un projet principal en amont qui est utilisé pour construire des conteneurs OpenShift sandboxed. Les conteneurs OpenShift sandboxed intègrent Kata Containers avec OpenShift Container Platform.
- KataConfig
-
KataConfigreprésentent des configurations de conteneurs en bac à sable. Ils stockent des informations sur l'état de la grappe, telles que les nœuds sur lesquels le logiciel est déployé. - Classe d'exécution
-
Un objet
RuntimeClassdécrit quel runtime peut être utilisé pour exécuter une charge de travail donnée. Une classe d'exécution nomméekataest installée et déployée par l'opérateur de conteneurs en bac à sable OpenShift. La classe d'exécution contient des informations sur l'exécution qui décrivent les ressources dont l'exécution a besoin pour fonctionner, telles que l'overhead du pod.
2.3. OpenShift sandboxed containers workload management (gestion de la charge de travail) Copier lienLien copié sur presse-papiers!
Les conteneurs OpenShift sandboxed offrent les fonctionnalités suivantes pour améliorer la gestion et l'allocation de la charge de travail :
2.3.1. Les blocs de construction des conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
L'opérateur de conteneurs en bac à sable OpenShift encapsule tous les composants des conteneurs Kata. Il gère les tâches d'installation, de cycle de vie et de configuration.
L'opérateur de conteneurs en bac à sable OpenShift est emballé dans le format Operator bundle sous forme de deux images de conteneurs. L'image du bundle contient des métadonnées et est nécessaire pour rendre l'opérateur prêt pour OLM. La deuxième image de conteneur contient le contrôleur réel qui surveille et gère la ressource KataConfig.
2.3.2. Extensions RHCOS Copier lienLien copié sur presse-papiers!
L'opérateur OpenShift sandboxed containers est basé sur le concept d'extensions Red Hat Enterprise Linux CoreOS (RHCOS). Les extensions Red Hat Enterprise Linux CoreOS (RHCOS) sont un mécanisme permettant d'installer des logiciels OpenShift Container Platform optionnels. L'OpenShift sandboxed containers Operator utilise ce mécanisme pour déployer des conteneurs sandboxed sur un cluster.
L'extension RHCOS des conteneurs en bac à sable contient des RPM pour Kata, QEMU et ses dépendances. Vous pouvez les activer en utilisant les ressources MachineConfig fournies par Machine Config Operator.
Ressources supplémentaires
2.3.3. Virtualisation et conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Vous pouvez utiliser des conteneurs OpenShift sandboxed sur des clusters avec OpenShift Virtualization.
Pour exécuter OpenShift Virtualization et OpenShift sandboxed containers en même temps, vous devez permettre aux VMs de migrer, afin qu'elles ne bloquent pas le redémarrage des nœuds. Configurez les paramètres suivants sur votre VM :
-
Utilisez
ocs-storagecluster-ceph-rbdcomme classe de stockage. -
Réglez le paramètre
evictionStrategysurLiveMigratedans la VM.
2.4. Comprendre la conformité et la gestion des risques Copier lienLien copié sur presse-papiers!
Les conteneurs OpenShift sandboxed peuvent être utilisés sur des clusters compatibles FIPS.
Lors de l'exécution en mode FIPS, les composants des conteneurs, les VM et les images de VM en bac à sable d'OpenShift sont adaptés pour être conformes à la norme FIPS.
La conformité FIPS est l'un des éléments les plus critiques requis dans les environnements hautement sécurisés, afin de garantir que seules les technologies cryptographiques prises en charge sont autorisées sur les nœuds.
The use of FIPS Validated / Modules in Process cryptographic libraries is only supported on OpenShift Container Platform deployments on the x86_64 architecture.
Pour comprendre le point de vue de Red Hat sur les cadres de conformité d'OpenShift Container Platform, reportez-vous au chapitre Gestion des risques et préparation aux réglementations du livre-guide sur la sécurité d'OpenShift.
Chapitre 3. Déployer les charges de travail des conteneurs sandboxés d'OpenShift Copier lienLien copié sur presse-papiers!
Vous pouvez installer l'OpenShift sandboxed containers Operator en utilisant la console web ou l'OpenShift CLI (oc). Avant d'installer l'OpenShift sandboxed containers Operator, vous devez préparer votre cluster OpenShift Container Platform.
3.1. Conditions préalables Copier lienLien copié sur presse-papiers!
Avant d'installer les conteneurs OpenShift sandboxed, assurez-vous que votre cluster OpenShift Container Platform répond aux exigences suivantes :
Votre cluster doit être installé sur une infrastructure bare-metal sur site avec des travailleurs Red Hat Enterprise Linux CoreOS (RHCOS). Vous pouvez utiliser n'importe quelle méthode d'installation, y compris le provisionnement par l'utilisateur, le provisionnement par l'installateur ou l'installation assistée pour déployer votre cluster.
Note- Les conteneurs OpenShift sandboxed ne prennent en charge que les nœuds de travail RHCOS. Les nœuds RHEL ne sont pas pris en charge.
- La virtualisation imbriquée n'est pas prise en charge.
- Vous pouvez installer les conteneurs OpenShift sandboxed sur les instances bare-metal d'Amazon Web Services (AWS). Les instances bare-metal proposées par d'autres fournisseurs de cloud ne sont pas prises en charge.
3.1.1. Ressources nécessaires pour les conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
OpenShift sandboxed containers permet aux utilisateurs d'exécuter des charges de travail sur leurs clusters OpenShift Container Platform à l'intérieur d'un runtime sandboxed (Kata). Chaque pod est représenté par une machine virtuelle (VM). Chaque VM s'exécute dans un processus QEMU et héberge un processus kata-agent qui agit en tant que superviseur pour gérer les charges de travail des conteneurs et les processus s'exécutant dans ces conteneurs. Deux processus supplémentaires ajoutent des frais généraux :
-
containerd-shim-kata-v2est utilisé pour communiquer avec le pod. -
virtiofsdgère l'accès au système de fichiers de l'hôte pour le compte de l'invité.
Chaque VM est configurée avec une quantité de mémoire par défaut. La mémoire supplémentaire est connectée à chaud à la VM pour les conteneurs qui demandent explicitement de la mémoire.
Un conteneur fonctionnant sans ressource mémoire consomme de la mémoire libre jusqu'à ce que la mémoire totale utilisée par la VM atteigne l'allocation par défaut. L'invité et ses tampons d'E/S consomment également de la mémoire.
Si un conteneur se voit attribuer une quantité spécifique de mémoire, cette mémoire est connectée à chaud à la VM avant le démarrage du conteneur.
Lorsqu'une limite de mémoire est spécifiée, la charge de travail est interrompue si elle consomme plus de mémoire que la limite. Si aucune limite de mémoire n'est spécifiée, le noyau s'exécutant sur la VM peut manquer de mémoire. Si le noyau manque de mémoire, il peut mettre fin à d'autres processus sur la VM.
Tailles de mémoire par défaut
Le tableau suivant présente certaines valeurs par défaut pour l'allocation des ressources.
| Ressources | Valeur |
|---|---|
| Mémoire allouée par défaut à une machine virtuelle | 2Gi |
| Utilisation de la mémoire du noyau Linux invité au démarrage | ~110Mi |
| Mémoire utilisée par le processus QEMU (à l'exclusion de la mémoire VM) | ~30Mi |
|
Mémoire utilisée par le processus | ~10Mi |
|
Mémoire utilisée par le processus | ~20Mi |
|
Données du cache du tampon de fichier après l'exécution de | ~300Mi* [1] |
Les tampons de fichiers apparaissent et sont pris en compte à plusieurs endroits :
- Dans l'invité où il apparaît en tant que cache de tampon de fichier.
-
Dans le démon
virtiofsdqui établit la correspondance entre les opérations d'E/S de fichiers autorisées dans l'espace utilisateur. - Dans le processus QEMU en tant que mémoire invitée.
L'utilisation totale de la mémoire est correctement prise en compte par les mesures d'utilisation de la mémoire, qui ne comptent la mémoire qu'une seule fois.
L'overhead pod décrit la quantité de ressources système utilisée par un pod sur un nœud. Vous pouvez obtenir le pod overhead actuel pour le runtime Kata en utilisant oc describe runtimeclass kata comme indiqué ci-dessous.
Exemple :
$ oc describe runtimeclass kata
Exemple de sortie
kind: RuntimeClass
apiVersion: node.k8s.io/v1
metadata:
name: kata
overhead:
podFixed:
memory: "500Mi"
cpu: "500m"
Vous pouvez modifier l'overhead du pod en changeant le champ spec.overhead pour un RuntimeClass. Par exemple, si la configuration que vous exécutez pour vos conteneurs consomme plus de 350Mi de mémoire pour le processus QEMU et les données du noyau invité, vous pouvez modifier l'overhead RuntimeClass pour l'adapter à vos besoins.
Les valeurs de frais généraux par défaut spécifiées sont prises en charge par Red Hat. La modification des valeurs de frais généraux par défaut n'est pas prise en charge et peut entraîner des problèmes techniques.
Lors de l'exécution de tout type d'E/S du système de fichiers dans l'invité, des tampons de fichiers sont alloués dans le noyau de l'invité. Les tampons de fichiers sont également mappés dans le processus QEMU sur l'hôte, ainsi que dans le processus virtiofsd.
Par exemple, si vous utilisez 300Mi de cache de tampon de fichier dans l'invité, QEMU et virtiofsd semblent utiliser 300Mi de mémoire supplémentaire. Cependant, la même mémoire est utilisée dans les trois cas. En d'autres termes, l'utilisation totale de la mémoire n'est que de 300Mi, mappée à trois endroits différents. Ce fait est correctement pris en compte dans le rapport sur l'utilisation de la mémoire.
3.1.2. Vérifier si les nœuds de cluster sont éligibles pour exécuter les conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Avant d'exécuter des conteneurs OpenShift sandboxed, vous pouvez vérifier si les nœuds de votre cluster sont éligibles pour exécuter des conteneurs Kata. Certains nœuds du cluster peuvent ne pas être conformes aux exigences minimales des conteneurs sandboxed. La raison la plus courante de l'inéligibilité d'un nœud est l'absence de support de virtualisation sur le nœud. Si vous tentez d'exécuter des charges de travail en bac à sable sur des nœuds non éligibles, vous rencontrerez des erreurs. Vous pouvez utiliser l'opérateur NFD (Node Feature Discovery) et une ressource NodeFeatureDiscovery pour vérifier automatiquement l'éligibilité des nœuds.
Si vous souhaitez installer le moteur d'exécution Kata sur des nœuds de travail sélectionnés dont vous savez qu'ils sont éligibles, appliquez l'étiquette feature.node.kubernetes.io/runtime.kata=true aux nœuds sélectionnés et définissez checkNodeEligibility: true dans la ressource KataConfig.
Pour installer le moteur d'exécution Kata sur tous les nœuds de travail, définissez checkNodeEligibility: false dans la ressource KataConfig.
Dans ces deux scénarios, il n'est pas nécessaire de créer la ressource NodeFeatureDiscovery. Vous ne devez appliquer manuellement le label feature.node.kubernetes.io/runtime.kata=true que si vous êtes sûr que le nœud est éligible pour exécuter des conteneurs Kata.
La procédure suivante applique l'étiquette feature.node.kubernetes.io/runtime.kata=true à tous les nœuds éligibles et configure la ressource KataConfig pour vérifier l'éligibilité des nœuds.
Conditions préalables
-
Installez le CLI OpenShift (
oc). -
Connectez-vous en tant qu'utilisateur disposant des privilèges
cluster-admin. - Installer l'opérateur NFD (Node Feature Discovery).
Procédure
Créer une ressource
NodeFeatureDiscoverypour détecter les capacités des nœuds adaptés à l'exécution des conteneurs Kata :Enregistrez le YAML suivant dans le fichier
nfd.yaml:apiVersion: nfd.openshift.io/v1 kind: NodeFeatureDiscovery metadata: name: nfd-kata namespace: openshift-nfd spec: operand: image: quay.io/openshift/origin-node-feature-discovery:4.10 imagePullPolicy: Always servicePort: 12000 workerConfig: configData: | sources: custom: - name: "feature.node.kubernetes.io/runtime.kata" matchOn: - cpuId: ["SSE4", "VMX"] loadedKMod: ["kvm", "kvm_intel"] - cpuId: ["SSE4", "SVM"] loadedKMod: ["kvm", "kvm_amd"]Créer la ressource personnalisée (CR)
NodeFeatureDiscovery:$ oc create -f nfd.yamlExemple de sortie
nodefeaturediscovery.nfd.openshift.io/nfd-kata createdUne étiquette
feature.node.kubernetes.io/runtime.kata=trueest appliquée à tous les nœuds de travail qualifiés.
Définissez le champ
checkNodeEligibilitysurtruedans la ressourceKataConfigpour activer la fonctionnalité, par exemple :Enregistrez le YAML suivant dans le fichier
kata-config.yaml:apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: example-kataconfig spec: checkNodeEligibility: trueCréer le CR
KataConfig:$ oc create -f kata-config.yamlExemple de sortie
kataconfig.kataconfiguration.openshift.io/example-kataconfig created
Vérification
Vérifiez que les nœuds admissibles de la grappe sont correctement étiquetés :
$ oc get nodes --selector='feature.node.kubernetes.io/runtime.kata=true'Exemple de sortie
NAME STATUS ROLES AGE VERSION compute-3.example.com Ready worker 4h38m v1.25.0 compute-2.example.com Ready worker 4h35m v1.25.0
3.2. Déployer les charges de travail des conteneurs OpenShift sandboxed à l'aide de la console web Copier lienLien copié sur presse-papiers!
Vous pouvez déployer des workloads OpenShift sandboxed containers à partir de la console web. Tout d'abord, vous devez installer OpenShift sandboxed containers Operator, puis créer la ressource personnalisée (CR) KataConfig. Une fois que vous êtes prêt à déployer une charge de travail dans un conteneur sandboxed, vous devez ajouter manuellement kata en tant que runtimeClassName au fichier YAML de la charge de travail.
3.2.1. Installation de l'Opérateur de conteneurs sandboxés OpenShift à l'aide de la console web Copier lienLien copié sur presse-papiers!
Vous pouvez installer les conteneurs OpenShift sandboxed Operator à partir de la console web OpenShift Container Platform.
Conditions préalables
- Vous avez installé OpenShift Container Platform 4.12.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
- Depuis la perspective Administrator dans la console web, naviguez vers Operators → OperatorHub.
-
Dans le champ Filter by keyword, tapez
OpenShift sandboxed containers. - Sélectionnez la tuile OpenShift sandboxed containers.
- Lisez les informations sur l'opérateur et cliquez sur Install.
Sur la page Install Operator:
- Sélectionnez stable-1.3 dans la liste des options Update Channel disponibles.
Vérifiez que Operator recommended Namespace est sélectionné pour Installed Namespace. Ceci installe l'Opérateur dans l'espace de noms obligatoire
openshift-sandboxed-containers-operator. Si cet espace de noms n'existe pas encore, il est automatiquement créé.NoteLa tentative d'installation de l'Opérateur de conteneurs en bac à sable OpenShift dans un espace de noms autre que
openshift-sandboxed-containers-operatorentraîne l'échec de l'installation.- Vérifiez que Automatic est sélectionné pour Approval Strategy. Automatic est la valeur par défaut, et permet des mises à jour automatiques des conteneurs OpenShift sandboxed lorsqu'une nouvelle version de z-stream est disponible.
- Cliquez sur Install.
L'opérateur OpenShift sandboxed containers est maintenant installé sur votre cluster.
Vérification
- Depuis la perspective Administrator dans la console web, naviguez vers Operators → Installed Operators.
- Vérifier que l'opérateur OpenShift sandboxed containers est listé dans la liste des opérateurs.
3.2.2. Création de la ressource personnalisée KataConfig dans la console web Copier lienLien copié sur presse-papiers!
Vous devez créer une ressource personnalisée (CR) KataConfig pour permettre l'installation de kata en tant que RuntimeClass sur vos nœuds de cluster.
La création de KataConfig CR entraîne le redémarrage automatique des nœuds de travail. Le redémarrage peut prendre de 10 à plus de 60 minutes. Les facteurs qui ralentissent le redémarrage sont les suivants :
- Un déploiement plus important d'OpenShift Container Platform avec un plus grand nombre de nœuds de travail.
- Activation du BIOS et de l'utilitaire de diagnostic.
- Déploiement sur un disque dur plutôt que sur un SSD.
- Déploiement sur des nœuds physiques tels que le métal nu, plutôt que sur des nœuds virtuels.
- Une unité centrale et un réseau lents.
Conditions préalables
- Vous avez installé OpenShift Container Platform 4.12 sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. - Vous avez installé l'Opérateur de conteneurs sandboxés OpenShift.
Kata est installé par défaut sur tous les nœuds de travail. Si vous souhaitez installer kata en tant que RuntimeClass uniquement sur des nœuds spécifiques, vous pouvez ajouter des étiquettes à ces nœuds, puis définir l'étiquette dans le CR KataConfig lorsque vous le créez.
Procédure
- Depuis la perspective Administrator dans la console web, naviguez vers Operators → Installed Operators.
- Sélectionnez l'Opérateur de conteneurs sandboxés OpenShift dans la liste des opérateurs.
- Dans l'onglet KataConfig, cliquez sur Create KataConfig.
Dans la page Create KataConfig, entrez les détails suivants :
-
Name: Entrez un nom pour la ressource
KataConfig. Par défaut, le nom est défini commeexample-kataconfig. -
Labels (Facultatif) : Saisissez tout attribut pertinent permettant d'identifier la ressource
KataConfig. Chaque étiquette représente une paire clé-valeur. -
checkNodeEligibility(Facultatif) : Cochez cette case pour utiliser l'opérateur de découverte des fonctionnalités du nœud (NFD) afin de détecter l'éligibilité du nœud à l'exécution dekataen tant queRuntimeClass. Pour plus d'informations, voir "Checking whether cluster nodes are eligible to run OpenShift sandboxed containers" (Vérification de l'éligibilité des nœuds de cluster à l'exécution des conteneurs OpenShift en bac à sable). kataConfigPoolSelector: Par défaut,kataest installé en tant queRuntimeClasssur tous les nœuds. Si vous souhaitez installerkataen tant queRuntimeClassuniquement sur certains nœuds, vous devez ajouter un matchExpression:-
Élargir la
kataConfigPoolSelectordomaine. -
Dans le
kataConfigPoolSelectordéveloppez matchExpressions. Il s'agit d'une liste d'exigences relatives aux sélecteurs d'étiquettes. - Cliquez sur Add matchExpressions.
- Dans le champ key, ajoutez la clé d'étiquette à laquelle le sélecteur s'applique.
-
Dans le champ operator, ajoutez la relation de la clé aux valeurs de l'étiquette. Les opérateurs valides sont
In,NotIn,ExistsetDoesNotExist. - Développez la zone values, puis cliquez sur Add value.
-
Dans le champ Value, entrez
trueoufalsepour la valeur de l'étiquette key.
-
Élargir la
-
logLevel: Définir le niveau des données de journal récupérées pour les nœuds exécutantkataen tant queRuntimeClass. Pour plus d'informations, voir "Collecting OpenShift sandboxed containers data" (Collecte des données des conteneurs en bac à sable OpenShift).
-
Name: Entrez un nom pour la ressource
- Cliquez sur Create.
Le nouveau CR KataConfig est créé et commence à installer kata en tant que RuntimeClass sur les nœuds de travail. Attendez la fin de l'installation de kata et le redémarrage des nœuds de travail avant de passer à l'étape suivante.
OpenShift sandboxed containers installe Kata uniquement en tant que runtime secondaire et optionnel sur le cluster et non en tant que runtime principal.
Vérification
-
Dans l'onglet KataConfig, sélectionnez le nouveau CR
KataConfig. - Dans la page KataConfig, sélectionnez l'onglet YAML.
Contrôler le champ installationStatus dans le statut.
Un message apparaît à chaque mise à jour. Cliquez sur Reload pour voir le CR
KataConfigmis à jour.Lorsque la valeur de Completed nodes est égale au nombre de nœuds de travail ou de nœuds étiquetés, l'installation est terminée. L'état contient également une liste des nœuds où l'installation est terminée.
3.2.3. Déploiement d'une charge de travail dans un conteneur en bac à sable à l'aide de la console web Copier lienLien copié sur presse-papiers!
OpenShift sandboxed containers installe Kata en tant que runtime secondaire et optionnel sur votre cluster, et non en tant que runtime principal.
Pour déployer une charge de travail modélisée par un pod dans un conteneur en bac à sable, vous devez ajouter manuellement kata en tant que runtimeClassName au fichier YAML de la charge de travail.
Conditions préalables
- Vous avez installé OpenShift Container Platform 4.12 sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. - Vous avez installé l'Opérateur de conteneurs sandboxés OpenShift.
-
Vous avez créé une ressource personnalisée (CR)
KataConfig.
Procédure
- Dans la perspective Administrator de la console Web, développez Workloads et sélectionnez le type de charge de travail que vous souhaitez créer.
- Dans la page de la charge de travail, cliquez sur pour créer la charge de travail.
Dans le fichier YAML pour la charge de travail, dans le champ spec où le conteneur est listé, ajoutez
runtimeClassName: kata.Exemple pour Pod
apiVersion: v1 kind: Pod metadata: name: example labels: app: httpd namespace: openshift-sandboxed-containers-operator spec: runtimeClassName: kata containers: - name: httpd image: 'image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest' ports: - containerPort: 8080Exemple de déploiement
apiVersion: apps/v1 kind: Deployment metadata: name: example namespace: openshift-sandboxed-containers-operator spec: selector: matchLabels: app: httpd replicas: 3 template: metadata: labels: app: httpd spec: runtimeClassName: kata containers: - name: httpd image: >- image-registry.openshift-image-registry.svc:5000/openshift/httpd:latest ports: - containerPort: 8080- Cliquez sur Save.
OpenShift Container Platform crée la charge de travail et commence à la planifier.
3.3. Déployer les charges de travail des conteneurs OpenShift sandboxed à l'aide de la CLI Copier lienLien copié sur presse-papiers!
Vous pouvez déployer des charges de travail de conteneurs OpenShift sandboxed à l'aide de la CLI. Tout d'abord, vous devez installer OpenShift sandboxed containers Operator, puis créer la ressource personnalisée KataConfig. Une fois que vous êtes prêt à déployer une charge de travail dans un conteneur sandboxed, vous devez ajouter kata en tant que runtimeClassName au fichier YAML de la charge de travail.
3.3.1. Installation de l'Opérateur de conteneurs sandboxés OpenShift à l'aide de la CLI Copier lienLien copié sur presse-papiers!
Vous pouvez installer les conteneurs OpenShift sandboxed Operator en utilisant le CLI de OpenShift Container Platform.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. Vous avez souscrit au catalogue de conteneurs en bac à sable d'OpenShift.
NoteL'abonnement au catalogue de conteneurs OpenShift sandboxed donne accès à l'espace de noms
openshift-sandboxed-containers-operatorà l'opérateur de conteneurs OpenShift sandboxed.
Procédure
Créez l'objet
Namespacepour l'Opérateur de conteneurs en bac à sable OpenShift.Créez un fichier YAML de l'objet
Namespacequi contient le manifeste suivant :apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operatorCréer l'objet
Namespace:$ oc create -f Namespace.yaml
Créez l'objet
OperatorGrouppour l'Opérateur de conteneurs en bac à sable OpenShift.Créez un fichier YAML de l'objet
OperatorGroupqui contient le manifeste suivant :apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: targetNamespaces: - openshift-sandboxed-containers-operatorCréer l'objet
OperatorGroup:$ oc create -f OperatorGroup.yaml
Créez l'objet
Subscriptionpour abonnerNamespaceà l'opérateur de conteneurs en bac à sable d'OpenShift.Créez un fichier YAML de l'objet
Subscriptionqui contient le manifeste suivant :apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-sandboxed-containers-operator namespace: openshift-sandboxed-containers-operator spec: channel: "stable-1.3" installPlanApproval: Automatic name: sandboxed-containers-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: sandboxed-containers-operator.v1.3.2Créer l'objet
Subscription:$ oc create -f Subscription.yaml
L'opérateur OpenShift sandboxed containers est maintenant installé sur votre cluster.
Tous les noms de fichiers d'objets énumérés ci-dessus sont des suggestions. Vous pouvez créer les fichiers YAML des objets en utilisant d'autres noms.
Vérification
S'assurer que l'opérateur est correctement installé :
$ oc get csv -n openshift-sandboxed-containers-operatorExemple de sortie
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.3.2 1.3.1 Succeeded
3.3.2. Création de la ressource personnalisée KataConfig à l'aide du CLI Copier lienLien copié sur presse-papiers!
Vous devez créer une ressource personnalisée (CR) KataConfig pour installer kata en tant que RuntimeClass sur vos nœuds. La création de la CR KataConfig déclenche l'opération suivante de l'opérateur de conteneurs en bac à sable OpenShift :
-
Installez les extensions RHCOS nécessaires, telles que QEMU et
kata-containers, sur votre nœud RHCOS. -
Assurez-vous que le runtime CRI-O est configuré avec les bons gestionnaires de runtime
kata. -
Créez un CR
RuntimeClassnommékataavec une configuration par défaut. Cela permet aux utilisateurs de configurer les charges de travail pour qu'elles utilisentkatacomme durée d'exécution en faisant référence à la CR dans le champRuntimeClassName. Ce CR spécifie également la surcharge de ressources pour le runtime.
Kata est installé par défaut sur tous les nœuds de travail. Si vous souhaitez installer kata en tant que RuntimeClass uniquement sur des nœuds spécifiques, vous pouvez ajouter des étiquettes à ces nœuds, puis définir l'étiquette dans le CR KataConfig lorsque vous le créez.
Conditions préalables
- Vous avez installé OpenShift Container Platform 4.12 sur votre cluster.
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. - Vous avez installé l'Opérateur de conteneurs sandboxés OpenShift.
La création de KataConfig CR entraîne le redémarrage automatique des nœuds de travail. Le redémarrage peut prendre de 10 à plus de 60 minutes. Les facteurs qui ralentissent le redémarrage sont les suivants :
- Un déploiement plus important d'OpenShift Container Platform avec un plus grand nombre de nœuds de travail.
- Activation du BIOS et de l'utilitaire de diagnostic.
- Déploiement sur un disque dur plutôt que sur un SSD.
- Déploiement sur des nœuds physiques tels que le métal nu, plutôt que sur des nœuds virtuels.
- Une unité centrale et un réseau lents.
Procédure
Créer un fichier YAML avec le manifeste suivant :
apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: checkNodeEligibility: false1 logLevel: info- 1
- Définissez "checkNodeEligibility" à
truepour détecter l'éligibilité du nœud à exécuterkataen tant queRuntimeClass. Pour plus d'informations, voir "Checking whether cluster nodes are eligible to run OpenShift sandboxed containers" (Vérifier si les nœuds du cluster sont éligibles à l'exécution des conteneurs OpenShift).
(Facultatif) Si vous souhaitez installer
kataen tant queRuntimeClassuniquement sur certains nœuds, créez un fichier YAML qui inclut l'étiquette dans le manifeste :apiVersion: kataconfiguration.openshift.io/v1 kind: KataConfig metadata: name: cluster-kataconfig spec: checkNodeEligibility: false logLevel: info kataConfigPoolSelector: matchLabels: <label_key>: '<label_value>'1 - 1
- Les étiquettes dans
kataConfigPoolSelectorne prennent en charge que des valeurs uniques ; la syntaxe denodeSelectorn'est pas prise en charge.
Créer la ressource
KataConfig:oc create -f <file name>.yaml
Le nouveau CR KataConfig est créé et commence à installer kata en tant que RuntimeClass sur les nœuds de travail. Attendez la fin de l'installation de kata et le redémarrage des nœuds de travail avant de passer à l'étape suivante.
OpenShift sandboxed containers installe Kata uniquement en tant que runtime secondaire et optionnel sur le cluster et non en tant que runtime principal.
Vérification
Contrôler la progression de l'installation :
$ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"Une fois que la valeur de Is In Progress apparaît comme
false, l'installation est terminée.
3.3.3. Déployer une charge de travail dans un conteneur en bac à sable à l'aide de la CLI Copier lienLien copié sur presse-papiers!
OpenShift sandboxed containers installe Kata en tant que runtime secondaire et optionnel sur votre cluster, et non en tant que runtime principal.
Pour déployer une charge de travail modélisée par un pod dans un conteneur en bac à sable, vous devez ajouter kata en tant que runtimeClassName au fichier YAML de la charge de travail.
Conditions préalables
- Vous avez installé OpenShift Container Platform 4.12 sur votre cluster.
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. - Vous avez installé l'Opérateur de conteneurs sandboxés OpenShift.
-
Vous avez créé une ressource personnalisée (CR)
KataConfig.
Procédure
Ajouter
runtimeClassName: kataà n'importe quel objet modélisé par un pod :-
Podobjets -
ReplicaSetobjets -
ReplicationControllerobjets -
StatefulSetobjets -
Deploymentobjets -
DeploymentConfigobjets
-
Exemple pour les objets Pod
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: kata
Exemple d'objets de déploiement
apiVersion: apps/v1
kind: Deployment
metadata:
name: mypod
labels:
app: mypod
spec:
replicas: 3
selector:
matchLabels:
app: mypod
template:
metadata:
labels:
app: mypod
spec:
runtimeClassName: kata
containers:
- name: mypod
image: myImage
OpenShift Container Platform crée la charge de travail et commence à la planifier.
Vérification
-
Inspectez le champ
runtimeClassNamesur un objet pod-templated. Si le champruntimeClassNameestkata, la charge de travail s'exécute sur un conteneur OpenShift sandboxed.
Chapitre 4. Surveillance des conteneurs OpenShift en bac à sable Copier lienLien copié sur presse-papiers!
Vous pouvez utiliser la console web d'OpenShift Container Platform pour surveiller les mesures liées à l'état de santé de vos charges de travail et nœuds en bac à sable.
OpenShift sandboxed containers dispose d'un tableau de bord préconfiguré disponible dans la console web, et les administrateurs peuvent également accéder et interroger les métriques brutes via Prometheus.
4.1. A propos des métriques des conteneurs sandboxés d'OpenShift Copier lienLien copié sur presse-papiers!
Les métriques des conteneurs sandboxed d'OpenShift permettent aux administrateurs de surveiller le fonctionnement de leurs conteneurs sandboxed. Vous pouvez interroger ces métriques dans l'interface Metrics UI de la console web.
Les métriques des conteneurs OpenShift sandboxed sont collectées pour les catégories suivantes :
- Mesures de l'agent Kata
-
Les métriques de l'agent Kata affichent des informations sur le processus de l'agent Kata qui s'exécute dans la VM intégrée à vos conteneurs en bac à sable. Ces mesures comprennent des données provenant de
/proc/<pid>/[io, stat, status]. - Métriques du système d'exploitation invité de Kata
-
Les mesures du système d'exploitation invité de Kata affichent les données du système d'exploitation invité qui s'exécute dans vos conteneurs en bac à sable. Ces mesures comprennent des données provenant de
/proc/[stats, diskstats, meminfo, vmstats]et/proc/net/dev. - Mesures de l'hyperviseur
-
Les métriques de l'hyperviseur affichent des données concernant l'hyperviseur qui exécute la VM intégrée dans vos conteneurs en bac à sable. Ces mesures comprennent principalement des données provenant de
/proc/<pid>/[io, stat, status]. - Les indicateurs de suivi des données
- Le moniteur Kata est le processus qui recueille les données métriques et les met à la disposition de Prometheus. Les métriques du moniteur de kata affichent des informations détaillées sur l'utilisation des ressources du processus de moniteur de kata lui-même. Ces métriques comprennent également des compteurs issus de la collecte de données de Prometheus.
- Kata containerd shim v2 metrics
-
Les métriques de Kata containerd shim v2 affichent des informations détaillées sur le processus kata shim. Ces mesures comprennent des données provenant de
/proc/<pid>/[io, stat, status]et des mesures détaillées de l'utilisation des ressources.
4.2. Visualisation des métriques pour les conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Vous pouvez accéder aux métriques pour les conteneurs OpenShift sandboxed dans la page Metrics de la console web.
Conditions préalables
- Vous avez installé OpenShift Container Platform 4.12.
- Vous avez installé des conteneurs OpenShift sandboxed.
-
Vous avez accès au cluster en tant qu'utilisateur avec le rôle
cluster-adminou avec des permissions de visualisation pour tous les projets.
Procédure
- Depuis la perspective Administrator dans la console web, naviguez vers Observe → Metrics.
Dans le champ de saisie, entrez la requête pour la mesure que vous souhaitez observer.
Toutes les mesures relatives aux kata commencent par kata. En tapant kata, vous obtiendrez une liste de toutes les mesures de kata disponibles.
Les données de votre requête sont visualisées sur la page.
4.3. Visualisation du tableau de bord des conteneurs sandboxés d'OpenShift Copier lienLien copié sur presse-papiers!
Vous pouvez accéder au tableau de bord des conteneurs OpenShift sandboxed dans la page Dashboards de la console web.
Conditions préalables
- Vous avez installé OpenShift Container Platform 4.12.
- Vous avez installé des conteneurs OpenShift sandboxed.
-
Vous avez accès au cluster en tant qu'utilisateur avec le rôle
cluster-adminou avec des permissions de visualisation pour tous les projets.
Procédure
- Depuis la perspective Administrator dans la console web, naviguez vers Observe → Dashboards.
- Dans la liste déroulante Dashboard, sélectionnez le tableau de bord Sandboxed Containers.
Optional: Select a time range for the graphs in the Time Range list.
- Select a pre-defined time period.
Set a custom time range by selecting Custom time range in the Time Range list.
- Définissez la date et l'intervalle de temps pour les données que vous souhaitez consulter.
- Click Save to save the custom time range.
- Optional: Select a Refresh Interval.
Le tableau de bord apparaît sur la page avec les mesures suivantes de la catégorie Kata guest OS :
- Nombre de machines virtuelles en cours d'exécution
- Affiche le nombre total de conteneurs en bac à sable en cours d'exécution sur votre cluster.
- Utilisation de l'unité centrale (par VM)
- Affiche l'utilisation du processeur pour chaque conteneur en bac à sable.
- Utilisation de la mémoire (par VM)
- Affiche l'utilisation de la mémoire pour chaque conteneur en bac à sable.
Hover over each of the graphs within a dashboard to display detailed information about specific items.
4.4. Ressources supplémentaires Copier lienLien copié sur presse-papiers!
- Pour plus d'informations sur la collecte de données à des fins d'assistance, voir Collecte de données sur votre cluster.
Chapitre 5. Désinstallation des conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Vous pouvez désinstaller les conteneurs OpenShift sandboxed en utilisant la console web OpenShift Container Platform ou OpenShift CLI (oc). Les deux procédures sont expliquées ci-dessous.
5.1. Désinstallation des conteneurs OpenShift sandboxed à l'aide de la console web Copier lienLien copié sur presse-papiers!
Utilisez la console web de OpenShift Container Platform pour supprimer les pods, ressources et espaces de noms des conteneurs OpenShift sandboxed concernés.
5.1.1. Suppression des pods de conteneurs sandboxés OpenShift à l'aide de la console web Copier lienLien copié sur presse-papiers!
Pour désinstaller les conteneurs OpenShift sandboxed, vous devez d'abord supprimer tous les pods en cours d'exécution qui utilisent kata comme runtimeClass.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. -
Vous avez une liste des pods qui utilisent
katacommeruntimeClass.
Procédure
- Dans la perspective de Administrator, naviguez vers Workloads → Pods.
- Recherchez le pod que vous souhaitez supprimer en utilisant le champ Search by name.
- Cliquez sur le nom du pod pour l'ouvrir.
-
Sur la page Details, vérifiez que
kataest affiché pour Runtime class. - Cliquez sur le menu Actions et sélectionnez Delete Pod.
- Cliquez sur Delete dans la fenêtre de confirmation.
5.1.2. Suppression de la ressource personnalisée KataConfig à l'aide de la console web Copier lienLien copié sur presse-papiers!
La suppression de la ressource personnalisée (CR) KataConfig supprime et désinstalle le moteur d'exécution kata et ses ressources connexes de votre cluster.
La suppression de KataConfig CR entraîne automatiquement le redémarrage des nœuds de travail. Le redémarrage peut prendre de 10 à plus de 60 minutes. Les facteurs qui ralentissent le redémarrage sont les suivants :
- Un déploiement plus important d'OpenShift Container Platform avec un plus grand nombre de nœuds de travail.
- Activation du BIOS et de l'utilitaire de diagnostic.
- Déploiement sur un disque dur plutôt que sur un SSD.
- Déploiement sur des nœuds physiques tels que le métal nu, plutôt que sur des nœuds virtuels.
- Une unité centrale et un réseau lents.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. -
Vous n'avez pas de pods en cours d'exécution qui utilisent
katacommeruntimeClass.
Procédure
- Dans la perspective de Administrator, naviguez vers Operators → Installed Operators.
- Recherchez l'opérateur de conteneurs OpenShift sandboxed en utilisant le champ Search by name.
- Cliquez sur l'opérateur pour l'ouvrir, puis sélectionnez l'onglet KataConfig.
-
Cliquez sur le menu Options
pour la ressource KataConfig, puis sélectionnez DeleteKataConfig. - Cliquez sur Delete dans la fenêtre de confirmation.
Attendez que le moteur d'exécution et les ressources de kata soient désinstallés et que les nœuds de travail redémarrent avant de passer à l'étape suivante.
5.1.3. Suppression des conteneurs OpenShift sandboxed Operator à l'aide de la console web Copier lienLien copié sur presse-papiers!
La suppression de l'opérateur de conteneurs OpenShift sandboxed supprime l'abonnement au catalogue, le groupe d'opérateurs et la version du service de cluster (CSV) pour cet opérateur.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
- Dans la perspective de Administrator, naviguez vers Operators → Installed Operators.
- Recherchez l'opérateur de conteneurs OpenShift sandboxed en utilisant le champ Search by name.
-
Cliquez sur le menu Options
de l'opérateur et sélectionnez Uninstall Operator.
- Cliquez sur Uninstall dans la fenêtre de confirmation.
5.1.4. Suppression de l'espace de noms des conteneurs OpenShift sandboxed à l'aide de la console web Copier lienLien copié sur presse-papiers!
Après avoir exécuté les commandes précédentes, votre cluster est restauré dans l'état où il se trouvait avant le processus d'installation. Vous pouvez maintenant révoquer l'accès à l'espace de noms de l'opérateur en supprimant l'espace de noms openshift-sandboxed-containers-operator.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
- Dans la perspective de Administrator, naviguez vers Administration → Namespaces.
-
Recherchez l'espace de noms
openshift-sandboxed-containers-operatoren utilisant le champ Search by name. Cliquez sur le menu Options
pour l'espace de noms et sélectionnez Delete Namespace.
NoteSi l'option Delete Namespace n'est pas disponible, vous n'êtes pas autorisé à supprimer l'espace de noms.
-
Dans le volet Delete Namespace, saisissez
openshift-sandboxed-containers-operatoret cliquez sur Delete. - Cliquez sur Delete.
5.1.5. Suppression de la définition de la ressource personnalisée KataConfig à l'aide de la console Web Copier lienLien copié sur presse-papiers!
La définition de ressource personnalisée (CRD) KataConfig vous permet de définir la CR KataConfig. Pour terminer le processus de désinstallation, supprimez le CRD KataConfig de votre cluster.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. -
Vous avez supprimé le
KataConfigCR de votre cluster. - Vous avez supprimé les conteneurs OpenShift sandboxed Operator de votre cluster.
Procédure
- Dans la perspective de Administrator, naviguez vers Administration → CustomResourceDefinitions.
-
Recherchez
KataConfigen utilisant le champ Search by name. -
Cliquez sur le menu Options
pour le CRD KataConfig, puis sélectionnez Delete CustomResourceDefinition. - Cliquez sur Delete dans la fenêtre de confirmation.
-
Attendez que le CRD
KataConfigdisparaisse de la liste. Cela peut prendre plusieurs minutes.
5.2. Désinstallation des conteneurs OpenShift sandboxed à l'aide de la CLI Copier lienLien copié sur presse-papiers!
Vous pouvez désinstaller les conteneurs OpenShift sandboxed en utilisant l'interface de ligne de commande (CLI) de OpenShift Container Platform. Suivez les étapes ci-dessous dans l'ordre où elles sont présentées.
5.2.1. Suppression des pods de conteneurs sandboxés OpenShift à l'aide de l'interface CLI Copier lienLien copié sur presse-papiers!
Pour désinstaller les conteneurs OpenShift sandboxed, vous devez d'abord supprimer tous les pods en cours d'exécution qui utilisent kata comme runtimeClass.
Conditions préalables
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez installé le processeur JSON en ligne de commande (
jq).
Procédure
Recherchez les pods qui utilisent
katacommeruntimeClassen exécutant la commande suivante :$ oc get pods -A -o json | jq -r '.items[] | select(.spec.runtimeClassName == "kata").metadata.name'Pour supprimer chaque module, exécutez la commande suivante :
oc delete pod <pod-name>
5.2.2. Suppression de la ressource personnalisée KataConfig à l'aide du CLI Copier lienLien copié sur presse-papiers!
Supprimez et désinstallez le runtime kata et toutes ses ressources associées, telles que CRI-O config et RuntimeClass, de votre cluster.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
La suppression de KataConfig CR entraîne automatiquement le redémarrage des nœuds de travail. Le redémarrage peut prendre de 10 à plus de 60 minutes. Les facteurs qui ralentissent le redémarrage sont les suivants :
- Un déploiement plus important d'OpenShift Container Platform avec un plus grand nombre de nœuds de travail.
- Activation du BIOS et de l'utilitaire de diagnostic.
- Déploiement sur un disque dur plutôt que sur un SSD.
- Déploiement sur des nœuds physiques tels que le métal nu, plutôt que sur des nœuds virtuels.
- Une unité centrale et un réseau lents.
Procédure
Supprimez la ressource personnalisée
KataConfigen exécutant la commande suivante :oc delete kataconfig <KataConfig_CR_Name>
L'opérateur OpenShift sandboxed containers supprime toutes les ressources qui ont été initialement créées pour activer le runtime sur votre cluster.
Pendant la suppression, la CLI cesse de répondre jusqu'à ce que tous les nœuds de travail redémarrent. Attendez la fin du processus avant de procéder à la vérification ou de passer à la procédure suivante.
Vérification
Pour vérifier que la ressource personnalisée
KataConfiga été supprimée, exécutez la commande suivante :oc get kataconfig <KataConfig_CR_Name>Exemple de sortie
No KataConfig instances exist
5.2.3. Suppression des conteneurs OpenShift sandboxed Operator à l'aide du CLI Copier lienLien copié sur presse-papiers!
Supprimez l'opérateur de conteneurs en bac à sable OpenShift de votre cluster en supprimant l'abonnement de l'opérateur, le groupe de l'opérateur, la version de service du cluster (CSV) et l'espace de noms.
Conditions préalables
- OpenShift Container Platform 4.10 est installé sur votre cluster.
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez installé le processeur JSON en ligne (
jq). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
Récupérez le nom de la version du service de cluster (CSV) pour les conteneurs OpenShift sandboxed à partir de l'abonnement en exécutant la commande suivante :
CSV_NAME=$(oc get csv -n openshift-sandboxed-containers-operator -o=custom-columns=:metadata.name)Supprimez l'abonnement OpenShift sandboxed containers Operator de Operator Lifecyle Manager (OLM) en exécutant la commande suivante :
$ oc delete subscription sandboxed-containers-operator -n openshift-sandboxed-containers-operatorSupprimez le nom CSV pour les conteneurs OpenShift sandboxed en exécutant la commande suivante :
$ oc delete csv ${CSV_NAME} -n openshift-sandboxed-containers-operatorRécupérez le nom du groupe d'opérateurs des conteneurs sandboxés d'OpenShift en exécutant la commande suivante :
$ OG_NAME=$(oc get operatorgroup -n openshift-sandboxed-containers-operator -o=jsonpath={..name})Supprimez le nom du groupe d'opérateurs des conteneurs OpenShift sandboxed en exécutant la commande suivante :
$ oc delete operatorgroup ${OG_NAME} -n openshift-sandboxed-containers-operatorSupprimez l'espace de noms des conteneurs OpenShift sandboxed en exécutant la commande suivante :
$ oc delete namespace openshift-sandboxed-containers-operator
5.2.4. Suppression de la définition de la ressource personnalisée KataConfig à l'aide de la CLI Copier lienLien copié sur presse-papiers!
La définition de ressource personnalisée (CRD) KataConfig vous permet de définir la CR KataConfig. Supprimez le CRD KataConfig de votre cluster.
Conditions préalables
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin. -
Vous avez supprimé le
KataConfigCR de votre cluster. - Vous avez supprimé les conteneurs OpenShift sandboxed Operator de votre cluster.
Procédure
Supprimez le CRD
KataConfigen exécutant la commande suivante :$ oc delete crd kataconfigs.kataconfiguration.openshift.io
Vérification
Pour vérifier que le CRD
KataConfigest supprimé, exécutez la commande suivante :$ oc get crd kataconfigs.kataconfiguration.openshift.ioExemple de sortie
Unknown CR KataConfig
Chapitre 6. Mise à jour des conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
La mise à jour des composants des conteneurs OpenShift sandboxed se compose des trois étapes suivantes :
-
Mise à jour d'OpenShift Container Platform pour mettre à jour le runtime
Kataet ses dépendances. - Mise à jour de l'Opérateur de conteneurs sandboxés OpenShift pour mettre à jour l'abonnement de l'Opérateur.
-
Correction manuelle de la ressource personnalisée (CR)
KataConfigpour mettre à jour les pods de surveillance.
Vous pouvez mettre à jour OpenShift Container Platform avant ou après la mise à jour d'OpenShift sandboxed containers Operator, à l'exception de ce qui suit. Appliquez toujours le correctif KataConfig immédiatement après la mise à niveau d'OpenShift sandboxed containers Operator.
Si vous mettez à jour OpenShift Container Platform 4.11 avec OpenShift sandboxed containers 1.3, l'ordre recommandé est de mettre à jour OpenShift sandboxed containers de 1.2 à 1.3, puis de mettre à jour OpenShift Container Platform de 4.10 à 4.11.
6.1. Mise à jour des ressources des conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Les ressources des conteneurs OpenShift sont déployées sur le cluster à l'aide des extensions Red Hat Enterprise Linux CoreOS (RHCOS).
L'extension RHCOS sandboxed containers contient les composants nécessaires à l'exécution de Kata Containers, tels que le runtime de Kata Containers, l'hyperviseur QEMU et d'autres dépendances. Vous mettez à jour l'extension en mettant à jour le cluster vers une nouvelle version d'OpenShift Container Platform.
Pour plus d'informations sur la mise à niveau d'OpenShift Container Platform, voir Mise à jour des clusters.
6.2. Mise à jour des conteneurs OpenShift sandboxed Operator Copier lienLien copié sur presse-papiers!
Utilisez Operator Lifecycle Manager (OLM) pour mettre à niveau les conteneurs OpenShift sandboxed Operator manuellement ou automatiquement. Le choix de la mise à niveau manuelle ou automatique lors du déploiement initial détermine le mode de mise à niveau futur. Pour les mises à niveau manuelles, la console web affiche les mises à jour disponibles qui peuvent être installées par l'administrateur du cluster.
Pour plus d'informations sur la mise à jour de l'opérateur OpenShift sandboxed containers dans Operator Lifecycle Manager (OLM), voir Mise à jour des opérateurs installés.
6.3. Mise à jour des pods de surveillance des conteneurs en bac à sable d'OpenShift Copier lienLien copié sur presse-papiers!
Après avoir mis à jour les conteneurs OpenShift sandboxed, vous devez mettre à jour l'image du moniteur dans le CR KataConfig pour mettre à jour les pods du moniteur. Sinon, les pods de surveillance continueront à exécuter les images de la version précédente.
Vous pouvez effectuer la mise à jour à l'aide de la console web ou de l'interface CLI.
6.3.1. Mise à niveau des modules de surveillance à l'aide de la console web Copier lienLien copié sur presse-papiers!
Le fichier YAML KataConfig dans OpenShift Container Platform contient le numéro de version de l'image du moniteur. Mettez à jour le numéro de version avec la version correcte.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
- Dans la perspective Administrator d'OpenShift Container Platform, naviguez vers Operators → Installed Operators.
- Sélectionnez le site OpenShift sandboxed containers Operator et allez dans l'onglet KataConfig.
-
Recherchez la ressource
KataConfigen utilisant le champ Search by name. Le nom par défaut de la ressourceKataConfigest example-kataconfig. -
Sélectionnez la ressource
KataConfiget allez dans l'onglet KataConfig. Modifier le numéro de version pour
kataMonitorImage:checkNodeEligibility: false kataConfigPoolSelector: null kataMonitorImage: 'registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0'- Cliquez sur Save.
6.3.2. Mise à niveau des modules de surveillance à l'aide de la CLI Copier lienLien copié sur presse-papiers!
Vous pouvez corriger manuellement l'image du moniteur dans le CR KataConfig pour mettre à jour les pods du moniteur.
Conditions préalables
- OpenShift Container Platform 4.12 est installé sur votre cluster.
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
Dans le CLI de OpenShift Container Platform, exécutez la commande suivante :
$ oc patch kataconfig <kataconfig_name> --type merge --patch '{"spec":{"kataMonitorImage":"registry.redhat.io/openshift-sandboxed-containers/osc-monitor-rhel8:1.3.0"}}'où :
<kataconfig_name>: : spécifie le nom de votre fichier de configuration Kata, par exempleexample-kataconfig.
Chapitre 7. Collecte des données des conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Lors du dépannage des conteneurs OpenShift sandboxed, vous pouvez ouvrir un dossier de support et fournir des informations de débogage à l'aide de l'outil must-gather.
Si vous êtes administrateur d'un cluster, vous pouvez également consulter les journaux de votre côté, ce qui vous permet d'obtenir un niveau de détail plus important.
7.1. Collecte des données des conteneurs sandboxés OpenShift pour le support Red Hat Copier lienLien copié sur presse-papiers!
Lorsque vous ouvrez un dossier d'assistance, il est utile de fournir des informations de débogage sur votre cluster à l'équipe d'assistance de Red Hat.
L'outil must-gather vous permet de collecter des informations de diagnostic sur votre cluster OpenShift Container Platform, y compris les machines virtuelles et d'autres données liées aux conteneurs OpenShift sandboxed.
Pour une assistance rapide, fournissez des informations de diagnostic pour OpenShift Container Platform et les conteneurs OpenShift sandboxed.
7.1.1. À propos de l'outil de collecte obligatoire Copier lienLien copié sur presse-papiers!
La commande CLI oc adm must-gather recueille les informations de votre cluster les plus susceptibles d'être nécessaires au débogage des problèmes, notamment
- Définitions des ressources
- Journaux de service
Par défaut, la commande oc adm must-gather utilise l'image du plugin par défaut et écrit dans ./must-gather.local.
Vous pouvez également recueillir des informations spécifiques en exécutant la commande avec les arguments appropriés, comme décrit dans les sections suivantes :
Pour collecter des données relatives à une ou plusieurs caractéristiques spécifiques, utilisez l'argument
--imageavec une image, comme indiqué dans la section suivante.Par exemple :
$ oc adm must-gather --image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel8:v4.12.0Pour collecter les journaux d'audit, utilisez l'argument
-- /usr/bin/gather_audit_logs, comme décrit dans la section suivante.Par exemple :
$ oc adm must-gather -- /usr/bin/gather_audit_logsNoteLes journaux d'audit ne sont pas collectés dans le cadre de l'ensemble d'informations par défaut afin de réduire la taille des fichiers.
Lorsque vous exécutez oc adm must-gather, un nouveau module portant un nom aléatoire est créé dans un nouveau projet sur le cluster. Les données sont collectées sur ce module et enregistrées dans un nouveau répertoire commençant par must-gather.local. Ce répertoire est créé dans le répertoire de travail actuel.
Par exemple :
NAMESPACE NAME READY STATUS RESTARTS AGE
...
openshift-must-gather-5drcj must-gather-bklx4 2/2 Running 0 72s
openshift-must-gather-5drcj must-gather-s8sdh 2/2 Running 0 72s
...
Pour collecter les données des conteneurs OpenShift sandboxed avec must-gather, vous devez spécifier l'image des conteneurs OpenShift sandboxed :
--image=registry.redhat.io/openshift-sandboxed-containers/osc-must-gather-rhel8:1.3.0
7.2. A propos des données de log des conteneurs sandboxés d'OpenShift Copier lienLien copié sur presse-papiers!
Lorsque vous collectez des données de log sur votre cluster, les fonctionnalités et objets suivants sont associés aux conteneurs OpenShift sandboxed :
- Tous les espaces de noms et leurs objets enfants qui appartiennent à des ressources de conteneurs OpenShift sandboxed
- Tous les conteneurs OpenShift sandboxed custom resource definitions (CRDs)
Les journaux des composants des conteneurs en bac à sable OpenShift suivants sont collectés pour chaque pod fonctionnant avec le moteur d'exécution kata:
- Journal de bord de l'agent Kata
- Journaux d'exécution de Kata
- Journaux QEMU
- Journaux d'audit
- Registres CRI-O
7.3. Activation des journaux de débogage pour les conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
En tant qu'administrateur de cluster, vous pouvez collecter un niveau plus détaillé de logs pour les conteneurs OpenShift sandboxed. Vous pouvez également améliorer la journalisation en modifiant le champ logLevel dans le CR KataConfig. Cela modifie l'adresse log_level dans le runtime CRI-O pour les nœuds de travail exécutant les conteneurs OpenShift sandboxed.
Procédure
-
Remplacez le champ
logLevelde votre CRKataConfigexistant pardebug:
$ oc patch kataconfig <name_of_kataconfig_file> --type merge --patch '{"spec":{"logLevel":\N "debug"}}'
Lors de l'exécution de cette commande, faites référence au nom de votre CR KataConfig. Il s'agit du nom que vous avez utilisé pour créer le CR lors de la mise en place des conteneurs OpenShift sandboxed.
Vérification
Surveillez le pool de configuration de la machine
kata-ocjusqu'à ce que le champUPDATEDapparaisse sous la formeTrue, ce qui signifie que tous les nœuds de travail sont mis à jour :$ oc get mcp kata-ocExemple de sortie
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE kata-oc rendered-kata-oc-169 False True False 3 1 1 0 9hVérifier que le site
log_levela été mis à jour dans CRI-O :Ouvrez une session
oc debugsur un nœud du pool de configuration de la machine et exécutezchroot /host.oc debug node/<node_name>sh-4.4# chroot /hostVérifiez les changements dans le fichier
crio.conf:sh-4.4# crio config | egrep 'log_levelExemple de sortie
log_level = "debug"
7.3.1. Afficher les journaux de débogage pour les conteneurs OpenShift sandboxed Copier lienLien copié sur presse-papiers!
Les administrateurs de clusters peuvent utiliser les journaux de débogage améliorés pour les conteneurs OpenShift sandboxed afin de résoudre les problèmes. Les journaux de chaque nœud sont imprimés dans le journal du nœud.
Vous pouvez consulter les journaux pour les composants suivants des conteneurs OpenShift sandboxed :
- Agent Kata
-
Kata runtime (
containerd-shim-kata-v2) - virtiofsd
Les journaux de QEMU ne sont pas imprimés dans le journal du nœud. Cependant, une défaillance de QEMU est signalée au moteur d'exécution et la console de l'invité QEMU est imprimée dans le journal du nœud. Vous pouvez consulter ces journaux en même temps que les journaux de l'agent Kata.
Conditions préalables
-
Vous avez installé l'OpenShift CLI (
oc). -
Vous avez accès au cluster en tant qu'utilisateur ayant le rôle
cluster-admin.
Procédure
Pour consulter les journaux de l'agent Kata et de la console de l'invité, exécutez :
$ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kata -g "reading guest console" (lecture de la console de l'invité)Pour consulter les journaux d'exécution des kata, exécutez :
oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t kataPour consulter les journaux de virtiofsd, exécutez :
$ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t virtiofsd
Legal Notice
Copier lienLien copié sur presse-papiers!
Copyright © Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of the OpenJS Foundation.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.