1.8. Problèmes connus

Dans OpenShift Container Platform 4.1, les utilisateurs anonymes pouvaient accéder aux terminaux de découverte. Les versions ultérieures ont révoqué cet accès afin de réduire la surface d'attaque possible pour les exploits de sécurité, car certains points de terminaison de découverte sont transmis à des serveurs d'API agrégés. Cependant, l'accès non authentifié est préservé dans les clusters mis à jour afin que les cas d'utilisation existants ne soient pas interrompus.

Si vous êtes un administrateur de cluster pour un cluster qui a été mis à niveau de OpenShift Container Platform 4.1 à 4.12, vous pouvez soit révoquer, soit continuer à autoriser l'accès non authentifié. À moins qu'il n'y ait un besoin spécifique pour l'accès non authentifié, vous devriez le révoquer. Si vous continuez à autoriser l'accès non authentifié, soyez conscient des risques accrus.

Utilisez le script suivant pour révoquer l'accès non authentifié aux terminaux de découverte :

## Snippet to remove unauthenticated group from all the cluster role bindings
$ for clusterrolebinding in cluster-status-binding discovery system:basic-user system:discovery system:openshift:discovery ;
do
### Find the index of unauthenticated group in list of subjects
index=$(oc get clusterrolebinding ${clusterrolebinding} -o json | jq 'select(.subjects!=null) | .subjects | map(.name=="system:unauthenticated") | index(true)');
### Remove the element at index from subjects array
oc patch clusterrolebinding ${clusterrolebinding} --type=json --patch "[{'op': 'remove','path': '/subjects/$index'}]";
done

Ce script supprime les sujets non authentifiés des liaisons de rôles de cluster suivantes :

(BZ#1821771)

Par intermittence, un cluster IBM Cloud VPC peut échouer à s'installer parce que certaines machines de travail ne démarrent pas. Au contraire, ces machines de travail restent dans la phase Provisioned.

Il existe une solution de contournement pour ce problème. À partir de l'hôte où vous avez effectué l'installation initiale, supprimez les machines qui ont échoué et exécutez à nouveau le programme d'installation.

Après une mise à jour de la source du catalogue, OLM met du temps à mettre à jour l'état de l'abonnement. Cela peut signifier que l'état de la politique d'abonnement peut continuer à s'afficher comme conforme lorsque le gestionnaire du cycle de vie Topology Aware (TALM) décide si une remédiation est nécessaire. En conséquence, l'opérateur spécifié dans la politique d'abonnement n'est pas mis à niveau. Comme solution de contournement, incluez un champ status dans la section spec de la politique de source de catalogue comme suit :

metadata:
  name: redhat-operators-disconnected
spec:
  displayName: disconnected-redhat-operators
  image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.11
status:
  connectionState:
    lastObservedState: READY

Cela réduit le délai nécessaire à OLM pour extraire la nouvelle image d'index et préparer le pod, réduisant ainsi le délai entre l'achèvement de la remédiation de la politique de source du catalogue et la mise à jour de l'état de l'abonnement. Si le problème persiste et que la mise à jour de l'état de la politique d'abonnement est toujours en retard, vous pouvez appliquer une autre CR ClusterGroupUpdate avec la même politique d'abonnement, ou une CR ClusterGroupUpdate identique avec un nom différent. (OCPBUGS-2813)

TALM ne procède pas à la remédiation d'une politique si tous les clusters sélectionnés sont conformes lorsque le CR ClusterGroupUpdate est démarré. La mise à jour des opérateurs avec une politique de source de catalogue modifiée et une politique d'abonnement dans la même CR ClusterGroupUpdate ne se termine pas. La politique d'abonnement est ignorée car elle est toujours conforme jusqu'à ce que la modification de la source du catalogue soit appliquée. Pour contourner le problème, ajoutez la modification suivante à un CR de la politique common-subscription, par exemple :

metadata.annotations.upgrade: "1"

La politique n'est donc pas conforme avant le début de la CR ClusterGroupUpdate. (OCPBUGS-2812)

Le CR BMCEventSubscription ne parvient pas à créer un abonnement Redfish pour un cluster spoke dans un environnement multi-cluster déployé par ACM, où le service metal3 ne fonctionne que sur un cluster hub. La solution consiste à créer l'abonnement en appelant directement l'API Redfish, par exemple en exécutant la commande suivante :

curl -X POST -i --insecure -u "<BMC_username>:<BMC_password>" https://<BMC_IP>/redfish/v1/EventService/Subscriptions \
    -H 'Content-Type: application/json' \
    --data-raw '{
    "Protocol": "Redfish",
    "Context": "any string is valid",
    "Destination": "https://hw-event-proxy-openshift-bare-metal-events.apps.example.com/webhook",
    "EventTypes": ["Alert"]
    }'

Vous devriez recevoir une réponse 201 Created et un en-tête avec Location: /redfish/v1/EventService/Subscriptions/<sub_id> qui indique que l'abonnement aux événements Redfish a été créé avec succès. (OCPBUGSM-43707)

Lorsque vous utilisez la méthode ZTP de GitOps pour gérer les clusters et que vous supprimez un cluster dont l'installation n'est pas terminée, le nettoyage de l'espace de noms du cluster sur le cluster hub peut être suspendu indéfiniment. Pour terminer la suppression de l'espace de noms, supprimez le finalisateur baremetalhost.metal3.io de deux CR dans l'espace de noms du cluster :

Problèmes connus de l'opérateur de plate-forme et du RukPak :

Les clusters qui utilisent des fournisseurs de cloud externes peuvent ne pas récupérer les informations d'identification mises à jour après la rotation. Les plateformes suivantes sont concernées :

En guise de solution, redémarrez les pods openshift-cloud-controller-manager en exécutant la commande suivante :

$ oc delete pods --all -n openshift-cloud-controller-manager

(OCPBUGS-5036)

Lorsqu'une machine de plan de contrôle est remplacée sur un cluster qui utilise le fournisseur de réseau OVN-Kubernetes, les pods liés à OVN-Kubernetes peuvent ne pas démarrer sur la machine de remplacement. Dans ce cas, l'absence de réseau sur la nouvelle machine empêche etcd de remplacer l'ancienne machine. En conséquence, le cluster est bloqué dans cet état et peut se dégrader. Ce comportement peut se produire lorsque le plan de contrôle est remplacé manuellement ou par le jeu de machines du plan de contrôle.

Il n'existe actuellement aucune solution pour résoudre ce problème. Pour éviter ce problème, désactivez le jeu de machines du plan de contrôle et ne remplacez pas manuellement les machines du plan de contrôle si votre cluster utilise le fournisseur de réseau OVN-Kubernetes. (OCPBUGS-5306)