Implementa una aplicación de VM con alta disponibilidad

En esta página, se proporciona la estrategia de implementación recomendada para compilar una aplicación de máquina virtual (VM) sólida y de alta disponibilidad (HA) en Google Distributed Cloud (GDC) con aislamiento de aire. Debes implementar 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 tiempo de inactividad inesperado o desastre local.

Esta página está dirigida a los desarrolladores que forman parte del grupo de operadores de aplicaciones y que son responsables de crear cargas de trabajo de aplicaciones para su organización. Para obtener más información, consulta Audiences for GDC air-gapped documentation.

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 cargas global.
  • Configura la replicación de almacenamiento asíncrona con almacenamiento de objetos o de bloques.

Antes de comenzar

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

  • Pídele al administrador de IAM de tu organización que te otorgue los siguientes roles:

    • Los roles de VM para crear y administrar cargas de trabajo de VM
    • Los roles de administrador de balanceador de cargas (load-balancer-admin) y administrador de balanceador de cargas global (global-load-balancer-admin) Debes tener estos roles para crear y administrar balanceadores de cargas.
    • El rol de 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 administrar políticas de red del proyecto en todas las zonas.
    • El rol de administrador global de replicación de volúmenes (app-volume-replication-admin-global) para administrar la relación de replicación de volúmenes para los recursos de almacenamiento en bloque.
    • Los roles de administrador de objetos del bucket del proyecto (project-bucket-object-admin) y administrador del bucket del proyecto (project-bucket-admin) para crear y administrar buckets de almacenamiento

    Consulta las descripciones de los roles para obtener más información.

  • Instala y configura la CLI de gdcloud y configura tus contextos zonales y globales. Consulta Administra recursos en diferentes zonas para obtener más información.

  • Instala y configura la CLI de kubectl con los archivos kubeconfig adecuados establecidos para el servidor de la API global y el servidor de la API de administración. Consulta Cómo generar manualmente un archivo kubeconfig para obtener más información.

Crea 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 conectará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 Crea e inicia una VM.

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

Console

  1. En el menú de navegación, selecciona Virtual Machines > Instances.
  2. Haz clic en Crear instancia.
  3. En el campo Nombre, especifica un nombre para la VM.
  4. Selecciona la zona en la que se creará la VM.
  5. Haz clic en Agregar etiquetas para asignar etiquetas a la VM y organizar tus instancias de VM.
  6. Selecciona la configuración de la máquina que se usará para la VM. Verifica que el tipo de máquina se alinee con tu carga de trabajo, según tus requisitos.
  7. Haz clic en Siguiente.
  8. Habilita el acceso externo para tu instancia de VM.
  9. Haz clic en Siguiente.
  10. Selecciona Agregar disco nuevo.
  11. Asigna un nombre al disco de la VM.
  12. Configura el tamaño del disco y los parámetros de configuración de la conexión.
  13. Haz clic en Guardar.
  14. Haz clic en Crear para crear la instancia de VM.
  15. Repite los pasos anteriores para cada zona de tu universo de GDC. Asegúrate de que haya una instancia de VM en cada zona que desees para tu estrategia de HA.

gdcloud

  1. Accede a la zona en la que deseas 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

    Reemplaza lo siguiente:

    • VM_NAME: es el nombre de la VM nueva. El nombre solo debe contener caracteres alfanuméricos y guiones, y no debe tener más de 53 caracteres.
    • MACHINE_TYPE: Es el tipo de máquina predefinido para la VM nueva. Para seleccionar un tipo de máquina disponible, ejecuta gdcloud compute machine-types list.
    • BOOT_DISK_IMAGE_NAME: Es el nombre de la imagen que se usará para el disco de arranque de la VM nueva.
    • BOOT_DISK_SIZE: Es 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 borra automáticamente cuando se borra la instancia de VM.

  3. Repite los pasos anteriores para cada zona de tu universo de GDC. Asegúrate de que haya una instancia de VM en cada zona que desees para tu estrategia de HA.

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

    Reemplaza lo siguiente:

    • MANAGEMENT_API_SERVER: Es el archivo kubeconfig del servidor de la API de Management para la zona en la que se creará la instancia de VM. Si aún no generaste un archivo kubeconfig para el servidor de la API de Management, consulta Cómo generar manualmente un archivo kubeconfig para obtener más detalles.
    • VM_BOOT_DISK_NAME: Es el nombre del nuevo disco de arranque de la VM.
    • PROJECT: Es el proyecto de GDC en el que se creará la VM.
    • BOOT_DISK_IMAGE_NAME: Es el nombre de la imagen que se usará para el disco de arranque de la VM nueva.
    • BOOT_DISK_SIZE: Es 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: es el nombre de la VM nueva. El nombre solo debe contener caracteres alfanuméricos y guiones, y no debe tener más de 53 caracteres.
    • MACHINE_TYPE: Es el tipo de máquina predefinido para la VM nueva. 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 borra automáticamente cuando se borra la instancia de VM.

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

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

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

  3. Repite los pasos anteriores para cada zona de tu universo de GDC. Asegúrate de que haya una instancia de VM en cada zona que desees para tu estrategia de HA.

