IBM Cloud Docs
Configuración de subredes de VPC

Configuración de subredes de VPC

Nube privada virtual

Cambie la agrupación de las direcciones IP públicas o privadas portátiles disponibles añadiendo subredes a su clúster VPC de Red Hat® OpenShift® on IBM Cloud®.

El contenido de esta página es específico de los clústeres de VPC. Para obtener información sobre los clústeres clásicos, consulte Configuración de subredes y direcciones IP para clústeres clásicos.

Visión general de la red de VPC en Red Hat OpenShift on IBM Cloud

Comprenda los conceptos básicos de la red de VPC en los clústeres de Red Hat OpenShift on IBM Cloud.

Subredes

Antes de crear un clúster VPC por primera vez, debe crear una subred VPC en cada zona en la que desee desplegar nodos de trabajador. Una subred de VPC es un rango específico de direcciones IP privadas (bloque de CIDR) y configura un grupo de nodos trabajadores y pods como si estuvieran conectados a la misma conexión física.

Cuando se crea un clúster, solo se puede especificar una subred de VPC existente para cada zona. Cada nodo trabajador que añada en un clúster se despliega con una dirección IP privada de la subred de VPC en dicha zona. Una vez suministrado el nodo trabajador, la dirección IP del nodo trabajador persiste tras una operación reboot, pero la dirección IP del nodo trabajador cambia después de las operaciones replace y update.

No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.

¿Cuántas direcciones IP necesito para mi subred VPC?

Cuando cree su subred VPC, asegúrese de crear una subred con suficientes direcciones IP para su clúster, como 256. Después, ya no puede cambiar el número de direcciones IP que tiene una subred de VPC.

Tenga en cuenta las siguientes restricciones en cuanto a las direcciones IP.

  • De forma predeterminada, 5 direcciones IP de cada subred están reservadas por VPC.
  • se requiere 1 dirección IP de una subred en cada zona en la que su clúster tenga nodos trabajadores para la puerta de enlace de los puntos finales privados virtuales(VPE).
  • Se requiere una dirección IP por cada nodo trabajador de su clúster.
  • Se requiere una dirección IP cada vez que se actualiza o se reemplaza un nodo trabajador. Estas direcciones IP son eventualmente reclamadas y disponibles para su reutilización.
  • Se utilizan 2 direcciones IP cada vez que se crea un equilibrador de carga público o privado. Si tiene un clúster multizona, estas 2 direcciones IP se distribuyen por zonas, por lo que es posible que la subred no tenga una dirección IP reservada.
  • Otros recursos de red que configure para el clúster, como por ejemplo un escalado automático de VPNaaS o LBaaS, pueden necesitar direcciones IP adicionales o tener otras limitaciones de servicio. Por ejemplo, el escalado automático de LBaaS podría escalar hasta 16 direcciones IP por equilibrador de carga.

¿Qué rangos de IP puedo utilizar para mis subredes VPC?

El rango predeterminado de direcciones IP para subredes de VPC es 10.0.0.0 – 10.255.255.255. Para ver una lista de rangos de direcciones IP por zona de VPC, consulte los prefijos de dirección predeterminados de VPC.

Si tiene que crear el clúster utilizando subredes de rango personalizado, consulte la guía de prefijos de direcciones personalizados. Sin embargo, si se usan subredes de rango personalizado para los nodos de trabajador, hay que asegurarse de que el rango de IP de las subredes de nodos de trabajador no se solapen con la subred de pods del clúster.

  • Si especificó su propia subred de pods en la opción --pod-subnet durante la creación del cluster, a sus pods se les asignarán direcciones IP de este rango.
  • Si no ha especificado una subred de pod personalizada durante la creación del clúster, el clúster utiliza la subred de pod predeterminada. En el primer clúster que cree en una VPC, la subred de pod predeterminada es 172.17.0.0/18. En el segundo clúster que cree en dicha VPC, la subred de pod predeterminada es 172.17.64.0/18. En cada clúster posterior, el rango de subred de pod es la siguiente subred /18 disponible que no se solape.

