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
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 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
CrashLoopBackOff
et l'échec des mises à niveau du cluster. Avec cette version, OpenShift sandboxed containers déploie le SCC lors de la création deKataConfig
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éesandboxed-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.
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 commandelscpu
:$ 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"
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 CRkataConfig
n'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 1
Vous 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
spec
dans 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 found
apparaît si un CRKataConfig
existe déjà ou non. Pour accéder à un CRKataConfig
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 imagekataMonitor
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 YAMLKataConfig
dans la console web.
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.
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 (commeout 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
ouCAP_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éekata
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
surLiveMigrate
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.
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.
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
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.
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.
Ressources supplémentaires
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.
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
NodeFeatureDiscovery
pour 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.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.
Définissez le champ
checkNodeEligibility
surtrue
dans la ressourceKataConfig
pour 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: true
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
- 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-operator
entraî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
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 dekata
en 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,kata
est installé en tant queRuntimeClass
sur tous les nœuds. Si vous souhaitez installerkata
en tant queRuntimeClass
uniquement sur certains nœuds, vous devez ajouter un matchExpression:-
Élargir la
kataConfigPoolSelector
domaine. -
Dans le
kataConfigPoolSelector
dé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
,Exists
etDoesNotExist
. - Développez la zone values, puis cliquez sur Add value.
-
Dans le champ Value, entrez
true
oufalse
pour 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écutantkata
en 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
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
- 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: 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
- 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.
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
Namespace
pour l'Opérateur de conteneurs en bac à sable OpenShift.Créez un fichier YAML de l'objet
Namespace
qui contient le manifeste suivant :apiVersion: v1 kind: Namespace metadata: name: openshift-sandboxed-containers-operator
Créer l'objet
Namespace
:$ oc create -f Namespace.yaml
Créez l'objet
OperatorGroup
pour l'Opérateur de conteneurs en bac à sable OpenShift.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
Créer l'objet
OperatorGroup
:$ oc create -f OperatorGroup.yaml
Créez l'objet
Subscription
pour abonnerNamespace
à l'opérateur de conteneurs en bac à sable d'OpenShift.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
Cré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-operator
Exemple de sortie
NAME DISPLAY VERSION REPLACES PHASE openshift-sandboxed-containers openshift-sandboxed-containers-operator 1.3.2 1.3.1 Succeeded
Ressources supplémentaires
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 utilisentkata
comme 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: false 1 logLevel: info
- 1
- Définissez "checkNodeEligibility" à
true
pour détecter l'éligibilité du nœud à exécuterkata
en 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
kata
en tant queRuntimeClass
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 denodeSelector
n'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.
Ressources supplémentaires
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 champruntimeClassName
estkata
, la charge de travail s'exécute sur un conteneur OpenShift sandboxed.
3.4. Ressources supplémentaires
- L'opérateur de conteneurs en bac à sable OpenShift est pris en charge dans un environnement de réseau restreint. Pour plus d'informations, utiliser Operator Lifecycle Manager sur des réseaux restreints.
- Lors de l'utilisation d'un cluster déconnecté sur un réseau restreint, vous devez configurer le support proxy dans Operator Lifecycle Manager pour accéder à OperatorHub. L'utilisation d'un proxy permet au cluster de récupérer les conteneurs OpenShift sandboxed Operator.
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
- 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.
Ressources supplémentaires
- Pour plus d'informations sur la création de requêtes PromQL pour afficher les métriques, voir Requête sur les métriques.
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
- 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
- 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
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
commeruntimeClass
.
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
kata
est affiché pour Runtime class. - Cliquez sur le menu Actions et sélectionnez Delete Pod.
- 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.
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
commeruntimeClass
.
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
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
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-operator
en 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-operator
et 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
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
- Dans la perspective de Administrator, naviguez vers Administration → CustomResourceDefinitions.
-
Recherchez
KataConfig
en 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
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
Recherchez les pods qui utilisent
kata
commeruntimeClass
en 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
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
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.
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
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-operator
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
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})
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
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
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.
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
- 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
KataConfig
en utilisant le champ Search by name. Le nom par défaut de la ressourceKataConfig
est example-kataconfig. -
Sélectionnez la ressource
KataConfig
et 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
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
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
NoteLes 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
-
Remplacez le champ
logLevel
de votre CRKataConfig
existant 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-oc
jusqu'à ce que le champUPDATED
apparaisse sous la formeTrue
, 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
Vérifier que le site
log_level
a été mis à jour dans CRI-O :Ouvrez une session
oc debug
sur un nœud du pool de configuration de la machine et exécutezchroot /host
.oc debug node/<node_name>
sh-4.4# chroot /host
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
- Pour plus d'informations sur la collecte de données à des fins d'assistance, voir Collecte de données sur votre cluster.