Configura los balanceadores de cargas

Para distribuir el tráfico entre tus VMs en diferentes zonas, crea balanceadores de cargas. Tienes la opción de crear balanceadores de cargas externos (ELB) y balanceadores de cargas internos (ILB), los cuales se pueden configurar de forma zonal o global. En este ejemplo, configura un ILB global y un ELB global para tu aplicación de VM.

Crea un balanceador de cargas interno global

Los balanceadores de cargas internos (ILB) 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 extremo fuera de la organización.

Completa los siguientes pasos para crear un ILB global para tus cargas de trabajo de VM.

gdcloud

Crea un ILB que se dirija a cargas de trabajo de VM con la CLI de gcloud.

Este ILB segmenta todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend. El recurso personalizado Backend debe tener un alcance limitado a una zona.

Para crear un ILB con gcloud CLI, sigue estos pasos:

  1. Crea un recurso Backend zonal en cada zona en la que se ejecutan tus VMs para definir el extremo del ILB:

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

    Reemplaza lo siguiente:

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

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

  2. Define una verificación de 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

    Reemplaza lo siguiente:

    • HEALTH_CHECK_NAME: Es el nombre del recurso de verificación de estado, como my-health-check.
    • CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo hasta el inicio del siguiente. El valor predeterminado es 5. Este campo es opcional.
    • HEALTHY_THRESHOLD: Es el tiempo que se debe esperar antes de declarar la falla. El valor predeterminado es 5. Este campo es opcional.
    • TIMEOUT: Es la cantidad de tiempo en segundos que se espera antes de declarar una falla. El valor predeterminado es 5. Este campo es opcional.
    • UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado. El valor predeterminado es 2. Este campo es opcional.
    • PORT: Es el puerto en el que se realiza la verificació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

    Reemplaza lo siguiente:

    • BACKEND_SERVICE_NAME: Es el nombre del servicio de backend.
    • PROJECT: nombre del proyecto.
    • TARGET_PORTS: Es una lista separada por comas de los puertos de destino que traduce este servicio de backend, en la que cada puerto de destino especifica el protocolo, el puerto en la regla de reenvío y el puerto en la instancia de backend. Puedes 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: Es el nombre del recurso de verificación de estado. Este campo es opcional.

  4. Agrega el recurso BackendService al recurso Backend creado anteriormente en cada zona:

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

    Reemplaza lo siguiente:

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

    Completa este paso para cada backend zonal que creaste 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

    Reemplaza lo siguiente:

    • FORWARDING_RULE_INTERNAL_NAME: Es el nombre de la regla de reenvío.
    • CIDR: Es el CIDR que se usará para tu regla de reenvío. Este campo es opcional. Si no se especifica, 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 Administra subredes.
    • PROTOCOL_PORT: Es 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 VIP en el puerto especificado en el campo de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

    Reemplaza lo siguiente:

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

API