¿Cómo crear subredes para el acceso a la infraestructura clásica?

Si habilita el acceso clásico al crear la VPC, los prefijos de dirección predeterminados de acceso clásico determinan automáticamente los rangos de IP de las subredes que cree. Sin embargo, los rangos de IP predeterminados para las subredes de VPC de acceso clásico entran en conflicto con las subredes para el plano de control de Red Hat OpenShift on IBM Cloud. En su lugar, debe crear la VPC sin los prefijos de direcciones predeterminados automáticos y, a continuación, crear sus propios prefijos de direcciones y subredes dentro de esos rangos para su clúster.

¿Puedo especificar subredes para pods y servicios en mi clúster?

Si tiene previsto conectar el clúster a redes locales mediante IBM Cloud Direct Link o un servicio VPN, puede evitar conflictos de subred si especifica un CIDR de subred personalizada que proporcione las direcciones IP privadas de los pods y un CIDR de subred personalizado para proporcionar las direcciones IP privadas de los servicios.

Para especificar subredes de pods y servicios personalizadas durante la creación del clúster, utilice las opciones --pod-subnet y --service-subnet en el comando CLI ibmcloud oc cluster create.

Para ver los pods y subredes de servicio que utiliza el clúster, busque los campos Pod Subnet y Service Subnet en la salida de ibmcloud oc cluster get.

Pods

Rango predeterminado

En el primer clúster que cree en una VPC, la subred de pod predeterminada es 172.17.0.0/18. En el segundo clúster que cree en dicha VPC, la subred de pod predeterminada es 172.17.64.0/18. En cada clúster posterior, el rango de subred de pod es la siguiente subred /18 disponible que no se solape.

Requisitos de tamaño

Al especificar una subred personalizada, tenga en cuenta el tamaño del clúster que tenga previsto crear y el número de nodos de trabajador que podría añadir en el futuro. La subred debe tener un CIDR de al menos /23, que proporciona suficientes IP de pod para un máximo de cuatro nodos trabajadores en un clúster. Para clústeres más grandes, utilice /22 para tener suficientes direcciones IP de pod para ocho nodos trabajadores, /21 para tener suficientes direcciones IP de pod para 16 nodos trabajadores, etc.

Para los clústeres de VPC, puede especificar el tamaño de subred incluyéndolo en la opción --pod-subnet. Por ejemplo: --pod-subnet 0.0.0.0/X donde X es el tamaño de subred de pod necesario. A continuación, se selecciona automáticamente la subred de pod. Al asignar la subred de pod automáticamente, la asignación se iniciará desde 172.17.0.0, la subred más grande se limita a 13 y el tamaño de subred más pequeño se limita a 23.

Existe un límite global para los nodos trabajadores. No puede superar los 500 nodos de trabajador en todos los clústeres de una región.

Requisitos de rango

Las subredes de pod y servicio no se pueden solapar entre sí, y la subred de pod no se puede solapar con las subredes de VPC para los nodos de trabajador. La subred elegida tiene que pertenecer a uno de los siguientes rangos.

  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.254.255

  • 198.18.0.0 - 198.19.255.255

Servicios

Rango predeterminado
De forma predeterminada, todos los servicios que se despliegan en el clúster tienen asignada una dirección IP privada en el rango 172.21.0.0/16.
Requisitos de tamaño
Cuando se especifica una subred personalizada, la subred debe especificarse en formato CIDR con un tamaño de al menos /24, lo que permite un máximo de 255 servicios en el clúster, o con un tamaño mayor.
Requisitos de rango
Las subredes de pod y servicio no se pueden solapar entre sí. La subred elegida tiene que pertenecer a uno de los siguientes rangos.
  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.254.255

  • 198.18.0.0 - 198.19.255.255

Pasarelas públicas

