Migration des points de terminaison d'origine vers les points de terminaison pris en charge

Grappes classiques

Vous devez prendre des mesures si l'une des situations suivantes s'applique à vous :

• Vous disposez d'un ou plusieurs clusters classiques sur lesquels le point de terminaison de service public est activé et vous limitez les accès sortants à l'aide de listes d'autorisation ou de pare-feu.
• Vous disposez de scripts ou d'outils personnalisés qui appellent directement les points de terminaison d' origin.<region>.containers.cloud.ibm.com.

Si aucune de ces deux conditions n'est remplie, aucune mesure n'est nécessaire.

Pour maintenir la connectivité de vos nœuds de travail à Red Hat OpenShift on IBM Cloud, veuillez suivre les étapes suivantes avant le 31 juillet 2026.

• Si vous utilisez des règles de pare-feu basées sur les adresses IP: assurez-vous que les adresses IP répertoriées dans la section « Autoriser les nœuds de travail à communiquer avec le maître du cluster » figurent bien dans vos règles de pare-feu.

• Si vous utilisez des règles de pare-feu basées sur les domaines: ajoutez les domaines de démarrage suivants à votre liste blanche.

• Si vous disposez de scripts personnalisés qui appellent directement les points de terminaison d'origine: passez aux points de terminaison API pris en charge. Pour plus d'informations, consultez la section « À propos de l'API ».

Avant de commencer, notez l'adresse IP publique de chaque noeud worker du cluster.

ibmcloud oc worker ls --cluster <cluster_name_or_ID>

Autoriser les noeuds worker à communiquer avec le maître de cluster

Pour permettre aux nœuds worker de communiquer avec le maître cluster sur le nœud final de service de cloud public, autorisez le trafic réseau sortant de la source <each_worker_node_publicIP> vers la plage de ports TCP/UDP de destination 30000 - 32767 et le port 443, ainsi que les adresses IP et les groupes de réseau suivants. De plus, si vous prévoyez d'utiliser Ingress ou des routes pour exposer des applications dans votre cluster, autorisez également le trafic réseau entrant via ces ports sur les adresses IP de vos noeuds worker pour que le plan de contrôle Red Hat OpenShift puisse vérifier l'intégrité de vos routeurs.

Ce tableau est en mouvement. Pour les listes d'adresses IP les plus récentes et les mises à jour continues, consultez le dossier d'isolement du réseau public dans le IBM/kube-samples référentiel . Vous pouvez consulter les pull requests du dépôt pour vous tenir au courant des mises à jour.

• TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_publicIP> TO <public_IPs>
• Remplacez <public_IPs> par les adresses IP publiques de la région où se trouve votre cluster.

Autoriser les noeuds worker à communiquer avec IBM Cloud Container Registry

Autorisez le trafic réseau sortant depuis vos nœuds de travail vers IBM Cloud Container Registry. Pour plus d'informations, voir Accès à IBM Cloud Container Registry via un pare-feu.

Autoriser le trafic réseau sortant du noeud worker vers IAM

Autorisez le trafic réseau sortant à partir de votre noeud worker vers IBM Cloud Identity and Access Management (IAM). Votre liste d'autorisation doit être de niveau 7 pour autoriser le nom de domaine IAM. IAM ne possède pas d'adresses IP spécifiques pouvant être autorisées. Si votre liste blanche ne prend pas en charge la couche 7, vous pouvez autoriser tout le trafic réseau HTTPS sur le port 443.

• TCP port 443 FROM <each_worker_node_publicIP> TO https://iam.bluemix.net
• TCP port 443 FROM <each_worker_node_publicIP> TO https://iam.cloud.ibm.com

Facultatif : autorisez le trafic réseau sortant depuis les noeuds d'agent vers les services Monitoring et IBM Cloud Logs

• IBM Cloud Monitoring:

  • TCP port 443, port 6443 FROM <each_worker_node_public_IP> TO <monitoring_public_IP>
  • Remplacez <monitoring_public_IP> par les adresses IP Monitoring.

• IBM Cloud Logs:

  • TCP port 443, port 80 FROM <each_worker_node_public_IP> TO <logging_public_IP>
  • Remplacez <logging_public_IP> par les adresses IP IBM Cloud Logs.

Facultatif : Autoriser le trafic réseau entrant pour la surveillance du sous-domaine d'entrée

Si vous souhaitez utiliser la surveillance de l'état du domaine Ingress pour surveiller l'état de vos points de terminaison de service, vous devez autoriser l'accès entrant des services de surveillance.

