En esta página de descripción general se explica el modelo operativo de las direcciones IP en un universo aislado de Google Distributed Cloud (GDC). Las direcciones IP se dividen en subredes para proporcionar segmentos gestionables que puedes asignar a tus servicios. Puedes definir subredes con intervalos de direcciones IP específicos o configurarlas para que se asignen dinámicamente.
Esta página está dirigida a los administradores de redes del grupo de administradores de la plataforma y a los desarrolladores de aplicaciones del grupo de operadores de aplicaciones, que son los responsables de gestionar el tráfico de red de sus servicios en un universo de GDC. Para obtener más información, consulta Audiencias de la documentación aislada de GDC.
Redes en GDC
En una organización de GDC, hay dos tipos de redes distintos para los que puedes asignar direcciones IP:
- Nube privada virtual (VPC): una red a la que se le asignan direcciones IP internas a las que solo pueden acceder las cargas de trabajo de tu organización.
- Segmento de red externa: red a la que se han asignado direcciones IP externas a las que pueden acceder las redes externas conectadas a tu organización.
Puedes asignar subredes a cada tipo de red para conseguir objetivos específicos. Una subred es una subdivisión lógica de una red de direcciones IP, definida por intervalos de enrutamiento entre dominios sin clases (CIDR). Los intervalos CIDR le permiten representar direcciones IP y sus redes correspondientes para que las use un servicio. Cada red de estos tipos de redes tiene un árbol de subredes independiente.
Se puede acceder a las subredes de una VPC desde la red de GDC, pero no se puede acceder a ellas desde fuera de GDC. Las subredes de VPC están disponibles para asignar direcciones IP internas en tu organización. Las subredes de segmentos de red se exponen a redes externas conectadas a una organización y te permiten proporcionar direcciones IP externas disponibles para redes ajenas a tu organización.
Red VPC
Una red de VPC usa direcciones IP internas a las que solo se puede acceder dentro de tu organización y a las que no pueden acceder las redes ajenas a tu organización.
Hay dos redes de VPC disponibles en tu universo de GDC:
- VPC predeterminada: una VPC a la que se asignan direcciones IP para cargas de trabajo internas, como contenedores y máquinas virtuales (VM), en varias zonas.
- Infra VPC: una VPC gestionada por el sistema que aloja servicios aislados de GDC de terceros, como Vertex AI, las APIs de observabilidad y la consola de GDC. Solo defines direcciones IP en esta VPC cuando planificas la arquitectura de direcciones IP de tu organización.
Las direcciones IP de la VPC predeterminada y la VPC de infraestructura no pueden solaparse entre sí en la misma organización. Para obtener más información, consulta Uso y limitaciones de IPv4.
Crea una subred en una red de VPC para asignar direcciones IP adicionales a las cargas de trabajo internas.
Segmento de red externo
A un segmento de red externo se le asignan direcciones IP externas a las que pueden acceder las redes externas conectadas a tu organización. Los segmentos de red de GDC solo tienen asignadas direcciones IP externas.
GDC proporciona los siguientes segmentos de red aislados lógicamente:
- Segmento de red de administrador: una red a la que se asignan direcciones IP externas para servicios administrativos durante la creación de la organización, como la consola de GDC y las APIs de gestión. Solo se definen direcciones IP en este segmento de red cuando se planifica la arquitectura de direcciones IP de la organización.
- Segmento de red de datos: una red a la que se asignan direcciones IP externas para servicios como la traducción de direcciones de red (NAT) de salida y los balanceadores de carga externos.
Puedes usar interconexiones distintas para conectar segmentos de red a otras redes externas. Las direcciones IP de los segmentos de red no pueden solaparse entre sí. Para obtener más información, consulta Uso y limitaciones de IPv4.
Crea una subred en un segmento de red para asignar direcciones IP externas adicionales a los servicios que deban conectarse a redes fuera de tu organización de GDC.
Jerarquía de subredes
Las subredes se clasifican por su tipo:
- Raíz: subredes de nivel superior de las que se pueden derivar otras subredes. Se crea una subred raíz global en cada red durante el aprovisionamiento de tu organización.
- Rama: subredes derivadas de una raíz o de otra subred de rama que se usan para subdividir aún más el espacio de direcciones IP.
- Hoja: la subdivisión más pequeña, que se suele usar para asignar direcciones IP a un servicio o recurso específico.

