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

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 :

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)

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)