Desplegar una aplicación de VM de alta disponibilidad

En esta página se describe la estrategia de implementación recomendada para crear una aplicación de máquina virtual (VM) sólida y de alta disponibilidad (HA) en Google Distributed Cloud (GDC) air-gapped. Debes desplegar la aplicación de VM en varias zonas de GDC y configurar la replicación de almacenamiento asíncrona para que la aplicación y sus datos se puedan recuperar en caso de que se produzca un tiempo de inactividad inesperado o un desastre local.

Esta página está dirigida a los desarrolladores del grupo de operadores de aplicaciones, que son responsables de crear cargas de trabajo de aplicaciones para su organización. Para obtener más información, consulta Audiencias de la documentación aislada de GDC.

Objetivos

  • Crea una instancia de VM con discos de arranque conectados en dos o más zonas de tu universo de GDC.
  • Configura el balanceo de carga global.
  • Configura la replicación de almacenamiento asíncrona mediante almacenamiento en bloque o almacenamiento de objetos.

Antes de empezar

  • Verifica que estás trabajando en un universo de GDC con varias zonas disponibles. Ejecuta gdcloud zones list para ver las zonas disponibles en tu universo. Para obtener más información, consulta Listar zonas de un universo.

  • Pide al administrador de gestión de identidades y accesos de tu organización que te conceda los siguientes roles:

    • Los roles de máquina virtual para crear y gestionar cargas de trabajo de máquinas virtuales.
    • Los roles Administrador de balanceadores de carga (load-balancer-admin) y Administrador de balanceadores de carga globales (global-load-balancer-admin). Debes tener estos roles para crear y gestionar balanceadores de carga.
    • El rol Administrador global de replicación de volúmenes (app-volume-replication-admin-global). Debes tener este rol para administrar la replicación de volúmenes.
    • El rol de administrador global de PNP (global-project-networkpolicy-admin). Debes tener este rol para crear y gestionar políticas de red de proyectos en todas las zonas.
    • El rol Administrador global de replicación de volúmenes (app-volume-replication-admin-global) para administrar la relación de replicación de volúmenes de los recursos de almacenamiento en bloque.
    • Los roles Administrador de objetos de contenedor de proyecto (project-bucket-object-admin) y Administrador de contenedor de proyecto (project-bucket-admin) para crear y gestionar contenedores de almacenamiento.

    Para obtener más información, consulta las descripciones de los roles.

  • Instala y configura la CLI de gdcloud y configura los contextos zonales y globales. Consulta el artículo sobre cómo gestionar recursos en varias zonas para obtener más información.

  • Instala y configura la CLI kubectl con los archivos kubeconfig adecuados para el servidor de la API global y el servidor de la API de gestión. Para obtener más información, consulta Generar manualmente el archivo kubeconfig.

Crear una instancia de VM en varias zonas

Una instancia de VM es un recurso zonal, por lo que debes crear una VM por separado en cada zona. En este ejemplo, crearás una instancia de VM con una imagen de SO proporcionada por GDC y asociarás un disco de arranque a la VM. Para obtener más información sobre cómo crear instancias de VM y usar imágenes personalizadas, consulta Crear e iniciar una VM.

De forma predeterminada, todos los proyectos de GDC pueden crear VMs a partir de imágenes de SO proporcionadas por GDC.

Consola

  1. En el menú de navegación, selecciona Máquinas virtuales > Instancias.
  2. Haz clic en Crear instancia.
  3. En el campo Nombre, especifica un nombre para la VM.
  4. Selecciona la zona en la que quieres crear la VM.
  5. Haz clic en Añadir etiquetas para asignar etiquetas a la VM y organizar tus instancias de VM.
  6. Selecciona la configuración de la máquina que quieras usar en la VM. Verifica que el tipo de máquina se ajuste a tu carga de trabajo, en función de tus requisitos.
  7. Haz clic en Siguiente.
  8. Habilita el acceso externo a tu instancia de VM.
  9. Haz clic en Siguiente.
  10. Selecciona Add New Disk (Añadir disco nuevo).
  11. Asigna un nombre al disco de la VM.
  12. Configura el tamaño del disco y los ajustes de los archivos adjuntos.
  13. Haz clic en Guardar.
  14. Haz clic en Crear para crear la instancia de VM.
  15. Repite los pasos anteriores con cada zona de tu universo de GDC. Asegúrate de que haya una instancia de VM en cada zona que quieras incluir en tu estrategia de alta disponibilidad.

