Migración de los puntos finales de origen a los puntos finales compatibles

Clústeres clásicos

Debes tomar medidas si te encuentras en alguna de las siguientes situaciones:

• Dispones de uno o varios clústeres clásicos con el punto de conexión de servicio público habilitado y restringes el acceso saliente mediante listas de permitidos o cortafuegos.
• Tienes scripts o herramientas personalizadas que llaman directamente a los puntos de fin origin.<region>.containers.cloud.ibm.com.

Si no se cumple ninguna de las dos condiciones, no es necesario tomar ninguna medida.

Para mantener la conectividad de tus nodos de trabajo con IBM Cloud Kubernetes Service, sigue los siguientes pasos antes del 31 de julio de 2026.

• Si utilizas reglas de cortafuegos basadas en direcciones IP: asegúrate de que las direcciones IP indicadas en la sección «Permitir que los nodos de trabajo se comuniquen con el maestro del clúster» figuren en tus reglas de cortafuegos.

• Si utilizas reglas de cortafuegos basadas en dominios: añade los siguientes dominios de arranque a tu lista de dominios permitidos.

• Si tienes scripts personalizados que llaman directamente a los puntos finales de origen: cambia a los puntos finales de la API compatibles. Para obtener más información, consulta la sección « Acerca de la API ».

Antes de empezar, apunte la dirección IP pública de cada uno de los nodos trabajadores del clúster.

ibmcloud ks worker ls --cluster <cluster_name_or_ID>

Permita que los nodos trabajadores se comuniquen con el maestro del clúster

Para permitir que los nodos de trabajador se comuniquen con el maestro de clúster a través del punto final de servicio de nube pública, permita el tráfico de red saliente desde el <each_worker_node_publicIP> de origen al rango de puertos TCP/UDP de destino 30000-32767 y el puerto 443, y las siguientes direcciones IP y grupos de red.

Esta tabla se está moviendo. Para obtener las últimas listas de IP y actualizaciones continuas, consulte la carpeta de aislamiento de red pública en el IBM/kube-samples repositorio de . Puedes consultar las solicitudes de incorporación de cambios (pull requests) en el repositorio para estar al tanto de las actualizaciones.

• TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_publicIP> TO <public_IPs>
• Sustituya <public_IPs> por las direcciones IP públicas de la región en la que se encuentra el clúster.

Permita que los nodos trabajadores se comuniquen con IBM Cloud Container Registry

Permite el tráfico de red saliente desde tus nodos de trabajo hacia IBM Cloud Container Registry. Para obtener más información, consulte Acceso a IBM Cloud Container Registry a través de un cortafuegos.

Permita el tráfico de red saliente desde el nodo trabajador a IAM

Permita el tráfico de red de salida desde el nodo trabajador a IBM Cloud Identity and Access Management (IAM). Tu lista de permitidos debe ser de capa 7 para permitir el nombre de dominio de IAM. IAM no tiene direcciones IP específicas que se pueda permitir. Si tu lista de permitidos no admite la capa 7, puedes permitir todo el tráfico de red de HTTPS en el puerto 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

Opcional: permita el tráfico de red saliente desde los nodos trabajadores a Monitoring y a los servicios de IBM Cloud Logs

• IBM Cloud Monitoring:

  • TCP port 443, port 6443 FROM <each_worker_node_public_IP> TO <monitoring_public_IP>
  • Sustituya <monitoring_public_IP> por las direcciones IP de Monitoring.

• IBM Cloud Logs:

  • TCP port 443, port 80 FROM <each_worker_node_public_IP> TO <logging_public_IP>
  • Sustituya <logging_public_IP> por las direcciones IP de IBM Cloud Logs.

Opcional: Permita el tráfico de red entrante y saliente para el complemento de Istio gestionado

• Permita el tráfico de red saliente desde el equilibrador de carga de istio-egressgateway a través de los puertos siguientes: TCP port 80, port 15443 FROM <each_worker_node_publicIP>
• Permita el tráfico de red entrante al plano de control de istiod y al equilibrador de carga de istio-ingressgateway a través de los puertos siguientes: TCP port 443, port 853, port 15010, port 15012, port 15014 FROM <each_worker_node_publicIP>

Opcional: Permitir el tráfico de red entrante para la supervisión del subdominio de entrada

Si desea utilizar la monitorización de la salud del dominio Ingress para monitorizar la salud de sus puntos finales de servicio, debe permitir el acceso entrante desde los servicios de monitorización.

Por defecto, las peticiones de monitorización de estado se envían a través de HTTPS al puerto 443, por lo que debe permitir el tráfico de los siguientes rangos de IP dirigidos al puerto 443. Si su monitor de salud está configurado para utilizar HTTP en su lugar, el tráfico de la lista de permisos debe dirigirse al puerto 80. Además, si utiliza un puerto TCP personalizado, asegúrese de permitir el tráfico entrante a ese puerto.

Para más información, consulte la documentación de IBM NS1 Connect sobre supervisión.

Próximos pasos

Si utiliza los servicios de equilibrador de carga, asegúrese de que todo el tráfico que utiliza el protocolo VRRP está permitido entre nodos de trabajador en las interfaces públicas y privadas. IBM Cloud Kubernetes Service utiliza el protocolo VRRP para gestionar las direcciones IP para los equilibradores de carga públicos y privados.

Permita que los nodos trabajadores se comuniquen con el maestro del clúster

Para permitir que los nodos de trabajador se comuniquen con el maestro de clúster a través del punto final de servicio de nube privada, permita el tráfico de red saliente desde el <each_worker_node_privateIP> de origen al rango de puertos TCP/UDP de destino 30000-32767 y el puerto 443, y las siguientes direcciones IP y grupos de red.

