Abrir los puertos y direcciones IP necesarios en tu lista de permitidos
Clústeres clásicos
Esta información sobre la lista de permitidos es específica de los clústeres clásicos. Para los clústeres de VPC, consulta « Abrir los puertos y direcciones IP necesarios en tu lista de permitidos para los clústeres de VPC ».
Revisa estas situaciones en las que podrías necesitar abrir puertos y direcciones IP específicos en tus listas de permitidos para tus clústeres de Red Hat® OpenShift® on IBM Cloud®.
- Listas de permitidos corporativas: Si las políticas de red de la empresa impiden el acceso desde tu sistema local a puntos finales públicos a través de proxies o listas de permitidos, debes permitir el acceso para ejecutar
comandos
ibmcloud,ibmcloud oc,ibmcloud cr,ocycalicoctldesde tu sistema local. - Listas de permitidos del dispositivo de puerta de enlace: Si tienes configuradas listas de permitidos en la red pública o privada de tu cuenta de infraestructura de IBM Cloud, como por ejemplo un VRA, debes habilitar rangos de IP, puertos y protocolos para permitir que los nodos de trabajo se comuniquen con el nodo maestro, con los recursos de infraestructura y con otros servicios de IBM Cloud. También puede abrir puertos para permitir el tráfico de entrada a los servicios que exponen apps en el clúster.
- Calico Políticas de red: Si utiliz Calico es políticas de red como lista de permitidos para restringir todo el tráfico saliente de los nodos de trabajo, debes permitir que estos nodos accedan a los recursos necesarios para el funcionamiento del clúster.
- Otros servicios o listas de permitidos de red: Para que tu clúster pueda acceder a servicios que se ejecutan dentro o fuera de IBM Cloud o en redes locales y que estén protegidos por una lista de permitidos, debes añadir las direcciones IP de tus nodos de trabajo a dicha lista.
Abrir puertos en una lista de permisos corporativa
Si las políticas de la red corporativa impiden el acceso desde tu sistema local a los puntos finales públicos mediante proxies o listas de permitidos, debes habilitar el acceso para poder ejecutar ibmcloud, comandos ibmcloud oc`` y ibmcloud cr ,
oc comandos y calicoctl comandos desde tu sistema local.
Ejecución de comandos « ibmcloud », « ibmcloud oc » y « ibmcloud cr » desde una lista de permitidos
Si las políticas de la red corporativa impiden el acceso desde tu sistema local a los terminales públicos a través de proxies o listas de permitidos, para ejecutar comandos ibmcloud, ibmcloud oc y ibmcloud cr,
debes permitir el acceso a TCP para IBM Cloud, Red Hat OpenShift on IBM Cloud y IBM Cloud Container Registry.
-
Añade
cloud.ibm.comen el puerto 443 a tu lista de direcciones permitidas. -
Verifique la conexión iniciando una sesión en IBM Cloud a través de este punto final de API.
ibmcloud login -a https://cloud.ibm.com/ -
Añade
containers.cloud.ibm.comen el puerto 443 a tu lista de direcciones permitidas. -
Compruebe la conexión. Si el acceso está configurado correctamente, las zonas se muestran en la salida.
curl https://containers.cloud.ibm.com/v1/zonesSalida de ejemplo
[{"id":"mon01","metro":""},{"id":"tor01","metro":""},{"id":"wdc04","metro":"Washington D.C."},{"id":"wdc06","metro":"Washington D.C."},{"id":"wdc07","metro":"Washington D.C."}] -
Permite el acceso a las regiones de IBM Cloud Container Registry que tengas previsto utilizar en el puerto 443 en tu lista de permitidos. El registro global almacena imágenes públicas proporcionadas por IBM y los registros regionales almacenan sus propias imágenes privadas o públicas.
-
Comprueba tu conexión enumerando los espacios de nombres de tu registro de contenedores.
Ejecución de mandatos oc desde detrás de una lista de elementos permitidos
Si las políticas de la red corporativa impiden el acceso desde tu sistema local a los terminales públicos mediante proxies o listas de permitidos, para ejecutar comandos de oc, debes permitir el acceso TCP para el clúster.
Cuando se crea un clúster, el puerto en los URL de punto final de servicio se asigna aleatoriamente del rango 30000-32767. Puede optar por abrir el rango de puertos 30000-32767 para cualquier clúster que se pueda crear o puede optar por permitir el acceso para un clúster existente específico.
Antes de empezar, permita el acceso para ejecutar mandatos ibmcloud oc.
Para permitir el acceso a un clúster específico:
-
Inicie una sesión en la CLI de IBM Cloud. Escriba sus credenciales de IBM Cloud cuando se le solicite. Si tiene una cuenta federada, incluya la opción
--sso.ibmcloud login [--sso] -
Si el clúster está en un grupo de recursos distinto de
default, elija como destino dicho grupo de recursos. Para ver el grupo de recursos al que pertenece cada clúster, ejecuteibmcloud oc cluster ls. Nota: Debe tener al menos el rol de Visor para el grupo de recursos.ibmcloud target -g <resource_group_name> -
Obtenga el nombre del clúster.
ibmcloud oc cluster ls -
Recupere los URL de punto final de servicio para el clúster.
- Si solo está especificado el URL de punto final de servicio público, obtenga este URL. Los usuarios autorizados del clúster pueden acceder al nodo maestro a través de este punto final en la red pública.
- Si solo está especificado el URL de punto final de servicio privado, obtenga este URL. Los usuarios autorizados del clúster pueden acceder al nodo maestro a través de este punto final en la red privada.
- Si tanto el URL de punto final de servicio público como el URL de punto final de servicio privado están especificados, obtenga los dos URL. Los usuarios autorizados del clúster pueden acceder al nodo maestro a través del punto final público de la red pública o del punto final privado de la red privada.
ibmcloud oc cluster get --cluster <cluster_name_or_ID>Salida de ejemplo
... Public Service Endpoint URL: https://c3.<region>.containers.cloud.ibm.com:30426 Private Service Endpoint URL: https://c3-private.<region>.containers.cloud.ibm.com:31140 ... -
Permita el acceso a los URL de punto final de servicio y a los puertos que ha obtenido en el paso anterior. Si tu lista de permitidos se basa en direcciones IP, puedes consultar esta tabla para ver qué direcciones IP tienen acceso al servicio cuando permites el acceso a las URL de los puntos finales del servicio.
-
Compruebe la conexión.
- Si el punto final de servicio en la nube público está habilitado:
curl --insecure <public_service_endpoint_URL>/version ``` Mandato de ejemplo: ```sh {: pre} curl --insecure https://c3.<region>.containers.cloud.ibm.com:31142/version ``` Salida de ejemplo ```sh {: screen} { "major": "1", "minor": "7+", "gitVersion": "v1.7.4-2+eb9172c211dc41", "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534", "gitTreeState": "clean", "buildDate": "2017-11-16T08:13:08Z", "goVersion": "go1.8.3", "compiler": "gc", "platform": "linux/amd64" } ``` - Si está habilitado el punto final de servicio en la nube privado, debe estar en la red privada de IBM Cloud o debe conectarse a la red privada a través de una conexión VPN para verificar la conexión con el nodo maestro. **Nota**: Debe [exponer el punto final maestro a través de un equilibrador de carga privado](/docs/openshift?topic=openshift-access_cluster#access_private_se) para que los usuarios puedan acceder al nodo maestro a través de una conexión VPN o IBM Cloud® Direct Link. ```sh {: pre} curl --insecure <private_service_endpoint_URL>/version ``` Mandato de ejemplo: ```sh {: pre} curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version ``` Salida de ejemplo ```sh {: screen} { "major": "1", "minor": "7+", "gitVersion": "v1.7.4-2+eb9172c211dc41", "gitCommit": "eb9172c211dc4108341c0fd5340ee5200f0ec534", "gitTreeState": "clean", "buildDate": "2017-11-16T08:13:08Z", "goVersion": "go1.8.3", "compiler": "gc", "platform": "linux/amd64" } ``` -
Opcional: repita estos pasos para cada clúster que necesite exponer.
Ejecución de mandatos calicoctl desde detrás de una lista de elementos permitidos
Si las políticas de la red corporativa impiden el acceso desde tu sistema local a los puntos finales públicos a través de proxies o listas de permitidos, para ejecutar comandos calicoctl, debes permitir el acceso TCP para los
comandos Calico.
Antes de empezar, permite el acceso a ibmcloud comandos y oc comandos.
-
Recupera la dirección IP del servidor principal URL que utilizaste para autorizar el acceso a
occomandos. -
Obtenga el puerto para etcd.
oc get cm -n kube-system cluster-info -o yaml | grep etcd_host -
Permita el acceso para las políticas de Calico mediante la dirección IP del URL maestro y el puerto etcd.
Abrir puertos en las listas de permisos de los dispositivos de puerta de enlace
Si tienes listas de permitidos configuradas en la red pública o en la red privada de tu cuenta de infraestructura de IBM Cloud, como por ejemplo un « Virtual Router Appliance » (Vyatta), debes habilitar rangos de IP, puertos y protocolos para permitir que los nodos de trabajo se comuniquen con el nodo maestro, con los recursos de infraestructura y con otros servicios de IBM Cloud.
Abrir los puertos necesarios en una lista de permitidos pública
Si dispones de una lista de permitidos en la red pública de tu cuenta de infraestructura de IBM Cloud, como, por ejemplo, un « Virtual Router Appliance » (Vyatta), debes habilitar rangos de IP, puertos y protocolos en dicha lista para permitir que los nodos de trabajo se comuniquen con el nodo maestro, con los recursos de infraestructura y con otros servicios de IBM Cloud.
Acción necesaria antes del 31 de julio de 2026: Los puntos finales de origin.<region>.containers.cloud.ibm.com van a dejar de estar disponibles. Si dispone de clústeres clásicos con el punto final de servicio
público habilitado y restringe el acceso saliente mediante listas de permitidos o cortafuegos, o si tiene scripts personalizados que llaman directamente a estos puntos finales de origen, deberá actualizar sus configuraciones antes del 31
de julio de 2026 para evitar interrupciones en el servicio. Para obtener más información, consulta « Migración de puntos finales de origen a puntos finales compatibles ».
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 Red Hat OpenShift on IBM Cloud, 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.
| Región | Dominio de arranque |
|---|---|
EU Central (fra02, fra04, fra05) |
bootstrap.eu-de.containers.cloud.ibm.com |
RU sur (lon02, lon04, lon05, lon06) |
bootstrap.eu-gb.containers.cloud.ibm.com |
Madrid (mad02, mad04, mad05) |
bootstrap.eu-es.containers.cloud.ibm.com |
Osaka (osa21, osa22,osa23) |
bootstrap.jp-osa.containers.cloud.ibm.com |
São Paulo (sao01, sao04, sao05) |
bootstrap.br-sao.containers.cloud.ibm.com |
AP sur (syd01, syd04, syd05) |
bootstrap.au-syd.containers.cloud.ibm.com |
AP North (tok02, tok04, tok05) |
bootstrap.jp-tok.containers.cloud.ibm.com |
Toronto (tor01, tor04, tor05) |
bootstrap.ca-tor.containers.cloud.ibm.com |
Sur de EE. UU. (dal10, dal12, dal13) |
bootstrap.us-south.containers.cloud.ibm.com |
Este de EE. UU. (wdc04, wdc06, wdc07) |
bootstrap.us-east.containers.cloud.ibm.com |
- 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 oc 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. Además, si tiene previsto utilizar Ingress o rutas para exponer apps en el clúster, permita también el tráfico de red de entrada a través de estos puertos a las direcciones IP del nodo trabajador para que el plano de control de Red Hat OpenShift pueda comprobar el estado de los direccionadores.
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 estar atento a las solicitudes de incorporación de cambios en el repositorio para ver si hay novedades.
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.
| Región | Dirección IP pública |
|---|---|
AP North (che01, sng01, tok02, tok04, tok05) |
119.81.194.90, 119.81.222.210, 128.168.106.194, 128.168.71.117, 128.168.75.194, 128.168.85.154, 135.90.69.66, 135.90.69.82, 161.202.126.210,
161.202.154.10, 161.202.186.226, 161.202.56.10, 161.202.57.34, 165.192.69.69, 165.192.80.146, 165.192.83.202, 165.192.95.90,
169.38.68.178, 169.38.70.10, 169.38.79.170, 169.56.1.162, 169.56.132.234, 169.56.48.114, 169.56.69.242, 169.56.96.42, 104.94.220.124,
104.94.221.124, 104.94.222.132, 104.94.223.132, 104.96.176.124, 104.96.177.124, 104.96.178.126, 104.96.179.126, 104.96.180.123,
104.96.181.123 |
AP sur (syd01, syd04, syd05) |
130.198.64.19, 130.198.66.26, 130.198.79.170, 130.198.83.34, 130.198.102.82, 135.90.66.2, 135.90.68.114, 135.90.69.66, 135.90.69.82,
135.90.89.234, 168.1.6.106, 168.1.8.195, 168.1.12.98, 168.1.39.34, 168.1.58.66, 104.94.220.125, 104.94.221.125, 104.94.222.133,
104.94.223.133, 104.96.176.125, 104.96.177.125, 104.96.178.127, 104.96.179.127, 104.96.180.124, 104.96.181.124 |
UE Central (ams03, par01, fra02, fra04, fra05) |
149.81.103.98, 149.81.104.122, 149.81.113.154, 149.81.123.18, 149.81.142.90, 149.81.180.114, 149.81.180.122, 149.81.68.2, 149.81.78.114,
158.177.102.162, 158.177.107.50, 158.177.112.146, 158.177.138.138, 158.177.151.2, 158.177.156.178, 158.177.198.138, 158.177.79.34,
159.8.79.250, 159.8.86.149, 159.8.95.34, 161.156.115.138, 161.156.120.74, 161.156.12.82, 161.156.183.218, 161.156.187.226, 161.156.65.42,
161.156.65.82, 161.156.74.10, 161.156.79.26, 169.50.146.82, 169.50.169.110, 169.50.184.18, 169.50.56.174, 104.94.220.127, 104.94.221.127,
104.94.222.135, 104.94.223.135, 104.96.176.127, 104.96.177.127, 104.96.178.129, 104.96.179.129, 104.96.180.126, 104.96.181.126 |
Madrid (mad02, mad04, mad05) |
13.120.65.98, 13.120.127.250, 13.121.64.178, 13.121.64.186, 13.122.65.10, 13.122.65.34, 2.18.48.89, 2.18.49.89, 2.18.50.89,
2.18.51.89, 2.18.52.89, 2.18.53.89, 2.18.54.89, 2.18.55.89, 23.40.100.89, 23.7.244.89 |
Osaka (osa21, osa22,osa23) |
163.68.69.114, 163.68.69.122, 163.69.65.114, 163.69.65.122, 163.73.64.250, 163.73.65.194, 104.94.220.131, 104.94.221.131, 104.94.222.139,
104.94.223.139, 104.96.176.131, 104.96.177.131, 104.96.178.133, 104.96.179.133, 104.96.180.130, 104.96.181.130 |
São Paulo (sao01, sao04, sao05) |
163.107.65.194, 163.107.65.202, 163.109.65.154, 163.109.65.242, 169.57.159.130, 169.57.254.50, 104.94.220.129, 104.94.221.129,
104.94.222.137, 104.94.223.137, 104.96.176.129, 104.96.177.129, 104.96.178.131, 104.96.179.131, 104.96.180.128, 104.96.181.128 |
Toronto (tor01, tor04, tor05) |
158.85.77.114, 163.74.65.250, 163.75.64.162, 104.94.220.132, 104.94.221.132, 104.94.222.140, 104.94.223.140, 104.96.176.132, 104.96.177.132,
104.96.178.134, 104.96.179.134, 104.96.180.131, 104.96.181.131 |
RU sur (lon02, lon04, lon05, lon06) |
141.125.102.106, 141.125.66.26, 141.125.67.34, 141.125.77.58, 141.125.91.138, 158.175.111.42, 158.175.125.194, 158.175.139.130,
158.175.150.122, 158.175.65.170, 158.175.77.178, 158.175.82.50, 158.176.123.130, 158.176.135.242, 158.176.142.26, 158.176.149.154,
158.176.71.242, 158.176.94.26, 158.176.95.146, 159.122.224.242, 159.122.242.78, 104.94.220.126, 104.94.221.126, 104.94.222.134,
104.94.223.134, 104.96.176.126, 104.96.177.126, 104.96.178.128, 104.96.179.128, 104.96.180.125, 104.96.181.125 |
EE. UU. este (mon01, wdc04, wdc06, wdc07) |
158.85.97.34, 169.47.162.130, 169.47.174.106, 169.53.167.50, 169.53.171.210, 169.54.126.219, 169.54.80.106, 169.54.94.26, 169.60.100.242,
169.60.101.42, 169.60.111.58, 169.60.73.142, 169.60.92.50, 169.60.92.66, 169.61.109.34, 169.61.110.66, 169.61.74.210, 169.61.83.62,
169.62.10.162, 169.62.9.250, 169.63.106.50, 169.63.111.82, 169.63.149.122, 169.63.158.82, 169.63.160.130, 169.63.66.226, 169.63.75.82,
169.63.88.178, 169.63.88.186, 169.63.94.210, 52.117.72.42, 52.117.88.42, 104.94.220.128, 104.94.221.128, 104.94.222.136, 104.94.223.136,
104.96.176.128, 104.96.177.128, 104.96.178.130, 104.96.179.130, 104.96.180.127, 104.96.181.127 |
Sur de EE. UU. (sjc03, sjc04, dal10, dal12, dal13) |
50.22.129.34, 52.116.231.210, 52.116.254.234, 52.116.54.122, 52.117.197.210, 52.117.212.34, 52.117.215.162, 52.117.232.194, 52.117.240.106,
52.117.28.138, 67.228.97.210, 169.45.126.154, 169.45.67.210, 169.45.88.98, 169.46.110.218, 169.46.111.122, 169.46.16.202, 169.46.24.210,
169.46.27.234, 169.46.63.250, 169.46.68.234, 169.46.7.238, 169.46.89.50, 169.47.109.34, 169.47.115.18, 169.47.201.194, 169.47.209.66,
169.47.229.90, 169.47.232.210, 169.47.239.34, 169.47.242.242, 169.47.70.10, 169.47.71.138, 169.48.110.250, 169.48.143.218, 169.48.161.242,
169.48.226.2, 169.48.230.146, 169.48.244.66, 169.57.100.18, 169.57.13.10, 169.57.147.58, 169.57.151.10, 169.57.154.98, 169.59.219.90,
169.59.223.194, 169.59.230.98, 169.60.128.2, 169.60.170.234, 169.61.175.106, 169.61.177.2, 169.61.187.58, 169.61.228.138, 169.61.28.66,
169.61.29.194, 169.61.60.130, 169.62.166.98, 169.62.189.26, 169.62.206.234, 169.62.230.114, 169.62.82.197, 169.62.87.170, 169.62.97.218,
169.63.39.66, 169.63.47.250, 104.94.220.130, 104.94.221.130, 104.94.222.138, 104.94.223.138, 104.96.176.130, 104.96.177.130,
104.96.178.132, 104.96.179.132, 104.96.180.129, 104.96.181.129 |
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 es compatible con 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.netTCP 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: 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.
IBM NS1 Connect Supervisión de rangos IP
163.114.225.0/24163.114.230.0/24163.114.231.0/24
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. Red Hat OpenShift on IBM Cloud utiliza el protocolo VRRP para gestionar las direcciones IP para los equilibradores de carga públicos y privados.
Si utilizas Ingress o rutas para exponer aplicaciones en tu clúster, permite el tráfico de red entrante procedente de las direcciones IP de origen IBM y NS1 en el puerto 80 hacia las direcciones IP de tus servicios de enrutador, de modo que el plano de control de Red Hat OpenShift pueda comprobar el estado de tus enrutadores.
Abrir los puertos necesarios en una lista de permitidos privada
Si dispones de una lista de permitidos en la red privada de tu cuenta de infraestructura de IBM Cloud, como un « Virtual Router Appliance » (Vyatta), debes habilitar rangos de IP, puertos y protocolos en dicha lista para permitir que los nodos de trabajo se comuniquen con el nodo maestro, entre sí, con los recursos de infraestructura y con otros servicios de IBM Cloud.
Antes de empezar
-
Permita los rangos de IP privados de la infraestructura de IBM Cloud para poder crear nodos trabajadores en el clúster.
- Permita los rangos de IP privados adecuados de la infraestructura de IBM Cloud. Consulte Red (privada) de fondo.
- Permita los rangos de IP privada de la infraestructura de IBM Cloud para todas los zonas que está utilizando. Nota: Debe añadir los rangos de IP
166.8.0.0/14y161.26.0.0/16, los rangos de IP para las zonasdal10ywdc04. Consulte Red de servicio (en red de fondo/privada).
-
Anote la dirección IP privada de cada nodo trabajador del clúster.
ibmcloud oc 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 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 estar atento a las solicitudes de incorporación de cambios en el repositorio para ver si hay novedades.
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.
| Región | Dirección IP privada |
|---|---|
AP North (che01, sng01, tok02, tok04, tok05) |
166.9.40.102, 166.9.40.21, 166.9.40.36, 166.9.40.39, 166.9.40.6, 166.9.40.7, 166.9.40.8, 166.9.40.88, 166.9.42.23,
166.9.42.28, 166.9.42.55, 166.9.42.6, 166.9.42.7, 166.9.42.97, 166.9.44.15, 166.9.44.3, 166.9.44.4, 166.9.44.47,
166.9.44.5, 166.9.44.88, 166.9.46.4, 166.9.60.2, 166.9.60.4, 166.9.249.106, 166.9.249.136, 166.9.249.170 |
AP sur (syd01, syd04, syd05) |
166.9.52.14, 166.9.52.15, 166.9.52.23, 166.9.52.30, 166.9.52.31, 166.9.54.11, 166.9.54.12, 166.9.54.13, 166.9.54.21,
166.9.54.32, 166.9.54.33, 166.9.56.10, 166.9.56.11, 166.9.56.16, 166.9.56.24, 166.9.56.36, 166.9.244.107, 166.9.244.137,
166.9.244.171 |
UE Central (ams03, par01, fra02, fra04, fra05) |
166.9.28.107, 166.9.28.17, 166.9.28.19, 166.9.28.20, 166.9.28.203, 166.9.28.22, 166.9.28.23, 166.9.28.235, 166.9.28.24,
166.9.28.240, 166.9.28.43, 166.9.28.64, 166.9.28.84, 166.9.28.87, 166.9.28.91, 166.9.28.94, 166.9.28.95, 166.9.30.100,
166.9.30.11, 166.9.30.116, 166.9.30.12, 166.9.30.13, 166.9.30.22, 166.9.30.41, 166.9.30.54, 166.9.30.56, 166.9.30.9,
166.9.30.92, 166.9.32.101, 166.9.32.185, 166.9.32.20, 166.9.32.26, 166.9.32.27, 166.9.32.44, 166.9.32.54, 166.9.32.56,
166.9.32.84, 166.9.32.88, 166.9.32.9, 166.9.248.77, 166.9.248.106, 166.9.248.137 |
Madrid (mad02, mad04, mad05) |
166.9.94.6, 166.9.95.6, 166.9.96.6, 166.9.94.7, 166.9.95.7, 166.9.96.7 |
Osaka (osa21, osa22,osa23) |
166.9.70.6, 166.9.70.8, 166.9.71.8, 166.9.71.10, 166.9.72.9, 166.9.72.10, 166.9.247.41, 166.9.247.75, 166.9.247.107 |
Reino Unido sur (lon02,lon04, lon05, lon06) |
166.9.34.17, 166.9.34.41, 166.9.34.45, 166.9.34.5, 166.9.34.50, 166.9.34.6, 166.9.34.77, 166.9.36.10, 166.9.36.11,
166.9.36.12, 166.9.36.13, 166.9.36.23, 166.9.36.30, 166.9.36.53, 166.9.36.65, 166.9.36.95, 166.9.38.18, 166.9.38.28,
166.9.38.46, 166.9.38.54, 166.9.38.6, 166.9.38.7, 166.9.38.75, 166.9.244.12, 166.9.244.48, 166.9.244.75 |
EE. UU. Este (mon01, tor01, wdc04, wdc06, wdc07) |
166.9.20.11, 166.9.20.117, 166.9.20.12, 166.9.20.13, 166.9.20.187, 166.9.20.38, 166.9.20.42, 166.9.20.63, 166.9.20.80,
166.9.22.10, 166.9.22.109, 166.9.22.211, 166.9.22.215, 166.9.22.26, 166.9.22.43, 166.9.22.51, 166.9.22.52, 166.9.22.8,
166.9.22.9, 166.9.24.19, 166.9.24.196, 166.9.24.198, 166.9.24.22, 166.9.24.35, 166.9.24.4, 166.9.24.45, 166.9.24.47,
166.9.24.5, 166.9.24.90, 166.9.68.130, 166.9.68.134, 166.9.68.34, 166.9.68.47, 166.9.231.217, 166.9.232.15, 166.9.251.118 |
EE. UU. sur (sao01, sjc03, sjc04, dal10, dal12, dal13) |
166.9.12.140, 166.9.12.141, 166.9.12.142, 166.9.12.143, 166.9.12.144, 166.9.12.151, 166.9.12.193, 166.9.12.196, 166.9.12.26,
166.9.12.99, 166.9.13.31, 166.9.13.93, 166.9.13.94, 166.9.14.122, 166.9.14.125, 166.9.14.202, 166.9.14.204, 166.9.14.205,
166.9.14.95, 166.9.15.130, 166.9.15.69, 166.9.15.70, 166.9.15.71, 166.9.15.72, 166.9.15.73, 166.9.15.74, 166.9.15.75,
166.9.15.76, 166.9.16.113, 166.9.16.137, 166.9.16.149, 166.9.16.183, 166.9.16.184, 166.9.16.185, 166.9.16.38, 166.9.16.39,
166.9.16.5, 166.9.17.2, 166.9.17.35, 166.9.17.37, 166.9.17.39, 166.9.48.124, 166.9.48.171, 166.9.48.175, 166.9.48.240,
166.9.48.35, 166.9.48.50, 166.9.48.76, 166.9.51.104, 166.9.51.106, 166.9.51.16, 166.9.51.54, 166.9.51.74, 166.9.58.104,
166.9.58.11, 166.9.58.16, 166.9.58.170, 166.9.58.210, 166.9.58.64, 166.9.58.65, 166.9.59.125, 166.9.59.147, 166.9.61.15,
166.9.61.54, 166.9.85.114, 166.9.88.186, 166.9.88.196, 166.9.88.21, 166.9.228.8, 166.9.229.10, 166.9.230.9 |
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 Red Hat OpenShift y los mandatos como
oc logsyoc exec. - Permita las conexiones de entrada y salida al puerto 53 TCP y UDP y el puerto 5353 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 el VRRP en la interfaz pública. Red Hat OpenShift on IBM Cloud 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.
| Región de Red Hat OpenShift on IBM Cloud | Dirección de registro | Registro de direcciones IP privadas hasta el 5 de julio de 2022 | Registro de direcciones IP privadas a partir del 5 de julio de 2022 |
|---|---|---|---|
| Registro global a través de regiones de Red Hat OpenShift on IBM Cloud | private.icr.io cp.icr.io |
166.9.20.31, 166.9.22.22, 166.9.24.16 | 166.9.251.49, 166.9.251.82, 166.9.251.113 |
| AP norte | private.jp.icr.io |
166.9.40.20, 166.9.42.21, 166.9.44.12 | 166.9.249.104, 166.9.249.157, 166.9.249.168 |
| AP sur | private.au.icr.io |
166.9.52.20, 166.9.54.19, 166.9.56.13 | 166.9.244.106, 166.9.244.136, 166.9.244.170 |
| UE central | private.de.icr.io |
166.9.28.35, 166.9.30.2, 166.9.32.2 | 166.9.248.76, 166.9.248.105, 166.9.248.136 |
| Madrid | private.es.icr.io |
N/D | 166.9.248.76, 166.9.248.105, 166.9.248.136 |
| Osaka | private.jp2.icr.io |
166.9.70.4, 166.9.71.5, 166.9.72.6 | 166.9.247.39, 166.9.247.73, 166.9.247.105 |
| Sao Paulo | private.br.icr.io |
166.9.82.13, 166.9.83.13, 166.9.84.13 | 166.9.246.72, 166.9.246.104, 166.9.246.130 |
| Toronto | private.ca.icr.io |
166.9.76.12, 166.9.77.11, 166.9.78.11 | 166.9.247.143, 166.9.247.170, 166.9.247.207 |
| Reino Unido sur | private.uk.icr.io |
166.9.36.19, 166.9.38.14, 166.9.34.12 | 166.9.244.9, 166.9.244.45, 166.9.244.73 |
| EE. UU. este, EE. UU. sur | private.us.icr.io |
166.9.12.227, 166.9.15.116, 166.9.16.244 | 166.9.250.214, 166.9.250.246, 166.9.251.21 |
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.
Apertura de puertos en una lista de elementos permitidos públicos o privados para el tráfico de entrada
Puede permitir el acceso a servicios NodePort, de equilibrador de carga e Ingress, y rutas de Red Hat OpenShift.
- Servicio NodePort
- Abra el puerto que ha configurado al desplegar el servicio en las direcciones IP públicas o privadas para todos los nodos de trabajador hacia los que se permite el tráfico. Para encontrar el puerto, ejecute
oc get svc. El puerto está en el rango 20000-32000. - Servicio equilibrador de carga
- Abra el puerto que ha configurado cuando ha desplegado el servicio a la dirección IP pública o privada del servicio de equilibrador de carga.
- Ingress
- Abra el puerto 80 para HTTP y el puerto 443 para HTTPS a la dirección IP pública o privada del equilibrador de carga de aplicación de Ingress.
- Ruta
- Abra el puerto 80 para HTTP y el puerto 443 para HTTPS a la dirección IP pública del direccionador.
Cómo permitir que el clúster acceda a recursos a través de políticas de red de Calico
En lugar de configurar un dispositivo de lista de permitidos en la puerta de enlace, puedes optar por utilizar las políticas de red de « Calico » para que actúen como una lista de permitidos del clúster en la red pública o privada. Para obtener más información, consulte los temas siguientes.
Permitir el tráfico procedente de tu clúster en las listas de permitidos de otros servicios o en las listas de permitidos locales
Si deseas acceder a servicios que se ejecutan dentro o fuera de IBM Cloud, o en tus propias instalaciones, y que están protegidos por una lista de permitidos, puedes añadir las direcciones IP de tus nodos de trabajo a dicha lista para permitir el tráfico de red saliente hacia tu clúster. Por ejemplo, es posible que quieras leer datos de una base de datos de IBM Cloud protegida por una lista de permitidos, o especificar las subredes de tus nodos de trabajo en una lista de permitidos local para permitir el tráfico de red procedente de tu clúster.
-
Obtenga las subredes de nodos trabajadores o las direcciones IP de los nodos trabajadores.
-
Subredes de los nodos de trabajo: Si prevés cambiar con frecuencia el número de nodos de trabajo de tu clúster —por ejemplo, si activas el escalador automático del clúster —, es posible que no te convenga actualizar tu lista de direcciones permitidas cada vez que se añada un nuevo nodo de trabajo. Puede, en su lugar, añadir las subredes de VLAN que utiliza el clúster. Tenga en cuenta que es posible que la subred de VLAN se comparta con nodos trabajadores de otros clústeres. Tenga en cuenta que las subredes públicas primarias que Red Hat OpenShift on IBM Cloud aprovisiona para el clúster incluyen 14 direcciones IP disponibles, y los demás clústeres de la misma VLAN las pueden compartir. Si tiene más de 14 nodos trabajadores, se solicita otra subred de modo que las subredes que debe permitir pueden cambiar. Para reducir la frecuencia de cambios, cree agrupaciones de nodos trabajadores con tipos de nodos trabajadores con más recursos de CPU y memoria para que no tenga que añadir nodos trabajadores con tanta frecuencia.
-
Obtenga una lista de los nodos trabajadores del clúster.
ibmcloud oc worker ls --cluster <cluster_name_or_ID> -
En la salida del paso anterior, anote todos los ID de red exclusivos (primeros tres octetos) de la IP pública para los nodos trabajadores del clúster. En la salida siguiente, los ID de red exclusivos son
169.xx.178y169.xx.210.ID Public IP Private IP Machine Type State Status Zone Version kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w31 169.xx.178.101 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal10 1.35 kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w34 169.xx.178.102 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal10 1.35 kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w32 169.xx.210.101 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal12 1.35 kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w33 169.xx.210.102 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal12 1.35 -
Obtenga una lista de las subredes VLAN para cada ID de red exclusivo.
ibmcloud sl subnet list | grep -e <networkID1> -e <networkID2>Salida de ejemplo
ID identifier type network_space datacenter vlan_id IPs hardware virtual_servers 1234567 169.xx.210.xxx ADDITIONAL_PRIMARY PUBLIC dal12 1122334 16 0 5 7654321 169.xx.178.xxx ADDITIONAL_PRIMARY PUBLIC dal10 4332211 16 0 6 -
Recupere la dirección de subred. En la salida, busque el número de IP. Luego eleve
2a lanpotencia, igual al número de IP. Por ejemplo, si el número de IP es16, se eleva2a la4potencia (n), lo que es igual a16. A continuación, obtenga el CIDR de la subred restando el valor dende32bits. Por ejemplo, sines igual a4, el CIDR es28(resultado de la ecuación32 - 4 = 28). Combine la máscara identifier con el valor de CIDR para obtener la dirección completa de la subred. En la salida anterior, las direcciones de subred son las siguientes:169.xx.210.xxx/28169.xx.178.xxx/28
-
-
Direcciones IP de nodo de trabajador individual: si tiene un número reducido de nodos de trabajador que sólo ejecutan una aplicación y no necesitan escala, o si desea añadir sólo un nodo de trabajador, liste todos los nodos de trabajador del clúster y anote las direcciones IP públicas. Si los nodos trabajadores solo están conectados a una red privada y desea conectarse a servicios de IBM Cloud utilizando el punto final de servicio en la nube privado, anote en su lugar las direcciones IP privadas. Solo se añaden estos nodos trabajadores. Si eliminas nodos de trabajo o añades nodos de trabajo al clúster, debes actualizar tu lista de permitidos en consecuencia.
ibmcloud oc worker ls --cluster <cluster_name_or_ID> ``` -
-
Añade el CIDR de la subred o las direcciones IP a la lista de permitidos de tu servicio para el tráfico saliente o a tu lista de permitidos local para el tráfico entrante.
-
Repita estos pasos para cada clúster cuyo tráfico desee permitir, tanto de entrada como de salida.
Actualización de las listas de permisos de IAM para Kubernetes Service zonas de red
De forma predeterminada, todas las direcciones IP se pueden utilizar para iniciar sesión en la IBM Cloud consola y realizar acciones para gestionar su clúster, como crear, actualizar, eliminar o ver credenciales. En la consola de IBM Cloud Identity and Access Management (IAM), puede crear una lista de elementos permitidos especificando las direcciones IP que tienen acceso; todas las demás direcciones IP quedan restringidas.
Si decide configurar una lista de permisos IAM, debe incluir una zona de red que incluya la dirección Kubernetes Service. De lo contrario, los clusters existentes no funcionarán correctamente. Esto se debe a que el plano de control de Kubernetes Service necesita poder ponerse en contacto con IAM para desplegar y gestionar los servicios de IBM necesarios para su clúster. Siga atentamente estas instrucciones antes de configurar su lista de permisos IBM.
En su allowlist, también debe configurar zonas de red en el plano de control Red Hat OpenShift on IBM Cloud para la región en la que se encuentra su clúster, de modo que Red Hat OpenShift on IBM Cloud pueda crear o acceder a componentes como los ALB de Ingress o la consola web Red Hat OpenShift, que requiere todas las direcciones IP del plano de control.
Antes de empezar, es necesario que siga estos pasos para cambiar la lista de elementos permitidos de IAM para el usuario cuyas credenciales se utilicen para los permisos de infraestructura de la región y el grupo de recursos del clúster. Si es el propietario de las credenciales, puede cambiar sus propios valores de la lista de elementos permitidos de IAM. Si no eres el titular de las credenciales, pero se te ha asignado el rol de acceso «Editor» o «Administrador» IBM Cloud en la plataforma IAM para el servicio de gestión de usuarios, puedes actualizar las redes del titular de las credenciales.
-
Identifique las credenciales de usuario que se utilizan para los permisos de la infraestructura de grupo de recursos y de la región del clúster.
- Compruebe la clave de API para una región y un grupo de recursos del clúster.
ibmcloud oc api-key info --cluster <cluster_name_or_ID> ``` Salida de ejemplo ```sh {: screen} Getting information about the API key owner for cluster <cluster_name>... OK Name Email <user_name> <name@email.com> ``` 2. Compruebe si la cuenta de la infraestructura para la región y el grupo de recursos se ha establecido manualmente de modo que utilice otra cuenta de infraestructura de IBM Cloud. ```sh {: pre} ibmcloud oc credential get --region <us-south> ``` **Salida de ejemplo si las credenciales se han establecido de modo que utilicen otra cuenta**. En este caso, las credenciales de infraestructura del usuario se utilizan para la región y el grupo de recursos que ha seleccionado como destino, incluso si las credenciales de un usuario diferente se almacenan en la clave de API que ha recuperado en el paso anterior. ```sh {: screen} OK Infrastructure credentials for user name <1234567_name@email.com> set for resource group <resource_group_name>. ``` **Salida de ejemplo si las credenciales no se han establecido de modo que utilicen otra cuenta**. En este caso, el propietario de la clave de API que ha recuperado en el paso anterior tiene las credenciales de infraestructura que se utilizan para la región y el grupo de recursos. ```sh {: screen} FAILED No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051) ``` -
Inicia sesión en la consola de IBM Cloud.
-
Cree zonas de red que incluyan las IP de Kubernetes Service para todas las regiones o sólo para las regiones en las que tiene clústeres.
-
En la cuenta en la que se encuentra el clúster, desde la barra de menús, haz clic en Gestionar > Restricciones basadas en el contexto.
-
Haga clic en Zonas de red > Crear.
-
En Nombre, introduzca un nombre descriptivo para la zona de red, como
us-south-kubernetes-service-network-zone. -
No introduzca ningún valor para las secciones Direcciones IP permitidas y VPC permitidas.
-
En la sección Referenciar un servicio, seleccione Kubernetes Service y haga clic en +.
-
Para Localizaciones, puede dejar el campo vacío para que se utilicen todas las ubicaciones, lo que se aplica a los clústeres de otras regiones, o puede especificar una única región.
-
Haz clic en « Siguiente » y revisa las opciones seleccionadas.
-
Pulse Crear.
-
Repita el procedimiento para las zonas adicionales.
-
-
Añada los nombres de las zonas de red a su lista de permisos de IAM.
-
En la barra de menús, pulse Gestionar > Acceso (IAM) y seleccione Valores.
-
En Restringir el acceso a direcciones IP, seleccione Activar e indique el nombre de la zona de red del paso anterior.
-
Haga clic en Aplicar.
-
Obtención de las direcciones IP de subred de Kubernetes Service
Siga los pasos para obtener las direcciones IP de subred correctas para añadirlas a la lista de elementos permitidos de IAM.
Obtención de las direcciones IP de subred en la consola
- En la lista de recursos de la consola de administración de IBM Cloud, haga clic en su clúster.
- Haz clic en « Nodos de trabajo ».
- Anote cada VLAN pública utilizada por los nodos trabajadores del clúster. Varios nodos trabajadores pueden utilizar la misma VLAN pública.
- En el menú de la consola IBM Cloud
, haga clic en Infraestructura > Infraestructura clásica > Gestión de IP > VLAN.
- Haga clic en cada VLAN pública para comprobar si la utilizan los nodos de trabajo de su clúster.
- 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
-
Liste las VLAN públicas que utilizan los nodos trabajadores. La salida se formatea como
publicVLAN=<vlan_id>.oc describe nodes | grep publicVLAN | sort | uniq -
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 -
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.
-
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