gdcloud

  1. Inicia sesión en la zona en la que quieras alojar tu instancia de VM:

    gdcloud config set core/zone ZONE

  2. Crea la instancia de VM en la zona con una imagen proporcionada por GDC:

    gdcloud compute instances create VM_NAME \
    --machine-type=MACHINE_TYPE \
    --image=BOOT_DISK_IMAGE_NAME
    --image-project=vm-system \
    --boot-disk-size=BOOT_DISK_SIZE \
    --no-boot-disk-auto-delete=NO_BOOT_DISK_AUTO_DELETE

    Haz los cambios siguientes:

    • VM_NAME: nombre de la nueva VM. El nombre solo puede contener caracteres alfanuméricos y guiones, y no debe tener más de 53 caracteres.
    • MACHINE_TYPE: el tipo de máquina predefinido de la nueva VM. Para seleccionar un tipo de máquina disponible, ejecuta gdcloud compute machine-types list.
    • BOOT_DISK_IMAGE_NAME: el nombre de la imagen que se va a usar para el nuevo disco de arranque de la VM.
    • BOOT_DISK_SIZE: el tamaño del disco de arranque, como 20GB. Este valor siempre debe ser mayor o igual que el minimumDiskSize de la imagen del disco de arranque.
    • NO_BOOT_DISK_AUTO_DELETE: indica si el disco de arranque se elimina automáticamente cuando se elimina la instancia de VM.

  3. Repite los pasos anteriores con cada zona de tu universo de GDC. Asegúrate de que haya una instancia de VM en cada zona que quieras incluir en tu estrategia de alta disponibilidad.

API

  1. Crea la instancia de VM en la zona con una imagen proporcionada por GDC:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineDisk
metadata:
  name: VM_BOOT_DISK_NAME
  namespace: PROJECT
spec:
  source:
    image:
      name: BOOT_DISK_IMAGE_NAME
      namespace: vm-system
  size: BOOT_DISK_SIZE
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachine
metadata:
  name: VM_NAME
  namespace: PROJECT
spec:
  compute:
    virtualMachineType: MACHINE_TYPE
  disks:
    - virtualMachineDiskRef:
        name: VM_BOOT_DISK_NAME
      boot: true
      autoDelete: BOOT_DISK_AUTO_DELETE
---
apiVersion: virtualmachine.gdc.goog/v1
kind: VirtualMachineExternalAccess
metadata:
  name: VM_NAME
  namespace: PROJECT
spec:
  enabled: true
  ports:
  - name: port-80
    port: 80
    protocol: TCP
EOF

    Haz los cambios siguientes:

    • MANAGEMENT_API_SERVER: archivo kubeconfig del servidor de la API Management de la zona en la que se va a crear la instancia de VM. Si aún no has generado un archivo kubeconfig para el servidor de la API Management, consulta Generar manualmente un archivo kubeconfig para obtener más información.
    • VM_BOOT_DISK_NAME: el nombre del nuevo disco de arranque de la VM.
    • PROJECT: el proyecto de GDC en el que se creará la VM.
    • BOOT_DISK_IMAGE_NAME: el nombre de la imagen que se va a usar para el nuevo disco de arranque de la VM.
    • BOOT_DISK_SIZE: el tamaño del disco de arranque, como 20Gi. Este valor siempre debe ser mayor o igual que el minimumDiskSize de la imagen del disco de arranque.
    • VM_NAME: nombre de la nueva VM. El nombre solo puede contener caracteres alfanuméricos y guiones, y no debe tener más de 53 caracteres.
    • MACHINE_TYPE: el tipo de máquina predefinido de la nueva VM. Para seleccionar un tipo de máquina disponible, ejecuta gdcloud compute machine-types list.
    • BOOT_DISK_AUTO_DELETE: indica si el disco de arranque se elimina automáticamente cuando se elimina la instancia de VM.

  2. Comprueba que la VM esté disponible y espera a que muestre el estado Running. El estado Running no indica que el SO esté totalmente listo y accesible.

    kubectl --kubeconfig MANAGEMENT_API_SERVER \
    get virtualmachine.virtualmachine.gdc.goog VM_NAME -n PROJECT

    Sustituye VM_NAME y PROJECT por el nombre y el proyecto de la VM.

  3. Repite los pasos anteriores con cada zona de tu universo de GDC. Asegúrate de que haya una instancia de VM en cada zona que quieras incluir en tu estrategia de alta disponibilidad.

Configurar balanceadores de carga

Para distribuir el tráfico entre tus VMs de diferentes zonas, crea balanceadores de carga. Puedes crear balanceadores de carga externos (ELB) y balanceadores de carga internos (ILB), que se pueden configurar por zonas o de forma global. En este ejemplo, configuraremos un ILB global y un ELB global para la aplicación de la VM.

Crear un balanceador de carga interno global

Los balanceadores de carga internos (ILBs) exponen servicios dentro de la organización desde un grupo de direcciones IP internas asignado a la organización. Nunca se puede acceder a un servicio de ILB desde ningún punto final que no pertenezca a la organización.