Una pasarela pública permite que una subred y todos los nodos trabajadores conectados a la subred establezcan conexiones de salida a internet. Si los puntos finales de servicio tanto públicos como privados están habilitados para el clúster, debe habilitar una pasarela pública en las subredes de VPC en las que se despliegan los nodos trabajadores para acceder a los componentes de Red Hat OpenShift predeterminados sin estar conectados a la red privada de la VPC.

Cuando crea un clúster de VPC y habilita los puntos finales de servicio de nube pública y privada durante la creación del clúster, el punto final de servicio de nube pública se utiliza de forma predeterminada para acceder a componentes como la consola web de Red Hat OpenShift para el clúster. Para que los pods de consola establezcan una conexión pública segura sobre Internet a través del punto final de servicio público, debe habilitar una pasarela pública en cada subred de VPC en la que se despliegan los nodos trabajadores.

Cuando se crea un clúster de VPC y solo se habilita el punto final de servicio de nube privada durante la creación del clúster, el punto final de servicio de nube privada se utiliza de forma predeterminada para acceder a los componentes de Red Hat OpenShift, como la consola web de Red Hat OpenShift u OperatorHub. Debe estar conectado a la red privada de VPC, por ejemplo a través de una conexión VPN, para acceder a estos componentes o ejecutar mandatos kubectl en el clúster. Además, si un servicio de IBM Cloud no da soporte a puntos finales de servicio en la nube privados, los nodos trabajadores deben estar conectados a una subred que tenga una pasarela pública conectada. Los pods de dichos nodos trabajadores se pueden comunicar de forma segura con los servicios a través de la red pública a través de la pasarela pública de la subred. Tenga en cuenta que no se necesita una pasarela pública en las subredes para permitir el tráfico de red de entrada de Internet a los servicios LoadBalancer o ALB.

Dentro de una VPC, solo puede crear una pasarela pública por zona, pero dicha pasarela pública se puede conectar a varias subredes dentro de la zona. Para obtener más información sobre las pasarelas públicas, consulte la documentación sobre redes para VPC.

Puntos finales privados virtuales (VPE)

Los nodos trabajadores se pueden comunicar con el nodo maestro de Kubernetes a través del punto final privado virtual(VPE) del clúster.

Un VPE es una dirección IP virtual enlazada a una pasarela de punto final. Se crea un recurso de pasarela de VPE por clúster en la VPC. Una dirección IP de una subred en cada zona en la que el clúster tiene nodos trabajadores se utiliza automáticamente para la pasarela de VPE, y los nodos trabajadores de esta zona utilizan esta dirección IP para comunicarse con el maestro de Kubernetes. Para ver los detalles de la puerta de enlace VPE de su clúster, abra el panel Virtual private endpoint gateways for VPC y busque la puerta de enlace VPE en el formato iks-<cluster_ID>.

Tenga en cuenta que los nodos trabajadores utilizan automáticamente el VPE que se crea de forma predeterminada en la VPC. Sin embargo, si ha habilitado el punto final de servicio en la nube público para el clúster, el tráfico de trabajador a maestro se establece la mitad sobre el punto final público y la mitad sobre el VPE para la protección frente a posibles interrupciones de la red pública o privada.

No suprima ninguna dirección IP en las subredes que se utilizan para los VPE.

Segmentación de red

La segmentación de red describe el enfoque para dividir una red en varias subredes. Las aplicaciones que se ejecutan en una subred no pueden ver las aplicaciones de otra subred ni acceder a ellas. Para obtener más información sobre las opciones de segmentación de red y para subredes de VPC, consulte este tema sobre la seguridad del clúster.

Las subredes proporcionan un canal para la conectividad entre los nodos trabajadores dentro del clúster. Además, cualquier sistema que esté conectado a cualquiera de las subredes privadas en la misma VPC puede comunicarse con los nodos trabajadores. Por ejemplo, todas las subredes de una VPC se pueden comunicar a través del direccionamiento de capa 3 privado con un direccionador de VPC incorporado.

