Aprovisiona direcciones IP para las cargas de trabajo

Crea subredes adicionales en la nube privada virtual (VPC) interna de tu organización o en la VPC predeterminada para satisfacer tus requisitos de herramientas de redes internas. Por ejemplo, agrega subredes de VPC para asegurarte de que tus cargas de trabajo internas, como las máquinas virtuales (VMs) y los contenedores, tengan suficientes direcciones IP.

En esta página, se describen varias tareas que no se deben completar en orden:

• Crea una subred de rama zonal para las cargas de trabajo: Esta tarea es útil para organizar o asignar aún más las direcciones IP internas existentes de tu zona a las cargas de trabajo.
• Crea una subred de hoja para una carga de trabajo individual: Esta tarea es útil cuando tienes una carga de trabajo nueva que aún no tiene una dirección IP para usar.
• Asigna una subred zonal desde el rango de direcciones IP globales: Esta tarea es útil cuando tu zona ya no tiene suficiente espacio de direcciones IP internas.
• Divide la subred global raíz sin asignación de zona: Esta tarea es útil para organizar aún más las direcciones IP internas en el servidor de la API global antes de asignarlas a una zona.
• Agregar una nueva subred global de rango raíz de red: Esta tarea es útil cuando tu VPC predeterminada ya no tiene suficiente espacio de direcciones IP internas globales para asignar a tus zonas.

Para obtener una descripción general de las subredes y sus conceptos antes de completar las tareas de esta página, consulta Subredes y direcciones IP.

Este documento está dirigido a los administradores de plataformas y operadores de aplicaciones que son responsables de administrar el tráfico de red de su organización. Para obtener más información, consulta Públicos de la documentación de GDC aislado.

Antes de comenzar

Para obtener el permiso que necesitas para crear subredes, pídele al administrador de IAM de la organización que te otorgue el rol de IAM de administrador de la organización de subredes (subnet-org-admin). Este rol no está vinculado a un espacio de nombres.

Crea una subred de rama zonal para las cargas de trabajo

Para subdividir aún más las direcciones IP en tu VPC predeterminada zonal, puedes crear una subred interna zonal a partir de la subred raíz zonal existente de la zona. Debes crear este tipo de subred en el espacio de nombres platform.

Si la subred raíz zonal superior no tiene suficientes direcciones IP disponibles, asigna otra subred zonal del rango de direcciones IP global antes de continuar.

• En una ventana de terminal, crea la nueva subred zonal en el servidor de la API de administración:

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
    name: SUBNET_NAME
    namespace: platform
  spec:
    ipv4Request:
      prefixLength: CIDR_PREFIX_LENGTH
    networkSpec:
      enableGateway: true
      enableVLANID: false
    parentReference:
      name: PARENT_SUBNET_NAME
      namespace: platform
    type: Branch
  EOF
  

  Reemplaza lo siguiente:

  • MANAGEMENT_API_SERVER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig de tu servidor de la API de administración. Para obtener más información, consulta Recursos del servidor de la API de administración zonal.

  • SUBNET_NAME: Es el nombre de la subred de tu red nueva.

  • CIDR_PREFIX_LENGTH: Es la longitud del prefijo de tu subred nueva, como 27. Este campo asigna de forma dinámica el siguiente rango de direcciones IP disponible de ese tamaño de la subred superior. Usa el campo prefixLength cuando solo te importe el tamaño de la subred, no su rango de direcciones IP específico.

    Para asignar un rango de direcciones IP específico, sigue estos pasos:

    1. Quita la línea prefixLength: CIDR_PREFIX_LENGTH.
    2. Agrega una línea cidr: "YOUR_CIDR_BLOCK" en su lugar, como cidr: "10.0.10.0/27".

    Usa el campo cidr cuando sigas un plan de IP estricto y necesites asignar un rango de direcciones IP preciso y predecible. Este rango debe ser una subred válida y disponible dentro de la subred superior.

  • PARENT_SUBNET_NAME: Es el nombre de la subred superior, como default-vpc-zone0-cidr. La subred superior suele ser una subred raíz zonal en la VPC predeterminada.

  Para obtener más información, consulta la documentación de referencia de la API para el recurso Subnet.

  Puedes seguir dividiendo tus subredes zonales o crear una subred de hoja para asignar una dirección IP individual directamente a una carga de trabajo interna.

Crea una subred de hoja para una carga de trabajo individual

Para asignar una sola dirección IP a tu carga de trabajo, debes crear una subred de hoja. Esta subred de hoja debe tener el valor de campo type: Leaf y debe residir en el mismo espacio de nombres del proyecto que el recurso de carga de trabajo, como una VM o un contenedor.

