Prise en charge des conteneurs en bac à sable pour OpenShift

OpenShift Container Platform 4.12

Guide sur les conteneurs sandboxés d'OpenShift

Red Hat OpenShift Documentation Team

Résumé

Le support des conteneurs sandboxed d'OpenShift Container Platform offre aux utilisateurs un support intégré pour l'exécution de Kata Containers en tant que runtime optionnel supplémentaire.

Chapitre 1. {sandboxed-containers-first} {sandboxed-containers-version} notes de mise à jour

1.1. À propos de cette version

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

1.2.1. ID du conteneur dans la liste des métriques

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

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

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

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

  • 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-root

    En raison de ce problème, le CR KataConfig n'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 KataConfig et de l'observation de l'état du pod sous l'espace de noms openshift-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'extension sandboxed-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 CrashLoopBackOff et l'échec des mises à niveau du cluster. Avec cette version, OpenShift sandboxed containers déploie le SCC lors de la création de KataConfig CR 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-scc n'était pas supprimée. Avec cette version, la ressource personnalisée sandboxed-containers-operator-scc est supprimée lors de la désinstallation de l'OpenShift sandboxed containers Operator. (KATA-1569)

1.5. Problèmes connus

  • 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: unknown

    Les étiquettes MCS définies au niveau du conteneur ne sont pas appliquées à virtiofsd. Le moteur d'exécution kata n'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.

    (KATA-1875)

  • 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 hostPath dans 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 virtiofsd ou 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 virtiofsd d'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 commande lscpu:

    $ lscpu

    Exemple de sortie

    CPU(s):                          16
    On-line CPU(s) list:             0-12,14,15
    Off-line CPU(s) list:            13

    La 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 annotation suivante doit être ajoutée aux métadonnées du pod :

    metadata:
      annotations:
        io.katacontainers.config.hypervisor.default_vcpus: "16"

    (KATA-1376)

  • La progression de l'installation du runtime est affichée dans la section status de 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 machineconfigpool pour vérifier le nombre de nœuds de travail dans le pool de configuration de la machine.
    • Aucune adresse kataConfigPoolSelector n'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 status du CR kataConfig n'est pas mise à jour pendant l'installation. (KATA-1017)

  • 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 1

    Vous devez utiliser la dernière version de Buildah, disponible sur quay.io.

    (KATA-1278)

  • 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 spec dans le YAML KataConfig. 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 found apparaît si un CR KataConfig existe déjà ou non. Pour accéder à un CR KataConfig existant, 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 KataConfig CR 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 image kataMonitor obsolè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 kataMonitor en éditant le YAML KataConfig dans la console web.

    (KATA-1650)

1.6. Mises à jour asynchrones de l'errata

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.