Si tiene varios clústeres que deben comunicarse entre sí, puede crear los clústeres en la misma VPC. Sin embargo, si los clústeres no necesitan comunicarse, puede lograr una mejor segmentación de la red creando los clústeres en VPC independientes. También puede crear listas de control de accesos (ACL) para las subredes de VPC para que medien en el tráfico en la red privada. Las ACL constan de reglas de entrada y de salida que definen las entradas y salidas permitidas para cada subred de VPC.

Limitaciones de las redes de VPC

Cuando cree subredes de VPC para los clústeres, tenga en cuenta las siguientes características y limitaciones.

  • El tamaño de CIDR predeterminado de cada subred de VPC es /24, que puede dar soporte a un máximo de 253 nodos trabajadores. Si tiene intención de desplegar más de 250 nodos trabajadores por zona en un clúster, tenga en cuenta la posibilidad de crear una subred de mayor tamaño.
  • Después de crear una subred de VPC, no puede cambiarse el tamaño ni su rango de IP.
  • Varios clústeres de la misma VPC pueden compartir subredes de VPC. Sin embargo, las subredes de servicio y pod personalizadas no se pueden compartir entre varios clústeres.
  • Las subredes de la VPC están vinculadas a una región multizona de un único campus y no pueden abarcar varias zonas o regiones.
  • Después de crear una subred, no puede moverla a otra zona, región o VPC.
  • Si tiene nodos de trabajador conectados a una subred existente en una zona, no puede cambiar la subred de esa zona en el clúster.
  • Los rangos 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16 están prohibidos.
  • Dentro de una VPC, solo puede crear una pasarela pública por zona, pero dicha pasarela pública se puede conectar a varias subredes dentro de la zona.
  • Los prefijos de direcciones predeterminadas de acceso clásico entran en conflicto con las subredes para el plano de control de Red Hat OpenShift on IBM Cloud. Debe crear la VPC sin los prefijos de direcciones predeterminados automáticos y, a continuación, crear sus propios prefijos de direcciones y subredes dentro de esos rangos para su clúster.

Creación de una subred de VPC y conexión de una pasarela pública

Cree una subred de VPC para su clúster y, si lo desea, conecte una pasarela pública a la subred.

Creación de una subred de VPC en la consola

Utilice la consola de IBM Cloud para crear una subred de VPC para su clúster y, si lo desea, conecte una pasarela pública a la subred.

  1. En el panel de control de la subred de VPC, pulse Crear.
  2. Especifique un nombre para la subred y seleccione el nombre de la VPC que ha creado.
  3. Seleccione la ubicación y la zona en las que desea crear la subred.
  4. Especifique el número de direcciones IP que se deben crear.
    • Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
    • Si especifica un rango de IP específico, no utilice los siguientes rangos reservados: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16 y 172.20.0.0/16.
  5. Para ejecutar componentes predeterminados de Red Hat OpenShift como la consola web u OperatorHub, y para permitir que el clúster acceda a puntos finales públicos, como un URL público de otra app o un servicio IBM Cloud que solo da soporte a puntos finales de servicio en la nube públicos, debe conectar una pasarela pública a la subred.
  6. Pulse Crear subred.
  7. Utilice la subred para crear un clúster, crear una nueva agrupación de trabajadores o añadir la subred a una agrupación de trabajadores existente.> No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.

Creación de una subred de VPC en la CLI

Utilice la CLI de IBM Cloud para crear una subred de VPC para su clúster y, si lo desea, conecte una pasarela pública a la subred.

Antes de empezar

  1. En la línea de mandatos, inicie una sesión en su cuenta de IBM Cloud y elija como destino la región y grupo de recursos de IBM Cloud donde desea crear el clúster de VPC. Para ver las regiones soportadas, consulte Creación de una VPC en otra región. El grupo de recursos del clúster puede diferir del grupo de recursos de VPC. Escriba sus credenciales de IBM Cloud cuando se le solicite. Si dispone de un ID federado, utilice la opción --sso para conectarse.
    ibmcloud login -r <region> [-g <resource_group>] [--sso]
    
  2. Create a VPC in the same region where you want to create the cluster.