Sigue estos pasos para crear un ILB global para tus cargas de trabajo de VM.

gdcloud

Crea un ILB que tenga como destino cargas de trabajo de máquinas virtuales mediante la CLI de gcloud.

Este ILB está dirigido a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend. El recurso personalizado Backend debe tener un ámbito de zona.

Para crear un ILB con la CLI de gdcloud, sigue estos pasos:

  1. Crea un recurso Backend de zona en cada zona en la que se ejecuten tus VMs para definir el endpoint del ILB:

    gdcloud compute backends create BACKEND_NAME \
    --labels=LABELS \
    --project=PROJECT \
    --zone=ZONE

    Haz los cambios siguientes:

    • BACKEND_NAME: el nombre elegido para el recurso de backend, como my-backend.
    • LABELS: el selector que define qué endpoints entre las VMs se van a usar para este recurso de backend, como app=web.
    • PROJECT: el nombre de tu proyecto.
    • ZONE: la zona que se va a usar en esta invocación. Para predefinir la marca de zona en todos los comandos que la requieran, ejecuta gdcloud config set core/zone ZONE. La marca de zona solo está disponible en entornos multizona. Este campo es opcional.

    Repite este paso con cada zona de tu universo de GDC.

  2. Define una comprobación del estado global para el ILB:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
    --check-interval=CHECK_INTERVAL \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --timeout=TIMEOUT \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --port=PORT \
    --global

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre del recurso de comprobación de estado, como my-health-check.
    • CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5. Este campo es opcional.
    • HEALTHY_THRESHOLD: el tiempo que se debe esperar antes de declarar un error. El valor predeterminado es 5. Este campo es opcional.
    • TIMEOUT: el tiempo en segundos que se debe esperar antes de declarar un fallo. El valor predeterminado es 5. Este campo es opcional.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2. Este campo es opcional.
    • PORT: el puerto en el que se realiza la comprobación de estado. El valor predeterminado es 80. Este campo es opcional.

  3. Crea un recurso BackendService global:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
    --project=PROJECT \
    --target-ports=TARGET_PORTS \
    --health-check=HEALTH_CHECK_NAME \
    --global

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre del servicio de backend.
    • PROJECT: el nombre de tu proyecto.
    • TARGET_PORTS: lista separada por comas de puertos de destino que traduce este servicio de backend. Cada puerto de destino especifica el protocolo, el puerto de la regla de reenvío y el puerto de la instancia de backend. Puede especificar varios puertos de destino. Este campo debe tener el formato protocol:port:targetport, como TCP:80:8080. Este campo es opcional.
    • HEALTH_CHECK_NAME: el nombre del recurso de comprobación de estado. Este campo es opcional.

  4. Añade el recurso BackendService al recurso Backend que has creado anteriormente en cada zona:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    --backend-zone=ZONE \
    --backend=BACKEND_NAME \
    --project=PROJECT \
    --global

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre del servicio de backend global.
    • ZONE: la zona del backend.
    • BACKEND_NAME: el nombre del backend zonal.
    • PROJECT: el nombre de tu proyecto.

    Complete este paso para cada backend zonal que haya creado anteriormente.

  5. Crea un recurso ForwardingRule interno que defina la dirección IP virtual (VIP) en la que está disponible el servicio:

    gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
    --backend-service=BACKEND_SERVICE_NAME \
    --cidr=CIDR \
    --ip-protocol-port=PROTOCOL_PORT \
    --load-balancing-scheme=INTERNAL \
    --project=PROJECT \
    --global

    Haz los cambios siguientes:

    • FORWARDING_RULE_INTERNAL_NAME: el nombre de la regla de reenvío.
    • CIDR: el CIDR que se va a usar en la regla de reenvío. Este campo es opcional. Si no se especifica ninguna, se reserva automáticamente un CIDR IPv4/32 del grupo de direcciones IP global. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred global. Para obtener más información sobre los recursos de Subnet, consulta Gestionar subredes.
    • PROTOCOL_PORT: el protocolo y el puerto que se expondrán en la regla de reenvío. Este campo debe tener el formato ip-protocol=TCP:80. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro de la VM.

  6. Para validar el ILB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una solicitud curl a la VIP:

    1. Para obtener la VIP asignada, describe la regla de reenvío:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. Verifica el tráfico con una solicitud curl a la dirección IP virtual en el puerto especificado en el campo de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

    Haz los cambios siguientes:

    • FORWARDING_RULE_VIP: el VIP de la regla de reenvío.
    • PORT: número de puerto de la regla de reenvío.

API