En este diagrama se muestra cómo se conectan entre sí los diferentes tipos de subredes:
- Una subred raíz de
10.0.0.0/16que actúa como bloque de nivel superior para las principales asignaciones de direcciones IP. - De la subred raíz, se derivan dos subredes de ramificación con los valores
10.0.1.0/24y10.0.2.0/24. Estas subredes de ramificación representan subdivisiones del espacio de direcciones de la raíz, que se utilizan para fines más específicos. - Las subredes de las ramas se subdividen en subredes de hojas con valores como
10.0.1.10/32,10.0.1.11/32y10.0.2.12/24. Estas subredes de hoja suelen ser las subdivisiones más pequeñas y, a menudo, asignan direcciones IP únicas a servicios o recursos específicos.
Esta estructura jerárquica de subredes te permite delegar y organizar tu red de forma eficiente en las cargas de trabajo y los servicios que dependen de las direcciones IP de tu red.
Subredes globales y de zona
En GDC, puedes aprovisionar subredes en dos ámbitos diferentes: zonales y globales. Las subredes zonales y globales se definen y operan en servidores de API distintos, y ofrecen diferentes funciones.
Una vez que se haya aprovisionado tu organización, cada red tendrá una subred raíz global
que se alojará en el servidor de la API global de tu organización. Para aprovisionar direcciones IP de la subred raíz global, debes crear un recurso Subnet
global en el servidor de la API global que aprovisione un bloque CIDR en una zona o en varias zonas. En la subred global, define el campo propagationStrategy
para indicar cómo quieres asignar tu bloque CIDR en las zonas. Este intervalo de direcciones IP se asigna a una zona como subred raíz zonal.
Una vez que una zona tiene su propia subred raíz zonal, puedes crear Subnet
recursos zonales en el servidor de la API de gestión de la zona para dividir aún más el intervalo de direcciones IP de la subred en subredes de ramificación adicionales dentro de la zona o en subredes hoja que estén disponibles para cargas de trabajo y servicios individuales dentro de la zona.
Subredes globales
Debes crear una subred global para asignar direcciones IP de la subred raíz alojada en el servidor de la API global a una o varias zonas de tu universo de GDC.
Las subredes globales se crean en el servidor de la API global mediante el grupo de APIs ipam.global.gdc.goog/v1 e incluyen campos opcionales como zone y propagationStrategy para definir su interacción con zonas específicas.
Las subredes globales alojan un bloque CIDR como un intervalo de subred de rama que utilizan las zonas de un universo de GDC. Para obtener más información sobre dónde crear tus subredes globales, consulta Redes en GDC.
Subredes zonales
Una subred zonal está vinculada a una zona operativa específica, que a menudo incluye configuraciones de red directas. Las subredes zonales operan estrictamente en una sola zona y se proporcionan principalmente para cargas de trabajo de máquinas virtuales y contenedores en esa zona. Una subred zonal asigna direcciones IP que ya se han aprovisionado para que las use una subred global.
Para que la comunicación entre VPCs de diferentes zonas funcione correctamente, se deben usar subredes que no se solapen en cada zona.
Las subredes zonales se crean en el servidor de la API de gestión mediante el grupo de APIs ipam.gdc.goog/v1 e incluyen un campo networkSpec opcional en su especificación, lo que te permite definir elementos de red específicos de la zona, como las pasarelas y los IDs de VLAN.
Etiquetado de subredes
Hay cuatro tipos de etiquetas:
ipam.gdc.goog/vpcyipam.gdc.goog/network-segmentse usan para identificar la red a la que pertenece esta subred.ipam.gdc.goog/usagerefleja el propósito para el que se usará esta subred.ipam.gdc.goog/subnet-groupidentifica el grupo de subredes al que pertenece esta subred. La función de grupos de subredes se explicará en la sección Grupos de subredes.
En la siguiente tabla se muestra la asignación entre las redes y las etiquetas de red:
| Red | Etiqueta |
|---|---|
| VPC predeterminada | ipam.gdc.goog/vpc: default-vpc |
| VPC de infraestructura | ipam.gdc.goog/vpc: infra-vpc |
| Segmento de red de administrador | ipam.gdc.goog/network-segment: admin |
| Segmento de red de datos | ipam.gdc.goog/network-segment: data |
Los intervalos CIDR de las cuatro redes se definieron en tu organización como parte del proceso de arranque. Las cuatro subredes globales correspondientes se encuentran en el servidor de API global.
Esas subredes globales son el intervalo CIDR de nivel raíz de cada red en todas las zonas de una organización. Todas las subredes globales de nivel raíz tienen otra etiqueta ipam.gdc.goog/usage: network-root-range.
En cada zona, una subred raíz de red zonal está disponible inicialmente en el servidor de API global que procede del aprovisionamiento de la organización. Puedes crear subredes raíz adicionales para ampliar tu espacio de direcciones IP. Cada subred raíz aloja un intervalo CIDR de una red de la zona específica y actúa lógicamente como subred raíz de ámbito zonal con la etiqueta ipam.gdc.goog/usage: zone-network-root-range.
Esta subred raíz debe crearse inicialmente en el servidor de la API global y se propaga automáticamente a una zona especificada. Para obtener más información sobre los ámbitos de subred, consulta Subredes globales y zonales.
Debes usar las etiquetas definidas al crear un recurso personalizado Subnet para aplicarlo a la red de GDC adecuada.
En el siguiente diagrama se muestran las redes globales y zonales de un universo de GDC:

