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 es172.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 es172.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
dondeX
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á desde172.17.0.0
, la subred más grande se limita a13
y el tamaño de subred más pequeño se limita a23
. -
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
y172.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.
- En el panel de control de la subred de VPC, pulse Crear.
- Especifique un nombre para la subred y seleccione el nombre de la VPC que ha creado.
- Seleccione la ubicación y la zona en las que desea crear la subred.
- 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
y172.20.0.0/16
.
- 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.
- Pulse Crear subred.
- 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
- 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]
- Create a VPC in the same region where you want to create the cluster.
Para crear una subred de VPC, siga estos pasos.
-
Obtenga el ID de la VPC donde desea crear la subred.
ibmcloud oc vpcs
-
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
, y172.20.0.0/16
.
-
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 -
-
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)
-
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
- Cree una VPC de acceso clásico sin prefijos de dirección predeterminados.
- En el panel de control Nubes privadas virtuales, pulse Crear.
- Especifique detalles para el nombre, el grupo de recursos y las etiquetas.
- 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.
- Seleccione la región para la VPC.
- Pulse Crear nube privada virtual.
- Cree prefijos de dirección en cada zona.
- Pulse el nombre de su VPC para ver sus detalles.
- Pulse el separador Prefijos de dirección y pulse Crear.
- 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
.
- Cree subredes que utilicen los prefijos de dirección.
- En el panel de control de la subred de VPC, pulse Crear.
- Especifique un nombre para la subred y seleccione el nombre de la VPC de acceso clásico.
- Seleccione la ubicación y la zona en las que desea crear la subred.
- Seleccione el prefijo de dirección que ha creado para esta zona.
- 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.
- 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.
- Pulse Crear subred.
- 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
- 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]
- 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
- 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>
- 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>
- 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.
- 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.
Salida de ejemploibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
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 -
- Mediante los ID de la pasarela pública y la subred, conecte la pasarela pública a la subred.
Salida de ejemploibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
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)
- Cree una pasarela pública en cada zona. Recuerde nombrar la pasarela pública con en el formato
- 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.