Crea un ILB que tenga como destino cargas de trabajo de VM con la API de KRM. Este ILB segmenta todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend. Para crear un ILB global con la API de KRM, sigue estos pasos:

  1. Crea un recurso Backend para definir los extremos del ILB. Crea recursos de Backend para cada zona en la que se colocan las cargas de trabajo de VM:

    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

    Reemplaza lo siguiente:

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

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

  2. Define una verificación de 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de API global. Para obtener más información, consulta Cómo cambiar a un contexto global.
    • PROJECT: nombre del proyecto.
    • HEALTH_CHECK_NAME: Es el nombre del recurso de verificación de estado, como my-health-check.
    • PORT: Es el puerto en el que se realizará la verificación de estado. El valor predeterminado es 80.
    • TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5.
    • CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo hasta el inicio del siguiente. El valor predeterminado es 5.
    • HEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben aprobarse para que el extremo se considere en buen estado. El valor predeterminado es 2.
    • UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado. El valor predeterminado es 2.

  3. Crea un objeto BackendService con el recurso Backend creado anteriormente. Asegúrate de incluir 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de API global.
    • PROJECT: nombre del proyecto.
    • BACKEND_SERVICE_NAME: Es el nombre elegido para tu recurso BackendService.
    • HEALTH_CHECK_NAME: Es el nombre del recurso HealthCheck que creaste anteriormente.
    • BACKEND_NAME: Es el nombre del recurso Backend zonal.

    • ZONE: Es la zona en la que reside el recurso Backend. Puedes especificar varios servidores de backend 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 el recurso BackendService. Si usas este objeto, proporciona valores para lo siguiente:

    • PORT: Es el puerto que expone el servicio.

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

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

      Un ejemplo para targetPorts podría verse de la siguiente manera:

      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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de API global.
    • PROJECT: nombre del proyecto.
    • FORWARDING_RULE_INTERNAL_NAME: Es el nombre elegido para tu recurso ForwardingRuleInternal.
    • CIDR: Es el CIDR que se usará para tu regla de reenvío. Este campo es opcional. Si no se especifica, 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 Administra subredes.
    • PORT: Es el puerto que se expondrá en la regla de reenvío. Usa el campo ports para especificar un array de puertos de L4 para los que los paquetes se reenvían a los backends 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: Es el protocolo que se usará para la regla de reenvío, como TCP. Una entrada en el array ports debe verse de la siguiente manera:

      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. Recupera el VIP:

      kubectl get forwardingruleinternal -n PROJECT

      El resultado luce de la siguiente manera:

      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 VIP en el puerto especificado en el campo de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Reemplaza lo siguiente:

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

Crea un balanceador de cargas externo global

Los balanceadores de cargas externos (ELB) exponen servicios para acceder desde fuera de la organización desde un grupo de direcciones IP asignadas a la organización desde el grupo de direcciones IP externas de instancias más grande.

Completa los siguientes pasos para crear un ELB global para tus cargas de trabajo de VM.

gdcloud

Usa la CLI de gcloud para crear un ELB global que apunte 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 alcance limitado a una zona.

  1. Para que los servicios de ELB funcionen, debes configurar y aplicar tu propia política de transferencia de datos ProjectNetworkPolicy personalizada 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 balanceador de cargas en sí. Los ELB exponen las cargas de trabajo a la red de tu cliente, 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de API global. Si aún no generaste un archivo kubeconfig para el servidor de la API global, consulta Cómo generar manualmente un archivo kubeconfig para obtener más detalles.
    • PROJECT: nombre del proyecto.
    • CIDR: Es el CIDR externo desde el que se debe acceder al ELB. Esta política es necesaria, ya que el balanceador de cargas externo usa el retorno directo del servidor (DSR), que conserva la dirección IP externa de origen y omite el balanceador de cargas en la ruta de retorno. Para obtener más información, consulta Crea una regla de firewall de entrada global para el tráfico entre organizaciones.
    • PORT: Es el puerto de backend en las VMs detrás del balanceador de cargas. 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 dentro de los proyectos acceso al rango de CIDR especificado.

  2. Crea un recurso Backend en cada zona para definir el extremo del ELB:

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

    Reemplaza lo siguiente:

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

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

  3. Define una verificación de 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

    Reemplaza lo siguiente:

    • HEALTH_CHECK_NAME: Es el nombre del recurso de verificación de estado, como my-health-check.
    • CHECK_INTERVAL: Es la cantidad de tiempo en segundos desde el inicio de un sondeo hasta el inicio del siguiente. El valor predeterminado es 5. Este campo es opcional.
    • HEALTHY_THRESHOLD: Es el tiempo que se debe esperar antes de declarar la falla. El valor predeterminado es 5. Este campo es opcional.
    • TIMEOUT: Es la cantidad de tiempo en segundos que se debe esperar antes de declarar una falla. El valor predeterminado es 5. Este campo es opcional.
    • UNHEALTHY_THRESHOLD: Es la cantidad de sondeos secuenciales que deben fallar para que el extremo se considere en mal estado. El valor predeterminado es 2. Este campo es opcional.
    • PORT: Es el puerto en el que se realizará la verificación de 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

    Reemplaza lo siguiente:

    • BACKEND_SERVICE_NAME: Es el nombre elegido para este servicio de backend.
    • PROJECT: nombre del proyecto.
    • TARGET_PORTS: Es una lista separada por comas de los puertos de destino que traduce este servicio de backend, en la que cada puerto de destino especifica el protocolo, el puerto en la regla de reenvío y el puerto en la instancia de backend. Puedes 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: Es el nombre del recurso de verificación de estado. Este campo es opcional.

  5. Agrega el recurso BackendService global al recurso Backend zonal creado anteriormente:

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

    Completa este paso para cada backend zonal que creaste anteriormente.

  6. Crea un recurso ForwardingRule externo que defina la VIP 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

    Reemplaza lo siguiente:

    • FORWARDING_RULE_EXTERNAL_NAME: Es el nombre de la regla de reenvío.
    • CIDR: Es el CIDR que se usará para tu regla de reenvío. Este campo es opcional. Si no se especifica, 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 Administra subredes.
    • PROTOCOL_PORT: Es 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.
    • PROJECT: nombre del 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 VIP en el puerto especificado en el campo PROTOCOL_PORT de la regla de reenvío:

      curl http://FORWARDING_RULE_VIP:PORT

      Reemplaza lo siguiente:

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