La subred de hoja debe configurarse con un valor prefixLength de 32, ya que está diseñada para asignar una sola dirección IP. El valor parentReference hace referencia a una subred asignada con anterioridad, como la subred zonal superior que creaste en Crea una subred de rama zonal para las cargas de trabajo.

• En una ventana de terminal, crea la subred de hoja en el servidor de la API de administración:

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
    name: SUBNET_NAME
    namespace: PROJECT_NAMESPACE
  spec:
    ipv4Request:
      prefixLength: 32
    parentReference:
      name: PARENT_SUBNET
      namespace: PARENT_NAMESPACE
    type: Leaf
  EOF
  

  Reemplaza lo siguiente:

  • MANAGEMENT_API_SERVER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig de tu servidor de la API de administración. Para obtener más información, consulta Recursos del servidor de la API de administración zonal.
  • SUBNET_NAME: Es el nombre de la subred de hoja.
  • PROJECT_NAMESPACE: el espacio de nombres del proyecto correspondiente a tu proyecto en el que se encuentran tus cargas de trabajo.
  • PARENT_SUBNET: Es el nombre de la subred superior de la que esta subred de hoja obtendrá su dirección IP.
  • PARENT_NAMESPACE: Es el espacio de nombres de PROJECT_NAMESPACE o platform.

Tu dirección IP individual ahora está disponible para que la usen tus cargas de trabajo internas, como VMs y contenedores. Para obtener más información sobre cómo configurar la dirección IP de tus cargas de trabajo, consulta Crea una VM con una dirección IP estática o dinámica o Configura un balanceador de cargas interno para cargas de trabajo de contenedores.

Asigna una subred zonal desde un rango de direcciones IP global

Si tu zona no proporciona suficientes direcciones IP para tus cargas de trabajo desde el rango de direcciones IP de la subred raíz zonal existente, puedes asignar direcciones IP adicionales desde el rango raíz de direcciones IP global.

Para asignar una subred zonal desde el rango de direcciones IP global, completa los siguientes pasos para la red de VPC predeterminada en el espacio de nombres platform:

1. En una ventana de terminal, describe todas las subredes raíz de la VPC predeterminada y verifica sus bloques CIDR disponibles:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       -l ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage=network-root-range
   

   Reemplaza GLOBAL_API_SERVER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del servidor de la API global. Para obtener más información, consulta Recursos globales del servidor de la API. Las etiquetas son constantes y deben permanecer iguales.

   El resultado es similar a lo siguiente:

   Name:         default-vpc-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=default-vpc-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/vpc=default-vpc
   Annotations:  <none>
   API Version:  ipam.global.gdc.goog/v1
   Kind:         Subnet
   Metadata:
     Creation Timestamp:  2025-06-18T23:05:38Z
     Finalizers:
       global-subnet-finalizer
     Generation:        1
     Resource Version:  439434
     UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
   Spec:
     ipv4Request:
       Cidr:                10.252.0.0/14
     Propagation Strategy:  None
     Type:                  Root
   Status:
     Children Refs:
       Name:       default-vpc-zone1-root-cidr
       Namespace:  platform
       Type:       SingleSubnet
     Conditions:
       Last Transition Time:  2025-06-18T23:05:38Z
       Message:               IP allocation finished successfully
       Observed Generation:   1
       Reason:                AllocationSucceeded
       Status:                True
       Type:                  Ready
     ipv4Allocation:
       Available CIDRs:
         10.254.0.0/15
         10.253.0.0/16
       Cidr:  10.252.0.0/14
   Events:    <none>
   

   Toma nota de los valores de Status.ipv4Allocation.Available CIDRs. Estos valores son los bloques CIDR disponibles a los que se hace referencia en el siguiente paso. En el resultado anterior, los rangos CIDR 10.254.0.0/15 y 10.253.0.0/16 están disponibles. Es posible que el resultado muestre varias subredes. Toma nota de todos los bloques CIDR disponibles y sus subredes de origen.

2. Compara el bloque CIDR más grande disponible del paso anterior con el tamaño del bloque CIDR necesario para tu zona. Si el bloque CIDR más grande disponible no es lo suficientemente grande como para asignar tu subred nueva, agrega una subred global de rango raíz de red nueva antes de continuar. Toma nota de la subred superior de la que decides obtener el bloque CIDR para tu subred nueva.

   Por ejemplo, si necesitas un bloque CIDR /13, pero los CIDR disponibles solo incluyen /15 y /16, debes agregar una subred global de rango raíz de red nueva. Si necesitas una subred /15, puedes asignar una subred zonal nueva desde el bloque CIDR /15 existente.