Note

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

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

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

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

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

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 (comme out of tree ou 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 sysctl dé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_ADMIN ou CAP_BPF et 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

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

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
KataConfig repré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 RuntimeClass décrit quel runtime peut être utilisé pour exécuter une charge de travail donnée. Une classe d'exécution nommée kata est 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)

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

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

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

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-rbd comme classe de stockage.
  • Réglez le paramètre evictionStrategy sur LiveMigrate dans la VM.

2.4. Comprendre la conformité et la gestion des risques

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.

Important

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

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

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

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-v2 est utilisé pour communiquer avec le pod.
  • virtiofsd gè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.

RessourcesValeur

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 virtiofsd (à l'exclusion des tampons d'E/S de la VM)

~10Mi

Mémoire utilisée par le processus containerd-shim-kata-v2

~20Mi

Données du cache du tampon de fichier après l'exécution de dnf install sur Fedora

~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 virtiofsd qui é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.
Note

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.

Note

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

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.

Note

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

  1. Créer une ressource NodeFeatureDiscovery pour détecter les capacités des nœuds adaptés à l'exécution des conteneurs Kata :

    1. 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"]
    2. Créer la ressource personnalisée (CR) NodeFeatureDiscovery:

      $ oc create -f nfd.yaml

      Exemple de sortie

      nodefeaturediscovery.nfd.openshift.io/nfd-kata created

      Une étiquette feature.node.kubernetes.io/runtime.kata=true est appliquée à tous les nœuds de travail qualifiés.

  2. Définissez le champ checkNodeEligibility sur true dans la ressource KataConfig pour activer la fonctionnalité, par exemple :

    1. Enregistrez le YAML suivant dans le fichier kata-config.yaml:

      apiVersion: kataconfiguration.openshift.io/v1
      kind: KataConfig
      metadata:
        name: example-kataconfig
      spec:
        checkNodeEligibility: true
    2. Créer le CR KataConfig:

      $ oc create -f kata-config.yaml

      Exemple 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

Ressources supplémentaires

  • Pour plus d'informations sur l'installation de l'opérateur NFD (Node Feature Discovery), voir Installation de NFD.

3.2. Déployer les charges de travail des conteneurs OpenShift sandboxed à l'aide de la console web

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

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

  1. Depuis la perspective Administrator dans la console web, naviguez vers OperatorsOperatorHub.
  2. Dans le champ Filter by keyword, tapez OpenShift sandboxed containers.
  3. Sélectionnez la tuile OpenShift sandboxed containers.
  4. Lisez les informations sur l'opérateur et cliquez sur Install.
  5. Sur la page Install Operator:

    1. Sélectionnez stable-1.3 dans la liste des options Update Channel disponibles.
    2. 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éé.

      Note

      La tentative d'installation de l'Opérateur de conteneurs en bac à sable OpenShift dans un espace de noms autre que openshift-sandboxed-containers-operator entraîne l'échec de l'installation.

    3. 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.
  6. Cliquez sur Install.

L'opérateur OpenShift sandboxed containers est maintenant installé sur votre cluster.

Vérification

  1. Depuis la perspective Administrator dans la console web, naviguez vers OperatorsInstalled Operators.
  2. 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

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.

Important

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

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

  1. Depuis la perspective Administrator dans la console web, naviguez vers OperatorsInstalled Operators.
  2. Sélectionnez l'Opérateur de conteneurs sandboxés OpenShift dans la liste des opérateurs.
  3. Dans l'onglet KataConfig, cliquez sur Create KataConfig.
  4. 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 comme example-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 de kata en tant que RuntimeClass. 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, kata est installé en tant que RuntimeClass sur tous les nœuds. Si vous souhaitez installer kata en tant que RuntimeClass uniquement sur certains nœuds, vous devez ajouter un matchExpression:

      1. Élargir la kataConfigPoolSelector domaine.
      2. Dans le kataConfigPoolSelectordéveloppez matchExpressions. Il s'agit d'une liste d'exigences relatives aux sélecteurs d'étiquettes.
      3. Cliquez sur Add matchExpressions.
      4. Dans le champ key, ajoutez la clé d'étiquette à laquelle le sélecteur s'applique.
      5. Dans le champ operator, ajoutez la relation de la clé aux valeurs de l'étiquette. Les opérateurs valides sont In, NotIn, Exists et DoesNotExist.
      6. Développez la zone values, puis cliquez sur Add value.
      7. Dans le champ Value, entrez true ou false pour la valeur de l'étiquette key.
    • logLevel: Définir le niveau des données de journal récupérées pour les nœuds exécutant kata en tant que RuntimeClass. Pour plus d'informations, voir "Collecting OpenShift sandboxed containers data" (Collecte des données des conteneurs en bac à sable OpenShift).
  5. 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.

Important

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

  1. Dans l'onglet KataConfig, sélectionnez le nouveau CR KataConfig.
  2. Dans la page KataConfig, sélectionnez l'onglet YAML.
  3. Contrôler le champ installationStatus dans le statut.

    Un message apparaît à chaque mise à jour. Cliquez sur Reload pour voir le CR KataConfig mis à 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

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

  1. 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.
  2. Dans la page de la charge de travail, cliquez sur pour créer la charge de travail.
  3. 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: 8080

    Exemple 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

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

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

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.

    Note

    L'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

  1. Créez l'objet Namespace pour l'Opérateur de conteneurs en bac à sable OpenShift.

    1. Créez un fichier YAML de l'objet Namespace qui contient le manifeste suivant :

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-sandboxed-containers-operator
    2. Créer l'objet Namespace:

      $ oc create -f Namespace.yaml
  2. Créez l'objet OperatorGroup pour l'Opérateur de conteneurs en bac à sable OpenShift.

    1. Créez un fichier YAML de l'objet OperatorGroup qui 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-operator
    2. Créer l'objet OperatorGroup:

      $ oc create -f OperatorGroup.yaml
  3. Créez l'objet Subscription pour abonner Namespace à l'opérateur de conteneurs en bac à sable d'OpenShift.

    1. Créez un fichier YAML de l'objet Subscription qui 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.2
    2. Créer l'objet Subscription:

      $ oc create -f Subscription.yaml

L'opérateur OpenShift sandboxed containers est maintenant installé sur votre cluster.

Note

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-operator

    Exemple 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

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 RuntimeClass nommé kata avec une configuration par défaut. Cela permet aux utilisateurs de configurer les charges de travail pour qu'elles utilisent kata comme durée d'exécution en faisant référence à la CR dans le champ RuntimeClassName. Ce CR spécifie également la surcharge de ressources pour le runtime.
Note

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

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

  1. Créer un fichier YAML avec le manifeste suivant :

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: cluster-kataconfig
    spec:
      checkNodeEligibility: false 1
      logLevel: info
    1
    Définissez "checkNodeEligibility" à true pour détecter l'éligibilité du nœud à exécuter kata en tant que RuntimeClass. 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).
  2. (Facultatif) Si vous souhaitez installer kata en tant que RuntimeClass uniquement 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 kataConfigPoolSelector ne prennent en charge que des valeurs uniques ; la syntaxe de nodeSelector n'est pas prise en charge.
  3. 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.

Important

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

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 :

    • Pod objets
    • ReplicaSet objets
    • ReplicationController objets
    • StatefulSet objets
    • Deployment objets
    • DeploymentConfig objets

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 runtimeClassName sur un objet pod-templated. Si le champ runtimeClassName est kata, la charge de travail s'exécute sur un conteneur OpenShift sandboxed.

3.4. Ressources supplémentaires

Chapitre 4. Surveillance des conteneurs OpenShift en bac à sable

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

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

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-admin ou avec des permissions de visualisation pour tous les projets.

Procédure

  1. Depuis la perspective Administrator dans la console web, naviguez vers ObserveMetrics.
  2. 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.

Ressources supplémentaires

4.3. Visualisation du tableau de bord des conteneurs sandboxés d'OpenShift

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-admin ou avec des permissions de visualisation pour tous les projets.

Procédure

  1. Depuis la perspective Administrator dans la console web, naviguez vers ObserveDashboards.
  2. Dans la liste déroulante Dashboard, sélectionnez le tableau de bord Sandboxed Containers.
  3. 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.

      1. Définissez la date et l'intervalle de temps pour les données que vous souhaitez consulter.
      2. Click Save to save the custom time range.
  4. 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

Chapitre 5. Désinstallation des conteneurs OpenShift sandboxed

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

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

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 kata comme runtimeClass.

Procédure

  1. Dans la perspective de Administrator, naviguez vers WorkloadsPods.
  2. Recherchez le pod que vous souhaitez supprimer en utilisant le champ Search by name.
  3. Cliquez sur le nom du pod pour l'ouvrir.
  4. Sur la page Details, vérifiez que kata est affiché pour Runtime class.
  5. Cliquez sur le menu Actions et sélectionnez Delete Pod.
  6. Cliquez sur Delete dans la fenêtre de confirmation.

Ressources supplémentaires

Vous pouvez récupérer une liste des pods en cours d'exécution qui utilisent kata comme runtimeClass à partir de la CLI d'OpenShift. Pour plus de détails, voir Suppression des pods de conteneurs sandboxés OpenShift.

5.1.2. Suppression de la ressource personnalisée KataConfig à l'aide de la console web

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.

Important

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 kata comme runtimeClass.

Procédure

  1. Dans la perspective de Administrator, naviguez vers OperatorsInstalled Operators.
  2. Recherchez l'opérateur de conteneurs OpenShift sandboxed en utilisant le champ Search by name.
  3. Cliquez sur l'opérateur pour l'ouvrir, puis sélectionnez l'onglet KataConfig.
  4. Cliquez sur le menu Options kebab pour la ressource KataConfig, puis sélectionnez Delete KataConfig.
  5. 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

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

  1. Dans la perspective de Administrator, naviguez vers OperatorsInstalled Operators.
  2. Recherchez l'opérateur de conteneurs OpenShift sandboxed en utilisant le champ Search by name.
  3. Cliquez sur le menu Options kebab de l'opérateur et sélectionnez Uninstall Operator.
  4. 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

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

  1. Dans la perspective de Administrator, naviguez vers AdministrationNamespaces.
  2. Recherchez l'espace de noms openshift-sandboxed-containers-operator en utilisant le champ Search by name.
  3. Cliquez sur le menu Options kebab pour l'espace de noms et sélectionnez Delete Namespace.

    Note

    Si l'option Delete Namespace n'est pas disponible, vous n'êtes pas autorisé à supprimer l'espace de noms.

  4. Dans le volet Delete Namespace, saisissez openshift-sandboxed-containers-operator et cliquez sur Delete.
  5. Cliquez sur Delete.

5.1.5. Suppression de la définition de la ressource personnalisée KataConfig à l'aide de la console Web

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 KataConfig CR de votre cluster.
  • Vous avez supprimé les conteneurs OpenShift sandboxed Operator de votre cluster.

Procédure

  1. Dans la perspective de Administrator, naviguez vers AdministrationCustomResourceDefinitions.
  2. Recherchez KataConfig en utilisant le champ Search by name.
  3. Cliquez sur le menu Options kebab pour le CRD KataConfig, puis sélectionnez Delete CustomResourceDefinition.
  4. Cliquez sur Delete dans la fenêtre de confirmation.
  5. Attendez que le CRD KataConfig disparaisse de la liste. Cela peut prendre plusieurs minutes.

5.2. Désinstallation des conteneurs OpenShift sandboxed à l'aide de la CLI

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

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

  1. Recherchez les pods qui utilisent kata comme runtimeClass en exécutant la commande suivante :

    $ oc get pods -A -o json | jq -r '.items[] | select(.spec.runtimeClassName == "kata").metadata.name'
  2. 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

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

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

  1. Supprimez la ressource personnalisée KataConfig en 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.

Important

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 KataConfig a é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

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

  1. 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)
  2. 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-operator
  3. Supprimez le nom CSV pour les conteneurs OpenShift sandboxed en exécutant la commande suivante :

    $ oc delete csv ${CSV_NAME} -n openshift-sandboxed-containers-operator
  4. Ré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})
  5. 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-operator
  6. Supprimez 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

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 KataConfig CR de votre cluster.
  • Vous avez supprimé les conteneurs OpenShift sandboxed Operator de votre cluster.