API

Crea un ELB que tenga como objetivo las cargas de trabajo de la VM con la API de KRM. Este ELB segmenta todas las cargas de trabajo del proyecto que coinciden con la etiqueta definida en el objeto Backend. Para crear un ELB zonal con la API de KRM, sigue estos pasos:

  1. Para que los servicios de ELB funcionen, debes configurar y aplicar tu propia política de transferencia de datos ProjectNetworkPolicy personalizada 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 balanceador de cargas en sí. Los ELB exponen las cargas de trabajo a la red de tu cliente, 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de API global. Si aún no generaste un archivo kubeconfig para el servidor de la API global, consulta Cómo generar manualmente un archivo kubeconfig para obtener más detalles.
    • PROJECT: nombre del proyecto.
    • CIDR: Es el CIDR externo desde el que se debe acceder al ELB. Esta política es necesaria, ya que el balanceador de cargas externo usa el retorno directo del servidor (DSR), que conserva la dirección IP externa de origen y omite el balanceador de cargas en la ruta de retorno. Para obtener más información, consulta Crea una regla de firewall de entrada global para el tráfico entre organizaciones.
    • PORT: Es el puerto de backend en las VMs detrás del balanceador de cargas. 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 extremos del ELB. Crea recursos de Backend para cada zona en la que se colocan 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

    Reemplaza lo siguiente:

    • MANAGEMENT_API_SERVER: Es la ruta de acceso de kubeconfig del servidor de la API de administración zonal. Si aún no generaste un archivo kubeconfig para el servidor de la API en tu zona de destino, consulta Cómo generar manualmente un archivo kubeconfig para obtener más detalles.
    • PROJECT: nombre del proyecto.
    • BACKEND_NAME: El nombre del recurso Backend.

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

  3. Define una verificación de 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

    Reemplaza lo siguiente:

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

    Dado que se trata de un ELB global, crea la verificación de estado en la API global.

  4. Crea un objeto BackendService con el recurso Backend 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

    Reemplaza lo siguiente:

    • BACKEND_SERVICE_NAME: Es el nombre elegido para tu recurso BackendService.
    • HEALTH_CHECK_NAME: Es el nombre del recurso HealthCheck que creaste anteriormente. No incluyas este campo si configuras un ELB para cargas de trabajo de Pod.
    • ZONE: Es la zona en la que reside el recurso Backend. Puedes especificar varios backends 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 VIP 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

    Reemplaza lo siguiente:

    • FORWARDING_RULE_EXTERNAL_NAME: Es el nombre elegido para tu recurso ForwardingRuleExternal.
    • CIDR: Es el CIDR que se usará para tu regla de reenvío. Este campo es opcional. Si no se especifica, 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 Administra subredes.
    • PORT: Es el puerto que se expondrá en la regla de reenvío. Usa el campo ports para especificar un array de puertos de L4 para los que los paquetes se reenvían a los backends 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: Es el protocolo que se usará para la regla de reenvío, como TCP. Una entrada en el array ports debe verse de la siguiente manera:
    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. Recupera la VIP del proyecto:

      kubectl get forwardingruleexternal -n PROJECT

      El resultado luce de la siguiente manera:

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

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

      curl http://FORWARDING_RULE_VIP:PORT

      Reemplaza FORWARDING_RULE_VIP:PORT por la VIP y el puerto de la regla de reenvío, como 192.0.2.0:80.

Configura la replicación de almacenamiento asíncrona

