Abrir los puertos y direcciones IP necesarios en su lista de permitidos
Clústeres clásicos
Esta información de la lista de permisos es específica de los clusters clásicos. Para los clústeres de VPC, consulte Cómo abrir los puertos y las direcciones IP necesarios en su lista de permitidos para clústeres de VPC.
Revise estas situaciones en las que podría necesitar abrir puertos específicos y direcciones IP en sus listas de permisos para sus clusters Red Hat® OpenShift® on IBM Cloud®.
- Listas de permisos corporativas: Si las políticas de la red corporativa impiden el acceso desde su sistema local a los endpoints públicos a través de proxies o allowlists, debe permitir el acceso para ejecutar los comandos
ibmcloud
,ibmcloud oc
,ibmcloud cr
,oc
, ycalicoctl
desde su sistema local. - Gateway appliance allowlists: Si tiene listas de permisos configuradas en la red pública o privada en su cuenta de infraestructura de IBM Cloud, como una VRA, debe abrir rangos de IP, puertos y protocolos para permitir que los nodos trabajadores se comuniquen con el 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 utiliza las políticas de red de Calico para que actúen como una lista de permisos que restrinja la salida de todos los nodos de los trabajadores, debe permitir que estos accedan a los recursos necesarios para el funcionamiento del clúster.
- Otros servicios o listas de permisos de red: Para permitir que su clúster acceda a servicios que se ejecutan dentro o fuera de IBM Cloud o en redes locales y que están protegidos por una allowlist, debe añadir las direcciones IP de sus nodos trabajadores en dicha allowlist.
Abrir puertos en una lista de permisos corporativa
Si las políticas de la red corporativa impiden el acceso desde su sistema local a los endpoints públicos a través de proxies o allowlists, debe permitir el acceso para ejecutar los comandos ibmcloud
, ibmcloud oc
, y ibmcloud cr
,
los comandos oc
y calicoctl
desde su sistema local.
Ejecución de los comandos ibmcloud
, ibmcloud oc
, y ibmcloud cr
desde detrás de una allowlist
Si las políticas de la red corporativa impiden el acceso desde su sistema local a los puntos finales públicos a través de proxies o allowlists, para ejecutar los comandos ibmcloud
, ibmcloud oc
y ibmcloud cr
,
debe permitir el acceso TCP para IBM Cloud, Red Hat OpenShift on IBM Cloud y IBM Cloud Container Registry.
-
Permita el acceso a
cloud.ibm.com
en el puerto 443 en su lista de permitidos. -
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/
-
Permita el acceso a
containers.cloud.ibm.com
en el puerto 443 en su lista de permitidos. -
Compruebe la conexión. Si el acceso está configurado correctamente, las zonas se muestran en la salida.
curl https://containers.cloud.ibm.com/v1/zones
Salida 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."}]
-
Permita el acceso a las regiones de IBM Cloud Container Registry que planea utilizar en el puerto 443 en su lista de permisos. El registro global almacena imágenes públicas proporcionadas por IBM y los registros regionales almacenan sus propias imágenes privadas o públicas.
-
Verifique su conexión listando los espacios de nombres del registro de su contenedor.
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 su sistema local a los puntos finales públicos a través de proxies o allowlists, para ejecutar comandos oc
, debe 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 está basada en IP, puedes ver qué direcciones IP se abren cuando permites el acceso a las URLs de los puntos finales de servicio revisando esta tabla.
-
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:
curl --insecure https://c3.<region>.containers.cloud.ibm.com:31142/version
Salida de ejemplo
{ "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 para que los usuarios puedan acceder al nodo maestro a través de una conexión VPN o IBM Cloud® Direct Link.
curl --insecure <private_service_endpoint_URL>/version
Mandato de ejemplo:
curl --insecure https://c3-private.<region>.containers.cloud.ibm.com:31142/version
Salida de ejemplo
{ "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 su sistema local a los puntos finales públicos a través de proxies o allowlists, para ejecutar comandos calicoctl
, debe permitir el acceso TCP para los comandos Calico.
Antes de empezar, permita el acceso para ejecutar los comandos ibmcloud
y oc
.
-
Recupere la dirección IP del maestro URL que utilizó para permitir los comandos
oc
. -
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.
Apertura de puertos en las listas de permisos de los dispositivos de puerta de enlace
Si tiene listas de permisos configuradas en la red pública o en la red privada en su cuenta de infraestructura IBM Cloud, como Virtual Router Appliance (Vyatta), debe abrir rangos de IP, puertos y protocolos para permitir que los nodos trabajadores se comuniquen con el maestro, con los recursos de infraestructura y con otros servicios de IBM Cloud.
Abrir los puertos necesarios en una lista pública
Si tiene una allowlist en la red pública en su cuenta de infraestructura IBM Cloud, como Virtual Router Appliance (Vyatta), debe abrir rangos de IP, puertos y protocolos en su allowlist para permitir que los nodos trabajadores se comuniquen con el maestro, con los recursos de infraestructura y con otros servicios de IBM Cloud.
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 ver pull requests en el repositorio para 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.
Región | Dirección IP pública |
---|---|
AP Norte (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 , mil01 , 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.122.141.69 , 159.122.150.2 , 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 ,
169.51.197.18 , 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
Permita el tráfico de red saliente desde sus nodos trabajadores a 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). Su allowlist debe ser Layer 7 para permitir el nombre de dominio IAM. IAM no tiene direcciones IP específicas que se pueda permitir. Si su lista de permisos no admite la capa 7, puede 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.
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 utiliza Ingress o rutas para exponer aplicaciones en su clúster, permita el tráfico de red entrante desde las direcciones IP de origen de Akamai en el puerto 80 a las direcciones IP de sus servicios de router para que el plano de control de Red Hat OpenShift pueda comprobar el estado de sus routers.
Abrir los puertos necesarios en una allowlist privada
Si tiene una allowlist en la red privada de su cuenta de infraestructura IBM Cloud, como Virtual Router Appliance (Vyatta), debe abrir rangos de IP, puertos y protocolos en su allowlist para permitir que los nodos trabajadores se comuniquen con el 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/14
y161.26.0.0/16
, los rangos de IP para las zonasdal10
ywdc04
. 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 ver pull requests en el repositorio para 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.
Región | Dirección IP privada |
---|---|
AP Norte (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 , mil01 , 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 puertos siguientes deben estar abiertos en 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 logs
yoc 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
Habilite la comunicación de trabajador a trabajador permitiendo todo el tráfico TCP, UDP, VRRP e IPEncap entre nodos de trabajador en las interfaces privadas y permita también 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 de pod a pod 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.
El 23 de junio de 2022, solo han cambiado las regiones br-sao
y ca-tor
. Las regiones restantes cambiaron el 5 de julio de 2022. Para obtener más información, consulte Container Registry direcciones IP privadas cambiadas el 5 de julio de 2022.
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 después 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, configure reglas allowlist para sus 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 permisos de puerta de enlace, puede optar por utilizar las políticas de red de Calico para que actúen como una lista de permisos de clúster en la red pública o privada. Para obtener más información, consulte los temas siguientes.
Permitir el tráfico de su clúster en las listas permitidas de otros servicios o en las listas permitidas locales
Si desea acceder a servicios que se ejecutan dentro o fuera de IBM Cloud o en las instalaciones y que están protegidos por una lista de permisos, puede añadir las direcciones IP de sus nodos de trabajo en esa lista de permisos para permitir el tráfico de red saliente a su clúster. Por ejemplo, es posible que desee leer datos de una base de datos IBM Cloud protegida por una lista de permisos, o especificar las subredes de sus nodos de trabajo en una lista de permisos local para permitir el tráfico de red desde su clúster.
-
Obtenga las subredes de nodos trabajadores o las direcciones IP de los nodos trabajadores.
-
Subredes de nodos de trabajo: Si prevé cambiar con frecuencia el número de nodos trabajadores de su clúster, por ejemplo si activa el autoescalador de clústeres, es posible que no desee actualizar su lista de permisos para cada nuevo nodo trabajador. 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.178
y169.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.32 kube-dal10-crb2f60e9735254ac8b20b9c1e38b649a5-w34 169.xx.178.102 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal10 1.32 kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w32 169.xx.210.101 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal12 1.32 kube-dal12-crb2f60e9735254ac8b20b9c1e38b649a5-w33 169.xx.210.102 10.xxx.xx.xxx b3c.4x16.encrypted normal Ready dal12 1.32
-
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
2
a lan
potencia, igual al número de IP. Por ejemplo, si el número de IP es16
, se eleva2
a la4
potencia (n
), lo que es igual a16
. A continuación, obtenga el CIDR de la subred restando el valor den
de32
bits. Por ejemplo, sin
es 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/28
169.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 elimina los nodos trabajadores o añade nodos trabajadores al clúster, debe actualizar su lista de permisos en consecuencia.
ibmcloud oc worker ls --cluster <cluster_name_or_ID>
-
-
Añada el CIDR de subred o las direcciones IP a la lista de permitidos de su servicio para el tráfico saliente o a su 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, se pueden utilizar todas las direcciones IP para iniciar sesión en la consola de IBM Cloud y realizar acciones para gestionar el clúster, como crear, actualizar, suprimir o visualizar 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.
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 es el propietario de las credenciales, pero tiene asignada la función de acceso a la plataforma Editor o Administrador IBM Cloud IAM para el servicio Gestión de usuarios, puede actualizar las redes para el propietario 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
Getting information about the API key owner for cluster <cluster_name>... OK Name Email <user_name> <name@email.com>
-
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.
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.
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.
FAILED No credentials set for resource group <resource_group_name>.: The user credentials could not be found. (E0051)
-
-
Acceda a la consola 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.
-
Haga clic en Siguiente y revise las selecciones.
-
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, haga clic en Gestionar > Acceso (IAM) y seleccione Configuración.
-
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.
- Haga 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