Para crear una subred de VPC, siga estos pasos.

  1. Obtenga el ID de la VPC donde desea crear la subred.

    ibmcloud oc vpcs
    
  2. Cree la subred. Para obtener más información sobre las opciones de este mandato, revise la referencia de CLI.

    ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address>
    
    • Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
    • No utilice los siguientes rangos reservados: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, y 172.20.0.0/16.
  3. Compruebe si tiene una pasarela pública en las zonas en las que desea crear un clúster. Dentro de una VPC, solo puede crear una pasarela pública por zona, pero dicha pasarela pública se puede conectar a varias subredes dentro de la zona.

    ibmcloud is public-gateways
    

    Salida de ejemplo

    ID                                     Name                                       VPC                          Zone         Floating IP                  Created                     Status      Resource group
    26426426-6065-4716-a90b-ac7ed7917c63   test-pgw                                   testvpc(36c8f522-.)          us-south-1   169.xx.xxx.xxx(26466378-.)   2019-09-20T16:27:32-05:00   available   -
    2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   team3(ff537d43-.)            us-south-2   169.xx.xxx.xxx(2ba9a280-.)   2019-08-02T10:30:29-05:00   available   -
    
    • Si ya tiene una pasarela pública en cada zona, anote los ID de las pasarelas públicas.
    • Si no tiene una pasarela pública en cada zona, cree una pasarela pública. Recuerde nombrar la pasarela pública con en el formato <cluster>-<zone>-gateway. En la salida, anote el ID de la pasarela pública.
    ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
    

    Salida de ejemplo

    ID               26466378-6065-4716-a90b-ac7ed7917c63
    Name             mycluster-us-south-1-gateway
    Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
    Status           pending
    Created          2019-09-20T16:27:32-05:00
    Zone             us-south-1
    VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
    Resource group   -
    
  4. Utilizando los ID de la pasarela pública y de la subred, conecte la pasarela pública a la subred.

    ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
    

    Salida de ejemplo

    ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
    Name                mysubnet1
    IPv4 CIDR           10.240.xx.xx/24
    Address available   250
    Address total       256
    ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
    Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
    Created             2019-08-21T09:43:11-05:00
    Status              available
    Zone                us-south-1
    VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
    
  5. Utilice la subred para crear un clúster, crear una nueva agrupación de nodos trabajadores o añadir la subred a una agrupación de nodos trabajadores existente. No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.

Creación de subredes de VPC para el acceso clásico

Si habilita el acceso clásico al crear la VPC, los prefijos de dirección predeterminados de acceso clásico determinan automáticamente los rangos de IP de las subredes que cree. Sin embargo, los rangos de IP predeterminados para las subredes de VPC de acceso clásico entran en conflicto con las subredes para el plano de control de Red Hat OpenShift on IBM Cloud. En su lugar, debe crear la VPC sin los prefijos de dirección predeterminados automáticos y luego crear sus propios prefijos de dirección. A continuación, siempre que cree subredes para el clúster, cree las subredes dentro de los rangos de prefijos de dirección que ha creado.

Creación de subredes de VPC para el acceso clásico en la consola

  1. Cree una VPC de acceso clásico sin prefijos de dirección predeterminados.
    1. En el panel de control Nubes privadas virtuales, pulse Crear.
    2. Especifique detalles para el nombre, el grupo de recursos y las etiquetas.
    3. Marque el recuadro de selección para Habilitar acceso a recursos clásicos y desmarque el recuadro de selección Crear un prefijo predeterminado para cada zona.
    4. Seleccione la región para la VPC.
    5. Pulse Crear nube privada virtual.
  2. Cree prefijos de dirección en cada zona.
    1. Pulse el nombre de su VPC para ver sus detalles.
    2. Pulse el separador Prefijos de dirección y pulse Crear.
    3. Para cada zona en la que tiene previsto crear subredes, cree uno o varios prefijos de direcciones. Los prefijos de direcciones deben estar dentro de los siguientes rangos: 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255.
  3. Cree subredes que utilicen los prefijos de dirección.
    1. En el panel de control de la subred de VPC, pulse Crear.
    2. Especifique un nombre para la subred y seleccione el nombre de la VPC de acceso clásico.
    3. Seleccione la ubicación y la zona en las que desea crear la subred.
    4. Seleccione el prefijo de dirección que ha creado para esta zona.
    5. Especifique el número de direcciones IP que se deben crear. Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
    6. Para ejecutar componentes predeterminados de Red Hat OpenShift como la consola web u OperatorHub, y para permitir que el clúster acceda a puntos finales públicos, como un URL público de otra app o un servicio IBM Cloud que solo da soporte a puntos finales de servicio en la nube públicos, debe conectar una pasarela pública a la subred.
    7. Pulse Crear subred.
  4. Utilice las subredes para crear un clúster. No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.