Crea un ILB que tenga como destino cargas de trabajo de VMs mediante la API KRM. Este ILB se dirige a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend. Para crear un ILB global con la API KRM, sigue estos pasos:

  1. Crea un recurso Backend para definir los endpoints del ILB. Crea recursos Backendpara cada zona en la que se coloquen las cargas de trabajo de las VMs:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT
  name: BACKEND_NAME
spec:
  endpointsLabels:
    matchLabels:
      app: APP_NAME
EOF

    Haz los cambios siguientes:

    • MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API Management zonal. Para obtener más información, consulta Cambiar a un contexto zonal.
    • PROJECT: el nombre de tu proyecto.
    • BACKEND_NAME: el nombre del Backend recurso.
    • APP_NAME: el nombre de tu aplicación de VM.

    Puede usar el mismo recurso Backend para cada zona o crear recursos Backend con conjuntos de etiquetas diferentes para cada zona.

  2. Define una comprobación del estado global para el ILB:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Para obtener más información, consulta Cambiar a un contexto global.
    • PROJECT: el nombre de tu proyecto.
    • HEALTH_CHECK_NAME: el nombre del recurso de comprobación de estado, como my-health-check.
    • PORT: el puerto en el que se realizará la comprobación del estado. El valor predeterminado es 80.
    • TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un error. El valor predeterminado es 5.
    • CHECK_INTERVAL: el tiempo en segundos que transcurre desde el inicio de una comprobación hasta el inicio de la siguiente. El valor predeterminado es 5.
    • HEALTHY_THRESHOLD: el número de sondeos secuenciales que deben completarse correctamente para que el endpoint se considere en buen estado. El valor predeterminado es 2.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2.

  3. Crea un objeto BackendService usando el recurso Backend que has creado anteriormente. Incluye el recurso HealthCheck:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global.
    • PROJECT: el nombre de tu proyecto.
    • BACKEND_SERVICE_NAME: el nombre que elijas para tu recurso BackendService.
    • HEALTH_CHECK_NAME: el nombre del recurso HealthCheck que has creado anteriormente.
    • BACKEND_NAME: nombre del recurso de zona Backend

    • ZONE: la zona en la que se encuentra el recurso Backend. Puedes especificar varios back-ends en el campo backendRefs. Por ejemplo:

      - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

      El campo targetPorts es opcional. En este recurso se enumeran los puertos que traduce este recurso BackendService. Si usas este objeto, proporciona valores para lo siguiente:

    • PORT: el puerto expuesto por el servicio.

    • PROTOCOL: el protocolo de capa 4 con el que debe coincidir el tráfico. Solo se admiten TCP y UDP.

    • TARGET_PORT: el puerto al que se traduce el valor, como 8080. El valor no se puede repetir en un objeto determinado.

      Un ejemplo de targetPorts podría ser el siguiente:

      targetPorts:
  - port: 80
    protocol: TCP
    targetPort: 8080

  4. Crea un recurso ForwardingRule interno que defina la dirección IP virtual (VIP) en la que está disponible el servicio.

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global.
    • PROJECT: el nombre de tu proyecto.
    • FORWARDING_RULE_INTERNAL_NAME: el nombre que elijas para tu recurso ForwardingRuleInternal.
    • CIDR: el CIDR que se va a usar en la regla de reenvío. Este campo es opcional. Si no se especifica ninguna, se reserva automáticamente un CIDR IPv4/32 del grupo de direcciones IP global. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred global. Para obtener más información sobre los recursos de Subnet, consulta Gestionar subredes.
    • PORT: el puerto que se va a exponer en la regla de reenvío. Utilice el campo ports para especificar una matriz de puertos L4 para los que se reenvían paquetes a los back-ends configurados con esta regla de reenvío. Se debe especificar al menos un puerto. Usa el campo port para especificar un número de puerto. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.

    • PROTOCOL: el protocolo que se va a usar en la regla de reenvío, como TCP. Una entrada de la matriz ports debe tener el siguiente formato:

      ports:
- port: 80
  protocol: TCP

  5. Para validar el ILB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una solicitud curl a la VIP:

    1. Recuperar el VIP:

      kubectl get forwardingruleinternal -n PROJECT

      La salida tiene este aspecto:

      NAME           BACKENDSERVICE                  CIDR              READY
ilb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True

    2. Prueba el tráfico con una solicitud curl a la IP virtual en el puerto especificado en el campo de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Haz los cambios siguientes:

      • FORWARDING_RULE_VIP: el VIP de la regla de reenvío.
      • PORT: número de puerto del campo de la regla de reenvío.

Crear un balanceador de carga externo global

Los balanceadores de carga externos (ELB) exponen los servicios para que se pueda acceder a ellos desde fuera de la organización a partir de las direcciones IP de un pool asignadas a la organización desde el pool de direcciones IP externas de instancias más grande.