3. Crea la subred nueva en el servidor de la API global:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/vpc: default-vpc
       ipam.gdc.goog/usage: zone-network-root-range
     name: SUBNET_NAME
     namespace: platform
   spec:
     ipv4Request:
       prefixLength: CIDR_PREFIX_LENGTH
     zone: ZONE_NAME
     propagationStrategy: SingleZone
     type: Branch
     parentReference:
       name: PARENT_SUBNET_NAME
       namespace: ORG_NAME
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del servidor de la API global. Para obtener más información, consulta Recursos globales del servidor de la API.
   • SUBNET_NAME: es el nombre de la subred nueva.
   • CIDR_PREFIX_LENGTH: Es la longitud del prefijo CIDR de la subred nueva que se asigna de forma dinámica, como 20. Para configurar el CIDR de forma estática, reemplaza el campo prefixLength por el campo cidr y, luego, configura el bloque CIDR, como 10.0.10.0/27.
   • ZONE_NAME: Es la zona para la que se asignará la subred, como zone1.
   • PARENT_SUBNET_NAME: Es el nombre de la subred superior, como default-vpc-root-cidr, o la nueva subred global del rango raíz de la red que creaste.
   • ORG_NAME: Es el nombre de la organización.

   Para obtener más información, consulta la documentación de referencia de la API para el recurso Subnet.

4. Verifica que la subred esté lista y disponible en el servidor de la API global comprobando que su tipo de estado Ready sea true:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   El resultado es similar a lo siguiente:

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:28:48Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

5. Verifica que la subred zonal se cree en el servidor de la API de Management zonal y que su tipo de estado Ready sea true:

   kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   Reemplaza MANAGEMENT_API_SERVER_KUBECONFIG por la ruta de acceso al archivo kubeconfig de tu servidor de la API de administración. Para obtener más información, consulta Recursos del servidor de la API de administración zonal.

   El resultado es similar a lo siguiente:

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:29:34Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

   Desde esta nueva subred zonal, puedes crear más subredes secundarias zonales o asignar una dirección IP individual directamente a una carga de trabajo interna.

Divide la subred global raíz sin asignación de zona

Para dividir aún más una subred global sin asignarla a una zona, crea una subred global y omite la estrategia de propagación en el recurso personalizado Subnet. Este enfoque es útil si deseas seguir organizando tu rango de direcciones IP de acceso global desde la subred raíz global sin asignar las direcciones IP a una zona.

Para dividir tu subred raíz global dentro del permiso global, completa los siguientes pasos en el espacio de nombres platform:

1. En una ventana de terminal, describe todas las subredes raíz de la VPC predeterminada y verifica sus bloques CIDR disponibles:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG describe subnets --namespace platform \
       -l ipam.gdc.goog/vpc=default-vpc,ipam.gdc.goog/usage=network-root-range
   

   Reemplaza GLOBAL_API_SERVER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del servidor de la API global. Para obtener más información, consulta Recursos globales del servidor de la API. Las etiquetas son constantes y deben permanecer iguales.

   El resultado es similar a lo siguiente:

   Name:         default-vpc-root-cidr
   Namespace:    platform
   Labels:       ipam.gdc.goog/allocation-preference=default
                 ipam.gdc.goog/subnet-group=default-vpc-root-group
                 ipam.gdc.goog/usage=network-root-range
                 ipam.gdc.goog/vpc=default-vpc
   Annotations:  <none>
   API Version:  ipam.global.gdc.goog/v1
   Kind:         Subnet
   Metadata:
     Creation Timestamp:  2025-06-18T23:05:38Z
     Finalizers:
       global-subnet-finalizer
     Generation:        1
     Resource Version:  439434
     UID:               5ed1c51a-b5ee-473e-a185-8e065a87ae8f
   Spec:
     ipv4Request:
       Cidr:                10.252.0.0/14
     Propagation Strategy:  None
     Type:                  Root
   Status:
     Children Refs:
       Name:       default-vpc-zone1-root-cidr
       Namespace:  platform
       Type:       SingleSubnet
     Conditions:
       Last Transition Time:  2025-06-18T23:05:38Z
       Message:               IP allocation finished successfully
       Observed Generation:   1
       Reason:                AllocationSucceeded
       Status:                True
       Type:                  Ready
     ipv4Allocation:
       Available CIDRs:
         10.254.0.0/15
         10.253.0.0/16
       Cidr:  10.252.0.0/14
   Events:    <none>
   

   Toma nota de los valores de Status.ipv4Allocation.Available CIDRs. Estos valores son los bloques CIDR disponibles a los que se hace referencia en el siguiente paso. En el resultado anterior, los rangos CIDR 10.254.0.0/15 y 10.253.0.0/16 están disponibles. Puede haber varias subredes en el resultado según la cantidad de subredes raíz que tengas, así que toma nota de todos los bloques CIDR disponibles y de qué subred proviene el bloque CIDR disponible.