Los universos multizonales de GDC ofrecen el uso de recursos de almacenamiento replicados, como volúmenes y buckets, en modo asíncrono para situaciones de recuperación ante desastres. Estas opciones de recursos de almacenamiento proporcionan replicación asíncrona de datos entre dos zonas cualesquiera de la misma región. La replicación asíncrona se produce en segundo plano y proporciona un objetivo de punto de recuperación (RPO) bajo, pero no nulo, en caso de desastre. Todos los datos replicados están en línea y son accesibles de inmediato, pero es posible que se requiera un procedimiento manual de conmutación por error para habilitar la escritura en la zona secundaria.

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

Crea un bucket de doble zona para el almacenamiento de objetos

Los datos de almacenamiento de objetos se escriben en un solo bucket cuyos datos se almacenan en ambas zonas. Debido a que los datos se copian de forma asíncrona entre las zonas, es posible que estas no contengan las mismas versiones de objetos en ningún momento, pero, con el tiempo, se volverán equivalentes si no se realizan cambios adicionales. A diferencia de la replicación de volúmenes, los buckets replicados se pueden escribir durante las particiones de zona. Cada escritura en un objeto produce una versión diferente, y la versión más reciente en cualquiera de las zonas será el estado final después de que se restablezca 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 en zonas para el almacenamiento de objetos. Este recurso debe implementarse en el servidor raíz de la API global.

  2. Crea el recurso personalizado Bucket de doble zona:

    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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es el archivo kubeconfig para el servidor de la API global.
    • BUCKET_NAME: Es el nombre del bucket de almacenamiento.
    • PROJECT: Es el nombre del proyecto en el que reside el bucket.
    • LOCATION_NAME: Es el lugar físico donde residen los datos de objetos del bucket. Debe asignarse al nombre de un recurso BucketLocation existente. Para consultar el servidor de la API global de tu organización y obtener una lista de los recursos BucketLocation disponibles, ejecuta kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations. Si no hay recursos de BucketLocation, comunícate con tu IO para verificar que haya habilitado la replicación asíncrona.

Configura la replicación asíncrona del almacenamiento en bloque en diferentes zonas

El almacenamiento de bloques replicado proporciona volúmenes replicados de forma asíncrona (PV), que mantienen la equivalencia de bloques entre los volúmenes principal 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 activar mientras siga siendo el destino de la replicación, lo que requiere intervención manual para finalizar la relación y permitir que se produzcan escrituras.

Debes implementar un recurso personalizado VolumeReplicationRelationship en el servidor de la API 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 comenzar, verifica 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 en todas las zonas. Este recurso se debe implementar en el servidor de la API global raíz.

gdcloud

  1. Establece la relación de replicación asíncrona del volumen entre la zona principal y las zonas secundarias:

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

    Reemplaza lo siguiente:

    • PRIMARY_DISK_NAME: Es el nombre del disco de origen que se replica.
    • PROJECT: Es el proyecto de GDC del disco principal.
    • PRIMARY_ZONE: Es la zona en la que reside el disco principal.
    • SECONDARY_DISK_NAME: Es el nombre del disco de destino en el que se replicará.
    • SECONDARY_ZONE: Es 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 algún 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

    Reemplaza lo siguiente:

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

    Para obtener más información sobre cómo administrar la replicación asíncrona para cargas de trabajo de VM, consulta Cómo replicar volúmenes de forma asíncrona.

API

  1. Crea un archivo YAML de recurso personalizado VolumeReplicationRelationship y despliégalo 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

    Reemplaza lo siguiente:

    • GLOBAL_API_SERVER: Es el archivo kubeconfig para el servidor de la API de administración global.
    • VRR_NAME: Es el nombre de la relación de replicación del volumen. Se debe usar el mismo nombre cuando se detiene la replicación asíncrona.
    • PROJECT: Es el proyecto de GDC del disco principal.
    • PRIMARY_DISK_NAME: Es el nombre del disco de origen que se replica.
    • PRIMARY_ZONE: Es la zona en la que reside el disco principal.
    • SECONDARY_DISK_NAME: Es el nombre del disco de destino en el que se replicará.
    • SECONDARY_ZONE: Es 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 algún 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

    Reemplaza lo siguiente:

    • MANAGEMENT_API_SERVER: Es el archivo kubeconfig para el servidor de la API de administración.
    • FAILOVER_NAME: Es el nombre de la conmutación por error.
    • PROJECT: Es el proyecto en el que reside la infraestructura de almacenamiento.
    • REPL_NAME: Es el nombre de la relación de replicación del volumen.

Para obtener más información sobre cómo administrar la replicación asíncrona para cargas de trabajo de VM, consulta Cómo replicar volúmenes de forma asíncrona.

¿Qué sigue?