Esta tabla se está moviendo. Para obtener las últimas listas de IP y actualizaciones continuas, consulte la carpeta de aislamiento de red privada en el IBM/kube-samples repositorio de . Puedes consultar las solicitudes de incorporación de cambios (pull requests) en el repositorio para estar al tanto de las actualizaciones.

• TCP/UDP port range 30000-32767, port 443 FROM <each_worker_node_privateIP> TO <private_IPs>
• Sustituya <private_IPs> por las direcciones IP privadas de la región en la que se encuentra el clúster.

Abra los puertos

Abra los puertos siguientes en la lista de elementos permitidos para que los nodos trabajadores funcionen correctamente. Los siguientes puertos deben estar abiertos para todas las IP de destino.

• Permita las conexiones TCP y UDP de salida de los nodos trabajadores a los puertos 80 y 443 para permitir actualizaciones y recargas de nodos trabajadores.
• Permita TCP y UDP de salida al puerto 2049 para permitir montar el almacenamiento de archivos como volúmenes.
• Permita TCP de salida y UDP al puerto 3260 para la comunicación con el almacenamiento en bloque.
• Permita las conexiones TCP y UDP de entrada al puerto 10250 para el panel de control de Kubernetes y los mandatos como kubectl logs y kubectl exec.
• Permita las conexiones de entrada y salida al puerto 53 TCP y UDP para el acceso de DNS.

Habilite la comunicación trabajador-a-trabajador

Habilita la comunicación entre nodos de trabajo permitiendo todo el tráfico de TCP, UDP, VRRP e IPEncap entre los nodos de trabajo en las interfaces privadas, y permite también VRRP en la interfaz pública. IBM Cloud Kubernetes Service utiliza el protocolo VRRP para gestionar las direcciones IP de los equilibradores de carga y el protocolo IPEncap para permitir el tráfico entre pods a través de subredes.

Permita que los nodos trabajadores se comuniquen con IBM Cloud Container Registry

Para permitir que los nodos de trabajador se comuniquen con IBM Cloud Container Registry, permita el tráfico de red saliente desde los nodos de trabajador a las regiones de IBM Cloud Container Registry.

• TCP port 443 FROM <each_worker_node_privateIP> TO <registry_ip>
• Sustituya <registry_ip> por la dirección IP de registro a la que desea permitir el tráfico. El registro global almacena imágenes públicas proporcionadas por IBM y los registros regionales almacenan sus propias imágenes privadas o públicas.

Suprimir reclamaciones de volumen persistente

Para crear reclamaciones de volúmenes persistentes en un clúster en el que los nodos trabajadores solo se conectan a VLAN privadas, asegúrese de que el clúster se haya configurado con la versión de Kubernetes o las versiones del plugin de almacenamiento de IBM Cloud siguientes. Estas versiones permiten la comunicación de red privada entre el clúster y las instancias de almacenamiento persistente.

Si debe utilizar una versión de Kubernetes o una versión del complemento de almacenamiento IBM Cloud que no admita la comunicación de red a través de la red privada, o si desea utilizar IBM Cloud Object Storage sin autenticación HMAC, permita el acceso de salida a través de su lista de permitidos a la infraestructura de IBM Cloud y a IBM Cloud Identity and Access Management:

• Permita todo el tráfico de red de salida en el puerto TCP 443.
• Permita el acceso al rango de IP de la infraestructura de IBM Cloud correspondiente a la zona en la que se encuentra el clúster tanto para la red frontal (pública) como para la red de fondo (privada). Para buscar la zona del clúster, ejecute ibmcloud ks cluster ls.

Opcional: Configurar reglas allowlist para los servicios IBM Cloud Logs y IBM Cloud Monitoring

Para enviar datos de registro y métricas, configura reglas de lista de permitidos para tus servicios IBM Cloud Logs y IBM Cloud Monitoring.

• IBM Cloud Logs puntos finales privados
• Puntos finales privados de Monitoring

Obtención de las direcciones IP de subred en la consola

1. En la lista de recursos de la consola de administración de IBM Cloud, haga clic en su clúster.
2. Nodos de Click Worker.
3. Anote cada VLAN pública utilizada por los nodos trabajadores del clúster. Varios nodos trabajadores pueden utilizar la misma VLAN pública.
4. En el menú de la consola IBM Cloud , haga clic en Infraestructura > Infraestructura clásica > Gestión de IP > VLAN.
5. Haga clic en cada VLAN pública para comprobar si la utilizan los nodos de trabajo de su clúster.
6. Para cada VLAN pública utilizada por los nodos trabajadores del clúster, busque la sección Subnets y anote cada dirección IP incluida en la tabla. Estas son las direcciones IP que debe incluir en la lista de elementos permitidos.

Obtención de las direcciones IP de subred en la CLI

1. Liste las VLAN públicas que utilizan los nodos trabajadores. La salida se formatea como publicVLAN=<vlan_id>.

   kubectl describe nodes | grep publicVLAN | sort | uniq
   

2. Para cada VLAN pública, busque las subredes públicas asociadas. En la salida, anote las direcciones IP de subred en la columna identifier.

   ibmcloud sl subnet list | grep <vlan-id>
   

   Salida de ejemplo de subredes asociadas con la VLAN pública con el 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. Liste los nodos trabajadores y obtenga sus IP públicas. En la salida, las IP públicas se listan en la columna External-IP. Tenga en cuenta cuáles de estas direcciones IP están contenidas en las subredes que ha listado anteriormente y anote estos ID de subred.

4. Para cada ID de subred, ejecute el mandato para obtener los detalles de la subred. En cada salida, anote la dirección IP en la columna identifier. Esta es la dirección IP que debe añadir a la lista de elementos permitidos de IAM.

   ibmcloud sl subnet detail <subnet_id>
   

   Salida de ejemplo

   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