Sigue estos pasos para crear un ELB global para tus cargas de trabajo de VM.

gdcloud

Usa la CLI gdcloud para crear un ELB global que tenga como destino todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend. El recurso personalizado Backend debe tener un ámbito de zona.

  1. Para que los servicios de ELB funcionen, debes configurar y aplicar tu propia transferencia de datos de ProjectNetworkPolicy personalizada en la política para permitir el tráfico a las cargas de trabajo de este servicio de ELB. Las políticas de red controlan el acceso a tus cargas de trabajo, no al propio balanceador de carga. Los ELBs exponen las cargas de trabajo a la red de tus clientes, lo que requiere políticas de red explícitas para permitir el tráfico externo al puerto de la carga de trabajo, como 8080.

    Especifica la dirección CIDR externa para permitir el tráfico a las cargas de trabajo de este ELB:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Si aún no has generado un archivo kubeconfig para el servidor de la API global, consulta Generar manualmente un archivo kubeconfig para obtener más información.
    • PROJECT: el nombre de tu proyecto.
    • CIDR: el CIDR externo desde el que se debe acceder al ELB. Esta política es obligatoria, ya que el balanceador de carga externo usa la devolución directa del servidor (DSR), que conserva la dirección IP externa de origen y omite el balanceador de carga en la ruta de retorno. Para obtener más información, consulta Crear una regla de firewall de entrada global para el tráfico entre organizaciones.
    • PORT: el puerto de backend de las VMs que están detrás del balanceador de carga. Este valor se encuentra en el campo .spec.ports[].targetPortfield del manifiesto del recurso Service. Este campo es opcional.

    Esta configuración proporciona a todos los recursos de los proyectos acceso al intervalo CIDR especificado.

  2. Cree un recurso Backend en cada zona para definir el endpoint del balanceador de carga elástico:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT

    Haz los cambios siguientes:

    • BACKEND_NAME: el nombre del recurso de backend, como my-backend.
    • LABELS: un selector que define qué endpoints entre las VMs se deben usar para este recurso de backend, como app=web.
    • PROJECT: el nombre de tu proyecto.

    Puede usar el mismo recurso Backend para cada zona o crear recursos Backend con conjuntos de etiquetas diferentes para cada zona.

  3. Define una comprobación del estado global para el ELB:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre del recurso de comprobación de estado, como my-health-check.
    • CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una sonda hasta el inicio de la siguiente. El valor predeterminado es 5. Este campo es opcional.
    • HEALTHY_THRESHOLD: el tiempo que hay que esperar antes de reclamar un error. El valor predeterminado es 5. Este campo es opcional.
    • TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un fallo. El valor predeterminado es 5. Este campo es opcional.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2. Este campo es opcional.
    • PORT: el puerto en el que se realizará la comprobación del estado. El valor predeterminado es 80. Este campo es opcional.

  4. Crea un recurso BackendService global:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre elegido para este servicio de backend.
    • PROJECT: el nombre de tu proyecto.
    • TARGET_PORTS: lista de puertos de destino separados por comas que traduce este servicio de backend. Cada puerto de destino especifica el protocolo, el puerto de la regla de reenvío y el puerto de la instancia de backend. Puede especificar varios puertos de destino. Este campo debe tener el formato protocol:port:targetport, como TCP:80:8080. Este campo es opcional.
    • HEALTH_CHECK_NAME: el nombre del recurso de comprobación de estado. Este campo es opcional.

  5. Añade el recurso global BackendService al recurso de zona Backend que has creado anteriormente:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --backend-zone BACKEND_ZONE \
  --project=PROJECT \
  --global

    Complete este paso para cada backend zonal que haya creado anteriormente.

  6. Crea un recurso ForwardingRule externo que defina la IP virtual en la que está disponible el servicio:

    gdcloud compute forwarding-rules create FORWARDING_RULE_EXTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=EXTERNAL \
  --project=PROJECT \
  --global

    Haz los cambios siguientes:

    • FORWARDING_RULE_EXTERNAL_NAME: el nombre de la regla de reenvío.
    • CIDR: el CIDR que se va a usar en la regla de reenvío. Este campo es opcional. Si no se especifica ninguna, se reserva automáticamente un CIDR IPv4/32 del grupo de direcciones IP global. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred global. Para obtener más información sobre los recursos de Subnet, consulta Gestionar subredes.
    • PROTOCOL_PORT: el protocolo y el puerto que se expondrán en la regla de reenvío. Este campo debe tener el formato ip-protocol=TCP:80. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro de la máquina virtual.
    • PROJECT: el nombre de tu proyecto.

  7. Para validar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Verifica el tráfico con una solicitud curl a la VIP:

    1. Para obtener la VIP asignada, describe la regla de reenvío:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

    2. Verifica el tráfico con una solicitud curl a la IP virtual en el puerto especificado en el campo PROTOCOL_PORT de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Haz los cambios siguientes:

      • FORWARDING_RULE_VIP: la IP virtual de la regla de reenvío.
      • PORT: número de puerto del campo PROTOCOL_PORT de la regla de reenvío.