Procédure

  1. Supprimez le CRD KataConfig en exécutant la commande suivante :

    $ oc delete crd kataconfigs.kataconfiguration.openshift.io

Vérification

  • Pour vérifier que le CRD KataConfig est supprimé, exécutez la commande suivante :

    $ oc get crd kataconfigs.kataconfiguration.openshift.io

    Exemple de sortie

    Unknown CR KataConfig

Chapitre 6. Mise à jour des conteneurs OpenShift sandboxed

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 Kata et 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) KataConfig pour 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.

Important

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

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

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

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

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

  1. Dans la perspective Administrator d'OpenShift Container Platform, naviguez vers OperatorsInstalled Operators.
  2. Sélectionnez le site OpenShift sandboxed containers Operator et allez dans l'onglet KataConfig.
  3. Recherchez la ressource KataConfig en utilisant le champ Search by name. Le nom par défaut de la ressource KataConfig est example-kataconfig.
  4. Sélectionnez la ressource KataConfig et allez dans l'onglet KataConfig.
  5. 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'
  6. Cliquez sur Save.

6.3.2. Mise à niveau des modules de surveillance à l'aide de la CLI

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 exemple example-kataconfig.

Chapitre 7. Collecte des données des conteneurs OpenShift sandboxed

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

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

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 --image avec 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.0
  • Pour 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_logs
    Note

    Les 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

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

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

  1. Remplacez le champ logLevel de votre CR KataConfig existant par debug:
$ oc patch kataconfig <name_of_kataconfig_file> --type merge --patch '{"spec":{"logLevel":\N "debug"}}'
Note

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

  1. Surveillez le pool de configuration de la machine kata-oc jusqu'à ce que le champ UPDATED apparaisse sous la forme True, ce qui signifie que tous les nœuds de travail sont mis à jour :

    $ oc get mcp kata-oc

    Exemple 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                     9h

  2. Vérifier que le site log_level a été mis à jour dans CRI-O :

    1. Ouvrez une session oc debug sur un nœud du pool de configuration de la machine et exécutez chroot /host.

      oc debug node/<node_name>
      sh-4.4# chroot /host
    2. Vérifiez les changements dans le fichier crio.conf:

      sh-4.4# crio config | egrep 'log_level

      Exemple de sortie

      log_level = "debug"

7.3.1. Afficher les journaux de débogage pour les conteneurs OpenShift sandboxed

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 kata
  • Pour consulter les journaux de virtiofsd, exécutez :

    $ oc debug node/<nodename> -- journalctl -D /host/var/log/journal -t virtiofsd

7.4. Ressources supplémentaires

Note légale

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat 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 Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
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.