En este diagrama, hay dos organizaciones que abarcan un universo multizona. Cada organización define las redes de VPC y los segmentos de red externos. En este ejemplo, se usan direcciones IP de anycast para enrutar el tráfico entre los segmentos de red externos zonales, de modo que la zona más cercana o con mejor rendimiento atienda la solicitud de red. Para obtener más información sobre las direcciones IP de Anycast, consulta el artículo Direcciones IP en GDC.
Grupos de subredes
Un grupo de subredes es un conjunto de subredes con la misma etiqueta de grupo de subredes (por ejemplo, *ipam.gdc.goog/subnet-group: subnetgroup1). Organizar las subredes en un grupo ofrece las siguientes ventajas:
- Un grupo de subredes simplifica el aumento de los recursos de IP que pertenecen a la misma entidad o que se usan con el mismo fin. Una subred no se puede ampliar por sí sola, pero un grupo de subredes sí se puede ampliar añadiéndole una nueva subred. Los usuarios pueden hacer referencia a un grupo de subredes como su recurso de IP y aprovechar su comodidad de escalado.
- Al crear una subred secundaria, los usuarios pueden hacer referencia a un grupo de subredes como elemento principal en lugar de a una sola subred. Si se usa un grupo de subredes de esta forma, los usuarios no tienen que buscar por sí mismos una subred principal que tenga espacio de IP disponible. En su lugar, IPAM buscará automáticamente una subred en el grupo de subredes que tenga suficiente espacio de IP disponible como subred principal.
- Cuando se agoten los recursos de IP para un solo propósito o entidad, con el grupo de subredes como elemento superior, la información de error de la subred secundaria será más sencilla y se reducirá el esfuerzo necesario para comprobar todas las subredes una por una.
Todas las funciones de los grupos de subredes se aplican tanto a las subredes globales como a las zonales.
Crear y ampliar un grupo de subredes
No hay ninguna API ni ningún objeto para un grupo de subredes. En su lugar, un grupo de subredes se identifica mediante una etiqueta de grupo de subredes. Para crear un grupo de subredes o añadir subredes a uno, añade una etiqueta de grupo de subredes a una subred que ya tengas o crea una subred con una etiqueta de grupo de subredes.
Si el grupo de subredes aún no existe, se creará uno. Si ya hay otras subredes con la misma etiqueta de grupo de subredes en el mismo espacio de nombres, la nueva subred se añadirá al grupo de subredes.
En el siguiente ejemplo se muestra la definición de una subred que está asociada a un grupo de subredes llamado default-vpc-us-east67-b-group.
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
...
labels:
ipam.gdc.goog/subnet-group: default-vpc-us-east67-b-group
ipam.gdc.goog/usage: zone-network-root-range
ipam.gdc.goog/vpc: default-vpc
name: default-vpc-us-east67-b-root-cidr
namespace: platform
...
spec:
ipv4Request:
cidr: 10.99.0.0/16
parentReference:
name: default-vpc-root-cidr
namespace: platform
type: SingleSubnet
type: Branch
Reglas para crear y ampliar grupos de subredes
- Los grupos de subredes se definen por ámbito de espacio de nombres. Las subredes que tengan la misma etiqueta de grupo de subredes, pero que estén en dos espacios de nombres diferentes, se considerarán como si formaran parte de dos grupos de subredes distintos.
- Una subred no puede ser descendiente de otra subred del mismo grupo.
- Las subredes del mismo grupo deben pertenecer a la misma VPC o segmento de red.
- Una subred solo se puede asociar a un grupo de subredes.
Usar un grupo de subredes como elemento principal
Al crear una subred secundaria, el usuario puede hacer referencia a un grupo de subredes como elemento principal en lugar de usar una sola subred. Para hacer referencia a un grupo de subredes como elemento superior, debes hacer lo siguiente:
- Define explícitamente
spec.parentReference.typecomoSubnetGroup. Si se deja vacío, el valor predeterminado esSingleSubnet. - Si el grupo de subredes principal está en un espacio de nombres diferente al de la subred secundaria, se debe especificar
spec.parentReference.namespaceen el espacio de nombres del grupo de subredes principal.
Después de crear una subred secundaria a partir de un grupo de subredes, IPAM asignará un CIDR del grupo de subredes en función de la solicitud de la subred secundaria y de la disponibilidad de las subredes del grupo de subredes principal. Si se encuentra una subred superior adecuada, la subred secundaria obtendrá su CIDR de ella y la referencia de la subred superior se actualizará en el estado de la subred secundaria.
En el siguiente ejemplo, la subred solicita un CIDR a default-vpc-zone1-group y se le asigna un platform/default-vpc-zone1-root-cidr superior en el estado.
apiVersion: ipam.gdc.goog/v1
kind: Subnet
metadata:
...
labels:
ipam.gdc.goog/vpc: default-vpc
name: default-vpc-default-node-subnet
namespace: platform
...
spec:
ipv4Request:
prefixLength: 23
networkSpec:
enableGateway: true
enableVLANID: false
parentReference:
name: default-vpc-zone1-group
namespace: platform
type: SubnetGroup
type: Branch
status:
allocatedParent:
name: default-vpc-zone1-root-cidr
namespace: platform
type: SingleSubnet
...
Reglas para hacer referencia a un grupo de subredes como elemento superior
- Cuando se hace referencia a un grupo de subredes como elemento superior, el creador de la subred secundaria debe tener permiso de uso en todas las subredes del grupo de subredes.
- La subred secundaria debe estar en la misma VPC o segmento de red que el grupo de subredes.
Configuración estática y dinámica de CIDR
Al definir subredes, puedes usar una configuración estática o dinámica para asignar los bloques CIDR.
La configuración estática de CIDR te permite especificar explícitamente el bloque CIDR exacto de tu subred. Asigna tu bloque CIDR de forma estática cuando necesites un control preciso sobre tu espacio de direcciones IP. Usa el campo spec.ipv4Request.cidr del recurso personalizado Subnet para especificar el intervalo de direcciones IP exacto y predefinido.
La configuración dinámica de CIDR ofrece mayor flexibilidad, ya que permite que el sistema asigne automáticamente un bloque CIDR a tu subred. En lugar de proporcionar un CIDR completo, especifica la longitud del prefijo necesaria en el campo spec.ipv4Request.prefixLength. Asigna tu bloque CIDR de forma dinámica si prefieres que el sistema delegue automáticamente las direcciones IP en tus subredes, lo que simplifica la planificación de la red y reduce el riesgo de que se produzcan conflictos de direcciones IP. El sistema selecciona un bloque CIDR disponible del tamaño especificado de la red principal.
Para obtener más información, consulta la API SubnetRequest.
Direcciones IP en GDC
Los recursos, como las VMs y los balanceadores de carga, tienen direcciones IP en GDC. Estas direcciones IP permiten que los recursos de GDC se comuniquen con otros recursos de una organización o con redes externas conectadas a tu organización. Los siguientes tipos de direcciones IP están disponibles en un universo de GDC:
- Dirección IP externa
Las direcciones IP externas se anuncian a las redes externas conectadas a una organización. Los recursos con direcciones IP externas, como los balanceadores de carga y la NAT, pueden comunicarse con redes externas. Con GDC, puedes usar direcciones IP privadas o públicas como direcciones externas. Proporciona direcciones IPv4 externas para los recursos de las siguientes formas:
- Utilizar tus propias direcciones IP externas (BYOIP): proporcionas estas direcciones IP externas para tu organización. Las direcciones IP externas de BYOIP pueden superponerse con las de otras organizaciones siempre que no se conecten a la misma red externa.
- Direcciones IP externas proporcionadas por el IO: las organizaciones pueden usar las direcciones IP externas proporcionadas por el grupo de operadores de infraestructura al conectarse a una red externa. El grupo de operadores de infraestructura es el proveedor de la conectividad a esa red.
- Dirección IP interna
No se puede acceder a las direcciones IP internas desde fuera de GDC directamente y no se pueden enrutar públicamente. Las direcciones IP internas son locales de una red de VPC, una red de VPC conectada mediante el emparejamiento entre redes de VPC o una red local conectada a una red de VPC mediante Cloud VPN. Los recursos con direcciones IP internas se comunican con otros recursos como si estuvieran en la misma red privada.
- Dirección IP Anycast
Las direcciones IP de Anycast son un tipo especial de dirección externa que siempre se limita a todo el universo de GDC. GDC utiliza direcciones IP de anycast junto con el protocolo de pasarela fronteriza (BGP) para enrutar el tráfico a la zona más cercana o con mejor rendimiento. Cada servicio global de capa 4 que se ejecute en dos o más zonas recibe una dirección IP anycast de la subred anycast, que es una subred externa. Cada zona anuncia la misma dirección IP de Anycast, pero tu red elige la mejor en función de sus reglas de enrutamiento. Si una zona falla, retira su dirección IP y tu red redirige automáticamente el tráfico a otra zona. Este enrutamiento automático proporciona una conectividad fluida incluso durante las interrupciones.
- Dirección IP privada
Las direcciones IP privadas son direcciones que no se pueden enrutar en Internet. Para ver una lista de intervalos IPv4 privados, consulta las entradas de intervalos de direcciones IP privadas en la tabla Intervalos IPv4 válidos.
- Dirección IP pública
Las direcciones IP públicas son direcciones enrutables en Internet. En GDC, las direcciones IP externas pueden ser públicas o privadas. También puedes usar direcciones IPv4 públicas como direcciones internas cuando configures el intervalo de direcciones IPv4 principal de una subred de tu red de VPC. Estas direcciones se denominan direcciones IP públicas utilizadas de forma privada.
Uso y limitaciones de IPv4
Cada red de tu universo de GDC tiene algunas limitaciones de uso del intervalo de direcciones IPv4 que debes tener en cuenta al asignar direcciones IP. Los intervalos de direcciones IPv6 no se admiten en la VPC predeterminada ni en el segmento de red de datos. Ponte en contacto con tu grupo de operadores de infraestructura para conocer las posibilidades de rango de IPv6 en otras redes.
Limitaciones de todas las subredes IPv4
Estas limitaciones se aplican a las subredes de redes de VPC y a las subredes de segmentos de red externos.
- Todas las subredes deben ser un bloque CIDR válido único.
- Una vez que hayas creado una subred, no podrás ampliarla, sustituirla ni reducirla.
- GDC no aplica ningún límite al tamaño de un CIDR. Sin embargo, en la mayoría de los intervalos de direcciones IP superiores a
/8, las validaciones adicionales impiden que crees una subred de este tamaño. Por ejemplo, una subred no puede solaparse con una subred prohibida. Para minimizar las probabilidades de elegir una subred no válida, te recomendamos que limites el tamaño máximo de la subred a/8. No puedes crear subredes que se solapen con ninguna subred prohibida, ninguna otra subred de la misma red VPC, ninguna subred de un segmento de red externa conectada ni ninguna subred de una red emparejada. Debes colaborar con tu grupo de operadores de infraestructura para asegurarte de que no creas subredes superpuestas en estos casos.
GDC crea las rutas correspondientes para las subredes. Las subredes de la red de VPC tienen rutas creadas en la pila de red virtual de tu organización, y las subredes del segmento de red externa tienen rutas creadas en la tabla de enrutamiento de tu red emparejada externa.
Verifica que las subredes no entren en conflicto con el direccionamiento IP local si has conectado tu red VPC a otra red mediante una VPN gestionada o una interconexión compartida o dedicada.
Las subredes no deben coincidir, ser más estrechas ni más amplias que un intervalo prohibido. Por ejemplo,
169.0.0.0/8no es una subred válida porque se superpone con el intervalo local de enlace169.254.0.0/16(RFC 3927), que está restringido.Las subredes no deben abarcar un intervalo RFC, tal como se describe en Intervalos IPv4 válidos, ni un intervalo de direcciones IP públicas usadas de forma privada. Por ejemplo,
172.0.0.0/10no es una subred válida porque incluye tanto el intervalo de direcciones IP privadas172.16.0.0/12como direcciones IP públicas.Las subredes no deben abarcar varios intervalos RFC. Por ejemplo,
192.0.0.0/8no es una subred válida porque incluye tanto192.168.0.0/16(RFC 1918) como192.0.0.0/24(RFC 6890). Sin embargo, puedes crear dos subredes, una con192.168.0.0/16y otra con192.0.0.0/24.
Intervalos de IPv4 válidos
En la siguiente tabla se describen los intervalos válidos.
| Intervalo | Descripción |
|---|---|
| Intervalos de direcciones IPv4 privadas | |
10.0.0.0/8172.16.0.0/12192.168.0.0/16
|
Direcciones IP privadas RFC 1918 Para obtener información sobre cómo usar |
100.64.0.0/10 |
Espacio de direcciones compartidas RFC 6598 |
192.0.0.0/24 |
Asignaciones de protocolo IETF RFC 6890 |
192.0.2.0/24 (TEST-NET-1)198.51.100.0/24 (TEST-NET-2)203.0.113.0/24 (TEST-NET-3) |
Documentación RFC 5737 |
192.88.99.0/24 |
Relé de IPv6 a IPv4 (obsoleto) RFC 7526 |
198.18.0.0/15 |
Pruebas de rendimiento RFC 2544 |
240.0.0.0/4 |
Reservada para uso futuro (clase E), tal como se indica en RFC 5735 y RFC 1112. Algunos sistemas operativos no admiten el uso de este intervalo, por lo que debes verificar que tu SO lo admita antes de crear subredes que lo utilicen. |
| Intervalos de direcciones IP públicas usadas de forma privada | |
| Direcciones IPv4 públicas usadas de forma privada |
Direcciones IPv4 públicas de uso privado:
La prueba de concepto con air gap de GDC no presupone la conectividad a Internet. Como resultado, GDC con aislamiento físico anuncia cualquier intervalo de direcciones IP públicas como si fuera privado para tu organización. Si las direcciones de tu IP (BYOIP) que has importado son intervalos de direcciones IP públicas, debes verificar que no causen problemas de red en ninguna red externa. Las direcciones BYOIP no se pueden solapar con otras subredes de tu organización. |
Subredes IPv4 prohibidas
Los intervalos de subredes prohibidos incluyen los intervalos RFC reservados habitualmente y cualquier subred reservada a nivel global en tu universo de GDC específico, tal como se describe en la siguiente tabla. Estos intervalos no se pueden usar para subredes.
| Intervalo | Descripción |
|---|---|
| Intervalo de infraestructura de GDC |
Un CIDR reservado a nivel mundial que usa el sistema de GDC. Si no se especifica este intervalo en el campo zone-infra-cidr del cuestionario de recogida de información del cliente (CIQ), GDC usa 172.16.0.0/12 como intervalo de infraestructura de GDC de forma predeterminada. |
| Intervalos específicos del universo | Intervalos adicionales reservados por el grupo de operadores de infraestructura. |
0.0.0.0/8
|
Red actual (local) RFC 1122 |
127.0.0.0/8
|
Host local RFC 1122 |
169.254.0.0/16
|
Enlace local RFC 3927 |
224.0.0.0/4
|
Multicast (clase D) RFC 5771 |
255.255.255.255/32
|
Dirección de destino de difusión limitada RFC 8190 y RFC 919 |
Direcciones no utilizables en subredes IPv4
GDC usa las dos primeras y las dos últimas direcciones IPv4 de cada subred para alojarla.
| Dirección IPv4 no utilizable | Descripción | Ejemplo |
|---|---|---|
| Dirección de red | Primera dirección del intervalo IPv4 principal. | 10.1.2.0 del intervalo 10.1.2.0/24 |
| Dirección de la pasarela predeterminada | Segunda dirección del intervalo IPv4 principal. | 10.1.2.1 del intervalo 10.1.2.0/24 |
| Penúltima dirección | Penúltima dirección del intervalo IPv4 principal.
Google Cloud ha reservado este intervalo para un posible uso futuro. |
10.1.2.254 del intervalo 10.1.2.0/24 |
| Dirección de difusión | Última dirección del intervalo IPv4 principal. | 10.1.2.255 del intervalo 10.1.2.0/24 |
Consideraciones adicionales
Algunos productos de Google y de terceros usan 172.17.0.0/16 para enrutar dentro del sistema operativo invitado. Por ejemplo, la red de puente de Docker predeterminada usa este intervalo. Si dependes de un producto que usa 172.17.0.0/16, no lo utilices como intervalo de direcciones IPv4 de ninguna subred.
Permisos de gestión de identidades y accesos para subredes
Google Distributed Cloud aislado admite un amplio conjunto de permisos de gestión de identidades y accesos para gestionar subredes.
- Administrador de la organización de subredes (global): gestiona varias subredes de zona dentro de la organización. Pide al administrador de gestión de identidades y accesos de tu organización que te conceda el rol de clúster SubnetOrganization Admin (
subnet-org-admin). - Administrador de la organización de subredes: gestiona las subredes zonales de la organización. Pide al administrador de gestión de identidades y accesos de tu organización que te conceda el rol de clúster SubnetOrganization Admin (
subnet-org-admin). - Administrador de proyectos de subredes (global): gestiona varias subredes de zonas en proyectos. Pide al administrador de gestión de identidades y accesos de tu organización que te conceda el rol Administrador de proyectos de subred (
subnet-project-admin). - Administrador de subredes de proyecto: gestiona las subredes zonales de los proyectos. Pide al administrador de gestión de identidades y accesos de tu organización que te asigne el rol de administrador de proyectos de subred (
subnet-project-admin).- Este rol tiene permiso para leer todas las subredes del espacio de nombres del proyecto y para crear, actualizar y eliminar la mayoría de las subredes de los espacios de nombres del proyecto.
Sin embargo, este rol no concede permiso para crear, actualizar o eliminar subredes de tipo raíz (
subnet.Spec.Type== Root).
- Este rol tiene permiso para leer todas las subredes del espacio de nombres del proyecto y para crear, actualizar y eliminar la mayoría de las subredes de los espacios de nombres del proyecto.
Sin embargo, este rol no concede permiso para crear, actualizar o eliminar subredes de tipo raíz (
- Operador de proyecto de subred: gestiona las subredes asignadas automáticamente de tipo hoja en los proyectos. Pide al administrador de gestión de identidades y accesos de tu organización que te conceda el rol Operador de proyectos de subred (
subnet-project-operator).- Este rol tiene permiso para leer todas las subredes del espacio de nombres del proyecto y para crear, actualizar o eliminar solo las subredes hoja asignadas automáticamente en los espacios de nombres del proyecto. Este rol no concede permiso para crear, actualizar o eliminar las siguientes subredes:
- Subredes de tipo raíz o rama (
subnet.Spec.Type== Root ||subnet.Spec.Type== Branch) - Subredes de la red (
subnet.Spec.NetworkSpec!= nil) - subredes con CIDR dedicado (
subnet.Spec.Ipv4Request.CIDR!= nil ||subnet.Spec.Ipv6Request.CIDR!= nil)
- Subredes de tipo raíz o rama (
- Este rol tiene permiso para leer todas las subredes del espacio de nombres del proyecto y para crear, actualizar o eliminar solo las subredes hoja asignadas automáticamente en los espacios de nombres del proyecto. Este rol no concede permiso para crear, actualizar o eliminar las siguientes subredes:
- Lector de plataforma de subred: obtiene subredes en el espacio de nombres
platform. Pídele al administrador de gestión de identidades y accesos de tu organización que te conceda el rol de lector de plataforma de subred (subnet-platform-viewer). - Para usar una subred compartida en el espacio de nombres de la plataforma como elemento superior para asignar una subred dentro del proyecto, pide al administrador de gestión de identidades y accesos de tu organización que te conceda el rol
shared-subnet-user. - Para conceder una subred dedicada en el espacio de nombres de la plataforma que se usará como elemento principal para asignar una subred dentro del proyecto,
subnet-org-admindebe crear o actualizar una subred y definir la anotación"ipam.gdc.goog/subnet-delegation-role": autoen ella. A continuación, pide al administrador de gestión de identidades y accesos de tu organización que le conceda al usuario el rol<subnetName>-user. - Para habilitar un grupo de subredes en el espacio de nombres de la plataforma para la asignación de subredes internas del proyecto, el
subnet-org-admindebe crear o actualizar todas las subredes del grupo. Para cada subred, se debe definir la anotación"ipam.gdc.goog/subnet-delegation-role": auto. A continuación, pide al administrador de IAM de la organización que conceda el rol<subnetName>-usera cada subred del grupo.
Siguientes pasos
- Descripción general de las redes
- Asignar direcciones IP a cargas de trabajo
- Incorporar tus propias direcciones IP externas
- Descripción general de las multizonas