API

Crea un ELB que tenga como destino cargas de trabajo de máquinas virtuales mediante la API KRM. Este ELB se dirige a todas las cargas de trabajo del proyecto que coincidan con la etiqueta definida en el objeto Backend. Para crear un ELB zonal con la API KRM, sigue estos pasos:

  1. Para que los servicios de ELB funcionen, debes configurar y aplicar tu propia transferencia de datos de ProjectNetworkPolicy personalizada en la política para permitir el tráfico a las cargas de trabajo de este servicio de ELB. Las políticas de red controlan el acceso a tus cargas de trabajo, no al propio balanceador de carga. Los ELBs exponen las cargas de trabajo a la red de tus clientes, lo que requiere políticas de red explícitas para permitir el tráfico externo al puerto de la carga de trabajo, como 8080.

    Especifica la dirección CIDR externa para permitir el tráfico a las cargas de trabajo de este ELB:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-inbound-traffic-from-external
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - ipBlock:
        cidr: CIDR
    ports:
    - protocol: TCP
      port: PORT
EOF

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: la ruta de kubeconfig del servidor de la API global. Si aún no has generado un archivo kubeconfig para el servidor de la API global, consulta Generar manualmente un archivo kubeconfig para obtener más información.
    • PROJECT: el nombre de tu proyecto.
    • CIDR: el CIDR externo desde el que se debe acceder al ELB. Esta política es obligatoria, ya que el balanceador de carga externo usa la devolución directa del servidor (DSR), que conserva la dirección IP externa de origen y omite el balanceador de carga en la ruta de retorno. Para obtener más información, consulta Crear una regla de firewall de entrada global para el tráfico entre organizaciones.
    • PORT: el puerto de backend de las VMs que están detrás del balanceador de carga. Este valor se encuentra en el campo .spec.ports[].targetPortfield del manifiesto del recurso Service. Este campo es opcional.

  2. Crea un recurso Backend para definir los endpoints del ELB. Crea recursos Backend para cada zona en la que se coloquen las cargas de trabajo:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT
  name: BACKEND_NAME
spec:
  endpointsLabels:
    matchLabels:
      app: server
EOF

    Haz los cambios siguientes:

    • MANAGEMENT_API_SERVER: la ruta de kubeconfig del servidor de la API Management zonal. Si aún no has generado un archivo kubeconfig para el servidor de la API en tu zona de destino, consulta Generar manualmente un archivo kubeconfig para obtener más información.
    • PROJECT: el nombre de tu proyecto.
    • BACKEND_NAME: el nombre del recurso Backend.

    Puede usar el mismo recurso Backend para cada zona o crear recursos Backend con conjuntos de etiquetas diferentes para cada zona.

  3. Define una comprobación del estado global para el ELB:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    Haz los cambios siguientes:

    • HEALTH_CHECK_NAME: el nombre del recurso de comprobación de estado, como my-health-check.
    • PORT: el puerto en el que se realizará la comprobación del estado. El valor predeterminado es 80.
    • TIMEOUT: tiempo en segundos que se debe esperar antes de declarar un fallo. El valor predeterminado es 5.
    • CHECK_INTERVAL: la cantidad de tiempo en segundos que transcurre desde el inicio de una sonda hasta el inicio de la siguiente. El valor predeterminado es 5.
    • HEALTHY_THRESHOLD: el número de sondeos secuenciales que deben completarse para que el endpoint se considere en buen estado. El valor predeterminado es 2.
    • UNHEALTHY_THRESHOLD: número de sondeos secuenciales que deben fallar para que el endpoint se considere en mal estado. El valor predeterminado es 2.

    Como se trata de un ELB global, crea la comprobación del estado en la API global.

  4. Crea un objeto BackendService usando el recurso Backend que has creado anteriormente:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