Par défaut, les demandes de surveillance de l'état de santé sont envoyées par l'intermédiaire de HTTPS au port 443. Vous devez donc autoriser le trafic des plages d'adresses IP ci-dessous ciblé sur le port 443. Si votre moniteur de santé est configuré pour utiliser HTTP à la place, le trafic de la liste d'autorisation doit être ciblé sur le port 80. En outre, si vous utilisez un port TCP personnalisé, veillez à autoriser le trafic entrant vers ce port.

Pour plus d'informations, voir le site IBM NS1 Connect Documentation sur la surveillance.

Etapes suivantes

Si vous utilisez des services d'équilibrage de charge, vérifiez que tout le trafic utilisant le protocole VRRP est autorisé entre les nœuds worker sur les interfaces publiques et privées. Red Hat OpenShift on IBM Cloud utilise le protocole VRRP pour gérer les adresses IP des équilibreurs de charge publics et privés.

Si vous utilisez Ingress ou des routes pour exposer des applications dans votre cluster, autorisez le trafic réseau entrant provenant des adresses IP sources IBM NS1 sur le port 80 vers les adresses IP de vos services de routeurs, afin que le plan de contrôle Red Hat OpenShift puisse vérifier l'état de vos routeurs.

Autoriser les noeuds worker à communiquer avec le maître de cluster

Pour permettre aux nœuds worker de communiquer avec le maître de cluster sur le nœud final de service de cloud privé, laissez le trafic réseau sortant de la source <each_worker_node_privateIP> vers la plage de ports TCP/UDP de destination 30000-32767 et le port 443, ainsi que les adresses IP et les groupes réseau suivants.

Ce tableau est en mouvement. Pour les listes d'adresses IP les plus récentes et les mises à jour ultérieures, consultez le dossier d'isolement du réseau privé dans le IBM/kube-samples référentiel . Vous pouvez consulter les pull requests du dépôt pour vous tenir au courant des mises à jour.

• TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_privateIP> TO <private_IPs>
• Remplacez <private_IPs> par les adresses IP privées de la région où se trouve votre cluster.

Ouverture de ports

Ouvrez les ports suivants dans votre liste autorisée pour que vos noeuds worker fonctionnent correctement. Les ports suivants doivent être ouverts pour toutes les adresses IP de destination.

• Autorisez les connexions TCP et UDP sortantes à partir des noeuds worker sur les ports 80 et 443 pour permettre les mises à jour et les rechargements des noeuds worker.
• Autorisez les connexions TCP et UDP sortantes sur le port 2049 pour permettre le montage du stockage de fichiers sous forme de volumes.
• Autorisez les connexions TCP et UDP sortantes sur le port 3260 pour la communication avec du stockage par blocs.
• Autorisez les connexions TCP et UDP entrantes sur le port 10250 pour le tableau de bord Red Hat OpenShift et les commandes telles que oc logs et oc exec.
• Autorisez les connexions TCP et UDP entrantes et sortantes sur les ports 53 et 5353 pour l'accès DNS.

Activer la communication entre les nœuds worker

Activez la communication entre nœuds de travail en autorisant tout le trafic TCP, UDP, VRRP et IPEncap entre les nœuds de travail sur les interfaces privées, et autorisez également le protocole VRRP sur l'interface publique. Red Hat OpenShift on IBM Cloud utilise le protocole VRRP pour gérer les adresses IP des équilibreurs de charge et le protocole IPEncap pour permettre le trafic entre pods d'un sous-réseau à l'autre.

Autoriser les noeuds worker à communiquer avec IBM Cloud Container Registry

Pour permettre aux nœuds worker de communiquer avec IBM Cloud Container Registry, autorisez le trafic réseau sortant des nœuds worker vers les régions IBM Cloud Container Registry.

• TCP port 443 FROM <each_worker_node_privateIP> TO <registry_ip>
• Remplacez<registry_ip> par l'adresse IP de registre à laquelle vous souhaitez autoriser le trafic. Le registre global héberge des images publiques fournies par IBM et les registres régionaux stockent vos propres images privées ou publiques.

Optionnel : Configurer les règles de la liste d'autorisation pour les services IBM Cloud Logs et IBM Cloud Monitoring

Pour envoyer des données de journalisation et de métriques, configurez des règles de liste blanche pour vos services IBM Cloud Logs et IBM Cloud Monitoring.