2. Compara el bloque CIDR más grande disponible del paso anterior con el tamaño del bloque CIDR necesario para tu nueva subred global. Si el bloque CIDR más grande disponible no es lo suficientemente grande como para asignar tu subred nueva, agrega una subred global de rango raíz de red nueva antes de continuar. Toma nota de la subred superior de la que decides obtener el bloque CIDR para tu subred nueva.

   Por ejemplo, si necesitas un bloque CIDR /13, pero los CIDR disponibles solo incluyen /15 y /16, debes crear una nueva subred global de rango raíz de red. Si necesitas una subred /15, puedes asignar la nueva subred global desde el bloque CIDR /15 existente.

3. Crea la subred nueva en el servidor de la API global:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
   apiVersion: ipam.global.gdc.goog/v1
   kind: Subnet
   metadata:
     labels:
       ipam.gdc.goog/vpc: default-vpc
       ipam.gdc.goog/usage: zone-network-root-range
     name: SUBNET_NAME
     namespace: platform
   spec:
     ipv4Request:
       prefixLength: CIDR_PREFIX_LENGTH
     propagationStrategy: None
     type: Branch
     parentReference:
       name: PARENT_SUBNET_NAME
       namespace: ORG_NAME
   EOF
   

   Reemplaza lo siguiente:

   • GLOBAL_API_SERVER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del servidor de la API global. Para obtener más información, consulta Recursos globales del servidor de la API.
   • SUBNET_NAME: es el nombre de la subred nueva.
   • CIDR_PREFIX_LENGTH: Es la longitud del prefijo CIDR de la subred nueva que se asigna de forma dinámica, como 20. Para configurar el CIDR de forma estática, reemplaza el campo prefixLength por el campo cidr y, luego, configura el bloque CIDR, como 10.0.10.0/27.
   • PARENT_SUBNET_NAME: Es el nombre de la subred superior, como default-vpc-root-cidr, o la nueva subred global del rango raíz de la red que creaste.
   • ORG_NAME: Es el nombre de la organización.

   Para obtener más información, consulta la documentación de referencia de la API del recurso Subnet global.

4. Verifica que la subred esté lista y disponible en el servidor de la API global comprobando que su tipo de estado Ready sea true:

   kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG get subnet --namespace platform \
       SUBNET_NAME --output jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
   

   El resultado es similar a lo siguiente:

   status:
     conditions:
     - lastTransitionTime: "2025-06-06T07:28:48Z"
       message: IP allocation finished successfully
       observedGeneration: 1
       reason: AllocationSucceeded
       status: "True"
       type: Ready
   

La nueva subred global para tu organización en la VPC predeterminada está disponible. Puedes crear una subred para una zona en particular desde esta nueva subred superior global.

Agrega una nueva subred global de rango raíz de red

Las subredes globales con la etiqueta ipam.gdc.goog/usage: network-root-range alojan el CIDR para todas las zonas de la red. Si se agota el CIDR, debes crear una nueva subred de rango raíz de red en el servidor de la API global. Puedes crear varias subredes globales raíz, si es necesario.

Para crear una nueva subred de rango raíz de red, completa los siguientes pasos:

• En una ventana de terminal, crea la nueva subred global del rango raíz de la red para la VPC predeterminada en el espacio de nombres platform:

  kubectl --kubeconfig GLOBAL_API_SERVER_KUBECONFIG apply -f - <<EOF
  apiVersion: ipam.global.gdc.goog/v1
  kind: Subnet
  metadata:
    labels:
      ipam.gdc.goog/vpc: default-vpc
      ipam.gdc.goog/usage: network-root-range
    name: SUBNET_NAME
    namespace: platform
  spec:
    ipv4Request:
      cidr: NEW_CIDR
    type: Root
  EOF
  

  Reemplaza lo siguiente:

  • GLOBAL_API_SERVER_KUBECONFIG: Es la ruta de acceso al archivo kubeconfig del servidor de la API global. Para obtener más información, consulta Recursos globales del servidor de la API.
  • SUBNET_NAME: es el nombre de la subred nueva.
  • NEW_CIDR: Es el CIDR nuevo para la subred. Este CIDR no se puede superponer con ningún CIDR en todas las subredes existentes con la etiqueta ipam.gdc.goog/usage: network-root-range en el mismo servidor de la API global.

Esta nueva subred de rango raíz global se puede subdividir dentro del servidor de la API global o asignar a una zona específica.

¿Qué sigue?

• Subredes y direcciones IP
• Descripción general de las redes
• Implementa una aplicación de VM con alta disponibilidad
• Implementa una aplicación de contenedor con alta disponibilidad