3.3. Considérations relatives à la migration

Examinez les changements de stockage suivants à prendre en compte lors de la transition d'OpenShift Container Platform 3.11 à OpenShift Container Platform 4.12.

Stockage persistant du volume local

Le stockage local est uniquement supporté en utilisant l'opérateur de stockage local dans OpenShift Container Platform 4.12. Il n'est pas possible d'utiliser la méthode de provisionnement local d'OpenShift Container Platform 3.11.

Pour plus d'informations, voir Stockage persistant à l'aide de volumes locaux.

Stockage persistant FlexVolume

L'emplacement du plugin FlexVolume a changé depuis OpenShift Container Platform 3.11. Le nouvel emplacement dans OpenShift Container Platform 4.12 est /etc/kubernetes/kubelet-plugins/volume/exec. Les plugins FlexVolume attachables ne sont plus supportés.

Pour plus d'informations, voir Stockage persistant à l'aide de FlexVolume.

Stockage persistant CSI (Container Storage Interface)

Le stockage persistant utilisant l'interface de stockage des conteneurs (CSI) a fait l'objet d'un aperçu technologique dans OpenShift Container Platform 3.11. OpenShift Container Platform 4.12 est livré avec plusieurs pilotes CSI. Vous pouvez également installer votre propre pilote.

Pour plus d'informations, voir Stockage persistant à l'aide de l'interface de stockage de conteneurs (CSI).

Red Hat OpenShift Data Foundation

OpenShift Container Storage 3, qui est disponible avec OpenShift Container Platform 3.11, utilise Red Hat Gluster Storage comme stockage de sauvegarde.

Red Hat OpenShift Data Foundation 4, qui est disponible pour une utilisation avec OpenShift Container Platform 4, utilise Red Hat Ceph Storage comme stockage de sauvegarde.

Pour plus d'informations, voir Stockage persistant à l'aide de Red Hat OpenShift Data Foundation et l'article sur la matrice d'interopérabilité.

Options de stockage persistant non prises en charge

La prise en charge des options de stockage persistant suivantes d'OpenShift Container Platform 3.11 a changé dans OpenShift Container Platform 4.12 :

Si vous avez utilisé l'une de ces options dans OpenShift Container Platform 3.11, vous devez choisir une autre option de stockage persistant pour une prise en charge complète dans OpenShift Container Platform 4.12.

Pour plus d'informations, voir Comprendre le stockage persistant.

Migration des volumes en arborescence vers les pilotes CSI

OpenShift Container Platform 4 migre les plugins de volume in-tree vers leurs équivalents Container Storage Interface (CSI). Dans OpenShift Container Platform 4.12, les pilotes CSI sont la nouvelle valeur par défaut pour les types de volumes in-tree suivants :

Tous les aspects du cycle de vie des volumes, tels que la création, la suppression, le montage et le démontage, sont gérés par le pilote CSI.

Pour plus d'informations, voir Migration automatique CSI.

Examinez les changements de réseau suivants à prendre en compte lors de la transition d'OpenShift Container Platform 3.11 à OpenShift Container Platform 4.12.

Mode d’isolement réseau

Le mode d'isolation réseau par défaut pour OpenShift Container Platform 3.11 était ovs-subnet, bien que les utilisateurs aient souvent changé pour utiliser ovn-multitenant. Le mode d'isolation du réseau par défaut pour OpenShift Container Platform 4.12 est contrôlé par une politique de réseau.

Si votre cluster OpenShift Container Platform 3.11 utilisait le mode ovs-subnet ou ovs-multitenant, il est recommandé de passer à une politique de réseau pour votre cluster OpenShift Container Platform 4.12. Les politiques de réseau sont prises en charge en amont, sont plus flexibles et offrent les mêmes fonctionnalités que ovs-multitenant. Si vous souhaitez conserver le comportement ovs-multitenant tout en utilisant une politique de réseau dans OpenShift Container Platform 4.12, suivez les étapes pour configurer l'isolation multitenant à l'aide d'une politique de réseau.

Pour plus d'informations, voir À propos de la stratégie de réseau.

OVN-Kubernetes comme plugin de mise en réseau par défaut dans Red Hat OpenShift Networking