EOF

    Haz los cambios siguientes:

    • BACKEND_SERVICE_NAME: el nombre que elijas para tu recurso BackendService.
    • HEALTH_CHECK_NAME: el nombre del recurso HealthCheck que has creado anteriormente. No incluyas este campo si vas a configurar un ELB para cargas de trabajo de pods.
    • ZONE: la zona en la que se encuentra el recurso Backend. Puedes especificar varios back-ends en el campo backendRefs. Por ejemplo:
    - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

  5. Crea un recurso ForwardingRule externo que defina la IP virtual en la que está disponible el servicio.

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleExternal
metadata:
  namespace: PROJECT
  name: FORWARDING_RULE_EXTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Haz los cambios siguientes:

    • FORWARDING_RULE_EXTERNAL_NAME: el nombre elegido para tu recurso ForwardingRuleExternal.
    • CIDR: el CIDR que se va a usar en la regla de reenvío. Este campo es opcional. Si no se especifica ninguna, se reserva automáticamente un CIDR IPv4/32 del grupo de direcciones IP global. Especifica el nombre de un recurso Subnet en el mismo espacio de nombres que esta regla de reenvío. Un recurso Subnet representa la información de solicitud y asignación de una subred global. Para obtener más información sobre los recursos de Subnet, consulta Gestionar subredes.
    • PORT: el puerto que se va a exponer en la regla de reenvío. Utilice el campo ports para especificar una matriz de puertos de nivel 4 para los que se reenvían paquetes a los backends configurados con esta regla de reenvío. Se debe especificar al menos un puerto. Utilice el campo port para especificar un número de puerto. El puerto expuesto debe ser el mismo que el que expone la aplicación real dentro del contenedor.
    • PROTOCOL: el protocolo que se va a usar en la regla de reenvío, como TCP. Una entrada del array ports debe tener el siguiente formato:
    ports:
- port: 80
  protocol: TCP

  6. Para validar el ELB configurado, confirma la condición Ready en cada uno de los objetos creados. Prueba el tráfico con una solicitud curl a la VIP.

    1. Obtén la VIP del proyecto:

      kubectl get forwardingruleexternal -n PROJECT

      La salida tiene este aspecto:

      NAME           BACKENDSERVICE                  CIDR              READY
elb-name       BACKEND_SERVICE_NAME            192.0.2.0/32      True

    2. Verifica el tráfico con una solicitud curl a la IP virtual en el puerto especificado en el campo PORT de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Sustituye FORWARDING_RULE_VIP:PORT por la IP virtual y el puerto de la regla de reenvío, como 192.0.2.0:80.

Configurar la replicación de almacenamiento asíncrona

Los universos multizona de GDC ofrecen el uso de recursos de almacenamiento replicados, como volúmenes y contenedores, en modo asíncrono para situaciones de recuperación tras desastres. Estas opciones de recursos de almacenamiento proporcionan replicación de datos asíncrona entre dos zonas de la misma región. La replicación asíncrona se produce en segundo plano, lo que proporciona un objetivo de punto de recuperación (RPO) bajo, pero no nulo, en caso de desastre. Todos los datos replicados están online y se puede acceder a ellos inmediatamente, pero puede que se necesite un procedimiento de conmutación por error manual para habilitar la escritura en la zona secundaria.

Puedes elegir uno de los siguientes tipos de replicación de almacenamiento asíncrona para tu aplicación de VM:

Crear un segmento de doble zona para el almacenamiento de objetos

Los datos de almacenamiento de objetos se escriben en un solo segmento cuyos datos se almacenan en ambas zonas. Como los datos se copian de forma asíncrona entre zonas, es posible que las zonas no contengan las mismas versiones de los objetos en un momento dado, pero, con el tiempo, se convertirán en equivalentes si no se realizan cambios adicionales. A diferencia de la replicación de volúmenes, los contenedores replicados se pueden escribir durante las particiones de zona. Cada escritura en un objeto genera una versión diferente, y la versión más reciente de cualquiera de las zonas será el estado final una vez que se haya restaurado la conectividad.

  1. Verifica que tu operador de infraestructura (IO) haya creado el recurso personalizado BucketLocationConfig, que es necesario para la replicación asíncrona entre zonas del almacenamiento de objetos. Este recurso debe implementarse en el servidor de la API global raíz.

  2. Crea el recurso personalizado de doble zona Bucket:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: object.global.gdc.goog/v1
kind: Bucket
metadata:
  name: BUCKET_NAME
  namespace: PROJECT
spec:
  location: LOCATION_NAME
  description: Sample DZ Bucket
  storageClass: Standard
EOF

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: el archivo kubeconfig del servidor de la API global.
    • BUCKET_NAME: el nombre del segmento de almacenamiento.
    • PROJECT: el nombre del proyecto en el que se encuentra el cubo.
    • LOCATION_NAME: el lugar físico donde se encuentran los datos de los objetos del segmento. Debe corresponderse con el nombre de un recurso BucketLocation. Para consultar el servidor de la API global de tu organización y obtener una lista de recursos BucketLocation disponibles, ejecuta kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations. Si no hay recursos BucketLocation, ponte en contacto con tu IO para verificar que ha habilitado la replicación asíncrona.

Configurar la replicación de almacenamiento en bloque asíncrona entre zonas