Creación de subredes de VPC para el acceso clásico desde la CLI

  1. En la línea de mandatos, inicie una sesión en su cuenta de IBM Cloud y elija como destino la región y grupo de recursos de IBM Cloud donde desea crear el clúster de VPC. Para ver las regiones soportadas, consulte Creación de una VPC en otra región. El grupo de recursos del clúster puede diferir del grupo de recursos de VPC. Escriba sus credenciales de IBM Cloud cuando se le solicite. Si dispone de un ID federado, utilice la opción --sso para conectarse.
    ibmcloud login -r <region> [-g <resource_group>] [--sso]
    
  2. Cree una VPC de acceso clásico sin prefijos de dirección predeterminados. En la salida, copie el ID de VPC.
    ibmcloud is vpc-create <name> --classic-access --address-prefix-management manual
    
  3. Para cada zona en la que tiene previsto crear subredes, cree uno o varios prefijos de direcciones. Los prefijos de direcciones deben estar dentro de los siguientes rangos: 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.254.255.
    ibmcloud is vpc-address-prefix-create <prefix_name> <vpc_id> <zone> <prefix_range>
    
  4. Cree subredes en cada zona que utilicen los prefijos de dirección. Para obtener más información sobre las opciones de este mandato, revise la referencia de CLI. Las subredes de VPC proporcionan direcciones IP para los nodos trabajadores y los servicios del equilibrador de carga en el clúster, por lo tanto cree una subred de VPC con suficientes direcciones IP, como por ejemplo 256. Después, ya no puede cambiar el número de IP que tiene una subred de VPC.
    ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address> --ipv4-cidr-block <prefix_range>
    
  5. Para ejecutar componentes predeterminados de Red Hat OpenShift como la consola web u OperatorHub, y para permitir que el clúster acceda a puntos finales públicos, como un URL público de otra app o un servicio IBM Cloud que solo da soporte a puntos finales de servicio en la nube públicos, debe conectar una pasarela pública a la subred.
    1. Cree una pasarela pública en cada zona. Recuerde nombrar la pasarela pública con en el formato <cluster>-<zone>-gateway. En la salida, anote el ID de la pasarela pública.
      ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
      
      Salida de ejemplo
      ID               26466378-6065-4716-a90b-ac7ed7917c63
      Name             mycluster-us-south-1-gateway
      Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
      Status           pending
      Created          2019-09-20T16:27:32-05:00
      Zone             us-south-1
      VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
      Resource group   -
      
    2. Mediante los ID de la pasarela pública y la subred, conecte la pasarela pública a la subred.
      ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
      
      Salida de ejemplo
      ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
      Name                mysubnet1
      IPv4 CIDR           10.240.xx.xx/24
      Address available   250
      Address total       256
      ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
      Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
      Created             2019-08-21T09:43:11-05:00
      Status              available
      Zone                us-south-1
      VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
      
  6. Utilice las subredes para crear un clúster. No suprima las subredes que conecte al clúster durante la creación del clúster o cuando añada nodos trabajadores en una zona. Si suprime una subred de VPC que ha utilizado el clúster, cualquier equilibrador de carga que utilice direcciones IP de la subred puede tener problemas, y es posible que no pueda crear nuevos equilibradores de carga.