Dans OpenShift Container Platform 3.11, OpenShift SDN était le plugin de mise en réseau par défaut dans Red Hat OpenShift Networking. Dans OpenShift Container Platform 4.12, OVN-Kubernetes est désormais le plugin de mise en réseau par défaut.

Pour plus d'informations sur la migration vers OVN-Kubernetes depuis OpenShift SDN, voir Migrations depuis le plugin réseau OpenShift SDN.

Examinez les changements de journalisation suivants à prendre en compte lors de la transition d'OpenShift Container Platform 3.11 à OpenShift Container Platform 4.12.

Déploiement d’OpenShift Logging

OpenShift Container Platform 4 fournit un mécanisme de déploiement simple pour OpenShift Logging, en utilisant une ressource personnalisée Cluster Logging.

Pour plus d'informations, voir Installation d'OpenShift Logging.

Données de journalisation agrégées

Vous ne pouvez pas migrer vos données de journalisation agrégées d’OpenShift Container Platform 3.11 vers votre nouveau cluster OpenShift Container Platform 4.

Pour plus d'informations, voir À propos de la journalisation OpenShift.

Configurations de journalisation non prises en charge

Certaines configurations de journalisation qui étaient disponibles dans OpenShift Container Platform 3.11 ne sont plus prises en charge dans OpenShift Container Platform 4.12.

Pour plus d'informations sur les cas de journalisation explicitement non pris en charge, voir Maintenance et support.

Examinez les changements de sécurité suivants à prendre en compte lors de la transition d'OpenShift Container Platform 3.11 à OpenShift Container Platform 4.12.

Accès non authentifié aux points d’accès de découverte

Dans OpenShift Container Platform 3.11, un utilisateur non authentifié pouvait accéder aux terminaux de découverte (par exemple, /api/* et /apis/*). Pour des raisons de sécurité, l'accès non authentifié aux terminaux de découverte n'est plus autorisé dans OpenShift Container Platform 4.12. Si vous devez autoriser l'accès non authentifié, vous pouvez configurer les paramètres RBAC comme il se doit ; cependant, veillez à prendre en compte les implications en termes de sécurité, car cela peut exposer les composants internes du cluster au réseau externe.

Fournisseurs d’identité

La configuration des fournisseurs d’identité a été modifiée pour OpenShift Container Platform 4. Voici quelques changements notables :

Pour plus d'informations, voir Comprendre la configuration du fournisseur d'identité.

Format de stockage des tokens OAuth

Les tokens du porteur OAuth HTTP qui viennent d’être créés ne correspondent plus aux noms de leurs objets de token d’accès OAuth. Les noms des objets constituent maintenant un hachage du jeton du porteur et ne sont plus sensibles. Cela réduit le risque de fuite d’informations sensibles.

Contraintes de contexte de sécurité par défaut

Les contraintes de contexte de sécurité (SCC) restricted dans OpenShift Container Platform 4 ne peuvent plus être accédées par n'importe quel utilisateur authentifié comme le SCC restricted dans OpenShift Container Platform 3.11. L'accès authentifié large est maintenant accordé à la SCC restricted-v2, qui est plus restrictive que l'ancienne SCC restricted. Le SCC restricted existe toujours ; les utilisateurs qui veulent l'utiliser doivent recevoir des permissions spécifiques pour le faire.

Pour plus d'informations, voir Gestion des contraintes du contexte de sécurité.

Examinez les changements de surveillance suivants lors de la transition d'OpenShift Container Platform 3.11 à OpenShift Container Platform 4.12. Vous ne pouvez pas migrer les configurations et les métriques Hawkular vers Prometheus.

Alerte pour la disponibilité de l’infrastructure de surveillance

Dans OpenShift Container Platform 3.11, l’alerte par défaut qui se déclenchait pour garantir la disponibilité de la structure de surveillance était appelée DeadMansSwitch. Elle a été renommée Watchdog dans OpenShift Container Platform 4. Si l’intégration PagerDuty était configurée avec cette alerte dans OpenShift Container Platform 3.11, vous devez la configurer pour l’alerte Watchdog dans OpenShift Container Platform 4.

Pour plus d'informations, voir Application d'une configuration personnalisée de l'Alertmanager.