El almacenamiento en bloques replicado proporciona volúmenes (PVs) replicados de forma asíncrona, que mantienen la equivalencia de bloques entre los volúmenes primario y secundario. Debido a la naturaleza asíncrona, el volumen secundario refleja el estado de la zona principal en algún momento del pasado (RPO distinto de cero). El volumen secundario no se puede montar mientras siga siendo el destino de la replicación, por lo que se requiere una intervención manual para finalizar la relación y permitir que se produzcan escrituras.

Debes implementar un recurso personalizado VolumeReplicationRelationship en el servidor de APIs global para crear datos replicados que estén disponibles para la conmutación por error si los datos de la zona de origen dejan de estar disponibles.

Antes de empezar, comprueba que tu operador de infraestructura (IO) haya creado y configurado los recursos personalizados StorageClusterPeering y StorageVirtualMachinePeering para permitir la replicación del almacenamiento en bloque entre zonas. Este recurso debe implementarse en el servidor de la API global raíz.

gdcloud

  1. Define la relación de volumen de la réplica asíncrona entre la zona principal y las secundarias:

    gdcloud compute disks start-async-replication PRIMARY_DISK_NAME \
    --project PROJECT \
    --zone PRIMARY_ZONE \
    --secondary-disk SECONDARY_DISK_NAME \
    --secondary-zone SECONDARY_ZONE

    Haz los cambios siguientes:

    • PRIMARY_DISK_NAME: el nombre del disco de origen que se va a replicar.
    • PROJECT: el proyecto de GDC del disco principal.
    • PRIMARY_ZONE: la zona en la que reside el disco principal.
    • SECONDARY_DISK_NAME: el nombre del disco de destino en el que se va a replicar.
    • SECONDARY_ZONE: la zona en la que debe estar el disco secundario.

  2. Crea un recurso personalizado VolumeFailover en la zona de destino, que detiene la replicación en la zona de destino si la zona de origen no está disponible por cualquier motivo:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: REPL_NAME
EOF

    Haz los cambios siguientes:

    • MANAGEMENT_API_SERVER: el archivo kubeconfig del servidor de la API Management.
    • FAILOVER_NAME: el nombre de la conmutación por error.
    • PROJECT: el proyecto en el que reside la infraestructura de almacenamiento.
    • REPL_NAME: el nombre de la relación de replicación de volúmenes.

    Para obtener más información sobre cómo gestionar la replicación asíncrona de cargas de trabajo de máquinas virtuales, consulta Replicar volúmenes de forma asíncrona.

API

  1. Crea un archivo YAML de recurso personalizado VolumeReplicationRelationship y despliega en el servidor de la API global:

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: storage.global.gdc.goog/v1
kind: VolumeReplicationRelationship
metadata:
  name: VRR_NAME
  namespace: PROJECT
spec:
  source:
    virtualMachineDisk:
      virtualMachineDiskRef: PRIMARY_DISK_NAME
    zoneRef: PRIMARY_ZONE
  destination:
    volumeOverrideName: SECONDARY_DISK_NAME
    zoneRef: SECONDARY_ZONE
EOF

    Haz los cambios siguientes:

    • GLOBAL_API_SERVER: el archivo kubeconfig del servidor de la API de gestión global.
    • VRR_NAME: el nombre de la relación de replicación de volúmenes. Se debe usar el mismo nombre al detener la replicación asíncrona.
    • PROJECT: el proyecto de GDC del disco principal.
    • PRIMARY_DISK_NAME: el nombre del disco de origen que se va a replicar.
    • PRIMARY_ZONE: la zona en la que reside el disco principal.
    • SECONDARY_DISK_NAME: el nombre del disco de destino en el que se va a replicar.
    • SECONDARY_ZONE: la zona en la que debe residir el disco secundario.

  2. Crea un recurso personalizado VolumeFailover en la zona de destino, que detiene la replicación en la zona de destino si la zona de origen no está disponible por cualquier motivo:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: storage.gdc.goog/v1
kind: VolumeFailover
metadata:
  name: FAILOVER_NAME
  namespace: PROJECT
spec:
  volumeReplicationRelationshipRef: REPL_NAME
EOF

    Haz los cambios siguientes:

    • MANAGEMENT_API_SERVER: el archivo kubeconfig del servidor de la API Management.
    • FAILOVER_NAME: el nombre de la conmutación por error.
    • PROJECT: el proyecto en el que reside la infraestructura de almacenamiento.
    • REPL_NAME: el nombre de la relación de replicación de volúmenes.

Para obtener más información sobre cómo gestionar la replicación asíncrona de cargas de trabajo de máquinas virtuales, consulta Replicar volúmenes de forma asíncrona.

Siguientes pasos