• IBM Cloud Logs points d'extrémité privés
• Noeuds finaux privés Monitoring

Obtention de vos adresses IP de sous-réseau dans la console

1. Dans la liste des ressources de la console d' IBM Cloud, cliquez sur votre cluster.
2. Cliquez sur « Nœuds de travail ».
3. Notez chaque VLAN public utilisé par les noeuds worker dans votre cluster. Plusieurs noeuds worker peuvent utiliser le même VLAN public.
4. Dans le menu de la console IBM Cloud , cliquez sur Infrastructure > Infrastructure classique > Gestion IP > VLANs.
5. Cliquez sur chaque VLAN public pour vérifier s'il est utilisé par les nœuds de travail de votre cluster.
6. Pour chaque VLAN public utilisé par les noeuds worker dans votre cluster, recherchez la section Sous-réseaux et notez chaque adresse IP incluse dans le tableau. Il s'agit des adresses IP que vous devez inclure dans votre liste autorisée.

Obtention de vos adresses IP de sous-réseau dans l'interface de ligne de commande

1. Répertoriez les VLAN publics utilisés par vos noeuds worker. La sortie est au format publicVLAN=<vlan_id>.

   oc describe nodes | grep publicVLAN | sort | uniq
   

2. Pour chaque VLAN public, recherchez les sous-réseaux publics associés. Dans la sortie, notez les adresses IP de sous-réseau dans la colonne identifier.

   ibmcloud sl subnet list | grep <vlan-id>
   

   Exemple de sortie de sous-réseaux associés à un VLAN public avec l'ID 2761690.

   ID        identifier        type                 network_space   datacenter   vlan_id   IPs   hardware   virtual_servers  
   1962263   169.62.46.56      SECONDARY_ON_VLAN    PUBLIC          wdc07        2761690   8     0          0   
   2008207   169.62.39.248     SECONDARY_ON_VLAN    PUBLIC          wdc07        2761690   8     0          0   
   2342562   169.62.2.128      ADDITIONAL_PRIMARY   PUBLIC          wdc07        2761690   16    0          5
   

3. Répertoriez vos noeuds worker et obtenez leurs adresses IP publiques. Dans la sortie, les adresses IP publiques sont répertoriées dans la colonne External-IP. Notez quelles adresses IP sont contenues dans les sous-réseaux que vous avez répertoriés précédemment et notez ces ID de sous-réseau.

4. Pour chaque ID de sous-réseau, exécutez la commande pour obtenir les détails du sous-réseau. Dans chaque sortie, notez l'adresse IP dans la colonne identifier. Il s'agit de l'adresse IP que vous devez ajouter à la liste autorisée IAM.

   ibmcloud sl subnet detail <subnet_id>
   

   Exemple de sortie

   Name             Value   
   ID               2342562   
   identifier       169.62.2.128/28   
   subnet type      ADDITIONAL_PRIMARY   
   network space    PUBLIC   
   gateway          169.62.2.129   
   broadcast        169.62.2.143   
   datacenter       wdc07   
   usable ips       13   
   IP address       ID          IP address      
                   186531376   169.62.2.128      
                   186531378   169.62.2.129      
                   186531380   169.62.2.130      
                   186531382   169.62.2.131      
                   186531384   169.62.2.132      
                   186531386   169.62.2.133      
                   186531388   169.62.2.134      
                   186531390   169.62.2.135      
                   186531392   169.62.2.136      
                   186531394   169.62.2.137      
                   186531396   169.62.2.138      
                   186531398   169.62.2.139      
                   186531400   169.62.2.140      
                   186531402   169.62.2.141      
                   186531404   169.62.2.142      
                   186531406   169.62.2.143      
   virtual guests   hostname                                                 domain    public_ip      private_ip      
                   kube-c8ofi5pw077drsbovf90-roks47class-default-00000187   iks.ibm   169.62.2.130   10.191.55.109      
                   kube-c8ofi5pw077drsbovf90-roks47class-default-000002a2   iks.ibm   169.62.2.133   10.191.55.108      
                   kube-c8ofi5pw077drsbovf90-roks47class-default-00000372   iks.ibm   169.62.2.135   10.191.55.121      
                   kube-c8ofh6kw0jj8l6jovf8g-iks22classi-default-00000219   iks.ibm   169.62.2.132   10.191.55.105      
                   kube-c8ofh6kw0jj8l6jovf8g-iks22classi-default-0000012f   iks.ibm   169.62.2.134   10.191.55.107