Implemente uma aplicação de VM altamente disponível

Esta página fornece a estratégia de implementação recomendada para criar uma aplicação de máquina virtual (VM) robusta e de alta disponibilidade (HA) no Google Distributed Cloud (GDC) air-gapped. Tem de implementar a aplicação de VM em várias zonas do GDC e configurar a replicação de armazenamento assíncrona para que a aplicação e os respetivos dados sejam recuperáveis em caso de tempo de inatividade inesperado ou desastre local.

Esta página destina-se a programadores no grupo de operadores de aplicações, que são responsáveis por criar cargas de trabalho de aplicações para a respetiva organização. Para mais informações, consulte a documentação sobre públicos-alvo para GDC com isolamento de ar.

Objetivos

  • Crie uma instância de VM com discos de arranque anexados em duas ou mais zonas no seu universo do GDC.
  • Configure o balanceamento de carga global.
  • Configure a replicação de armazenamento assíncrona através do armazenamento em blocos ou do armazenamento de objetos.

Antes de começar

  • Verifique se está a trabalhar num universo do GDC com várias zonas disponíveis. Execute gdcloud zones list para listar as zonas disponíveis no seu universo. Para mais informações, consulte o artigo Liste as zonas num universo.

  • Peça ao administrador de IAM da organização para lhe conceder as seguintes funções:

    • As funções de VM para criar e gerir cargas de trabalho de VM.
    • As funções de administrador do equilibrador de carga (load-balancer-admin) e administrador do equilibrador de carga global (global-load-balancer-admin). Tem de ter estas funções para criar e gerir balanceadores de carga.
    • A função de administrador global da replicação de volumes (app-volume-replication-admin-global). Tem de ter esta função para administrar a replicação de volumes.
    • A função de administrador global do PNP (global-project-networkpolicy-admin). Tem de ter esta função para criar e gerir políticas de rede de projetos em várias zonas.
    • A função de administrador global da replicação de volumes (app-volume-replication-admin-global) para administrar a relação de replicação de volumes para recursos de armazenamento em blocos.
    • A função de administrador de objetos do contentor do projeto (project-bucket-object-admin) e administrador do contentor do projeto (project-bucket-admin) para criar e gerir contentores de armazenamento.

    Consulte as descrições das funções para mais informações.

  • Instale e configure a CLI gcloud e configure os contextos zonais e globais. Consulte o artigo Faça a gestão de recursos em várias zonas para mais informações.

  • Instale e configure a CLI kubectl com os ficheiros kubeconfig adequados definidos para o servidor de API global e o servidor de API de gestão. Consulte o artigo Gere manualmente o ficheiro kubeconfig para mais informações.

Crie uma instância de VM em várias zonas

Uma instância de VM é um recurso zonal, pelo que tem de criar uma VM separadamente em cada zona. Para este exemplo, vai criar uma instância de VM com uma imagem do SO fornecida pelo GDC e anexar um disco de arranque à VM. Para mais informações sobre como criar instâncias de VMs, bem como usar imagens personalizadas, consulte o artigo Crie e inicie uma VM.

Por predefinição, todos os projetos do GDC podem criar VMs a partir de imagens de SO fornecidas pelo GDC.

Consola

  1. No menu de navegação, selecione Máquinas virtuais > Instâncias.
  2. Clique em Criar instância.
  3. No campo Nome, especifique um nome para a VM.
  4. Selecione a zona na qual quer criar a VM.
  5. Clique em Adicionar etiquetas para atribuir etiquetas à VM e ajudar a organizar as instâncias de VM.
  6. Selecione a configuração da máquina a usar para a VM. Verifique se o tipo de máquina está alinhado com a sua carga de trabalho, consoante os seus requisitos.
  7. Clicar em Seguinte.
  8. Ative o acesso externo para a sua instância de VM.
  9. Clicar em Seguinte.
  10. Selecione Adicionar novo disco.
  11. Atribua um nome ao disco da VM.
  12. Configure o tamanho do disco e as definições de anexos.
  13. Clique em Guardar.
  14. Clique em Criar para criar a instância de VM.
  15. Repita os passos anteriores para cada zona no seu universo do GDC. Certifique-se de que existe uma instância de VM em cada zona que quer para a sua estratégia de HA.

gdcloud

  1. Inicie sessão na zona na qual quer alojar a sua instância de VM:

    gdcloud config set core/zone ZONE

  2. Crie a instância de VM na zona com uma imagem fornecida pelo 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

    Substitua o seguinte:

    • VM_NAME: o nome da nova VM. O nome só pode conter carateres alfanuméricos e travessões, e não pode ter mais de 53 carateres.
    • MACHINE_TYPE: o tipo de máquina predefinido para a nova VM. Para selecionar um tipo de máquina disponível, execute gdcloud compute machine-types list.
    • BOOT_DISK_IMAGE_NAME: o nome da imagem a usar para o novo disco de arranque da VM.
    • BOOT_DISK_SIZE: o tamanho do disco de arranque, como 20GB. Este valor tem de ser sempre igual ou superior ao minimumDiskSize da imagem do disco de arranque.
    • NO_BOOT_DISK_AUTO_DELETE: se o disco de arranque é eliminado automaticamente quando a instância de VM é eliminada.

  3. Repita os passos anteriores para cada zona no seu universo do GDC. Certifique-se de que existe uma instância de VM em todas as zonas que quer para a sua estratégia de HA.

API

  1. Crie a instância de VM na zona com uma imagem fornecida pelo 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

    Substitua o seguinte:

    • MANAGEMENT_API_SERVER: o ficheiro kubeconfig do servidor da API Management para a zona na qual criar a instância de VM. Se ainda não gerou um ficheiro kubeconfig para o servidor da API Management, consulte o artigo Gerar manualmente o ficheiro kubeconfig para obter detalhes.
    • VM_BOOT_DISK_NAME: o nome do novo disco de arranque da VM.
    • PROJECT: o projeto do GDC para criar a VM.
    • BOOT_DISK_IMAGE_NAME: o nome da imagem a usar para o novo disco de arranque da VM.
    • BOOT_DISK_SIZE: o tamanho do disco de arranque, como 20Gi. Este valor tem de ser sempre igual ou superior ao minimumDiskSize da imagem do disco de arranque.
    • VM_NAME: o nome da nova VM. O nome só pode conter carateres alfanuméricos e travessões, e não pode ter mais de 53 carateres.
    • MACHINE_TYPE: o tipo de máquina predefinido para a nova VM. Para selecionar um tipo de máquina disponível, execute gdcloud compute machine-types list.
    • BOOT_DISK_AUTO_DELETE: indica se o disco de arranque é eliminado automaticamente quando a instância de VM é eliminada.

  2. Verifique se a VM está disponível e aguarde que a VM apresente o estado Running. O estado Running não indica que o SO está totalmente pronto e acessível.

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

    Substitua VM_NAME e PROJECT pelo nome e projeto da VM.

  3. Repita os passos anteriores para cada zona no seu universo do GDC. Certifique-se de que existe uma instância de VM em todas as zonas que quer para a sua estratégia de HA.

Configure balanceadores de carga

Para distribuir o tráfego entre as suas VMs em diferentes zonas, crie balanceadores de carga. Tem a opção de criar balanceadores de carga externos (ELB) e balanceadores de carga internos (ILB), que podem ser configurados ao nível da zona ou globalmente. Para este exemplo, configure um ILB global e um ELB global para a sua aplicação de VM.

Crie um balanceador de carga interno global

Os balanceadores de carga internos (ILB) expõem serviços na organização a partir de um conjunto de endereços IP internos atribuídos à organização. Um serviço ILB nunca está acessível a partir de nenhum ponto final fora da organização.

Conclua os passos seguintes para criar um ILB global para as suas cargas de trabalho de VMs.

gdcloud

Crie um ILB que segmenta cargas de trabalho de VMs através da CLI gdcloud.

Este ILB segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend. O recurso personalizado Backend tem de estar no âmbito de uma zona.

Para criar um ILB através da CLI gdcloud, siga estes passos:

  1. Crie um recurso Backend zonal em cada zona onde as suas VMs estão a ser executadas para definir o ponto final do ILB:

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

    Substitua o seguinte:

    • BACKEND_NAME: o nome escolhido para o recurso de back-end, como my-backend.
    • LABELS: o seletor que define que pontos finais entre VMs usar para este recurso de back-end, como app=web.
    • PROJECT: o nome do seu projeto.
    • ZONE: a zona a usar para esta invocação. Para predefinir a flag de zona para todos os comandos que a requerem, execute gdcloud config set core/zone ZONE. O indicador de zona está disponível apenas em ambientes com várias zonas. Este campo é opcional.

    Repita este passo para cada zona no seu universo do GDC.

  2. Defina uma verificação de funcionamento global para o 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

    Substitua o seguinte:

    • HEALTH_CHECK_NAME: o nome do recurso de verificação de estado, como my-health-check.
    • CHECK_INTERVAL: a quantidade de tempo em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5. Este campo é opcional.
    • HEALTHY_THRESHOLD: o tempo de espera antes de reclamar a falha. O valor predefinido é 5. Este campo é opcional.
    • TIMEOUT: o período de tempo em segundos a aguardar antes de declarar a falha. O valor predefinido é 5. Este campo é opcional.
    • UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2. Este campo é opcional.
    • PORT: a porta na qual a verificação do estado é realizada. O valor predefinido é 80. Este campo é opcional.

  3. Crie um recurso BackendService global:

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

    Substitua o seguinte:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end.
    • PROJECT: o nome do seu projeto.
    • TARGET_PORTS: uma lista separada por vírgulas das portas de destino que este serviço de back-end traduz, em que cada porta de destino especifica o protocolo, a porta na regra de encaminhamento e a porta na instância de back-end. Pode especificar várias portas de destino. Este campo tem de estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
    • HEALTH_CHECK_NAME: o nome do recurso de verificação de estado. Este campo é opcional.

  4. Adicione o recurso BackendService ao recurso Backend criado anteriormente em cada zona:

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

    Substitua o seguinte:

    • BACKEND_SERVICE_NAME: o nome do serviço de back-end global.
    • ZONE: a zona do back-end.
    • BACKEND_NAME: o nome do back-end zonal.
    • PROJECT: o nome do seu projeto.

    Conclua este passo para cada back-end zonal que criou anteriormente.

  5. Crie um recurso ForwardingRule interno que defina o endereço IP virtual (VIP) no qual o serviço está disponível:

    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

    Substitua o seguinte:

    • FORWARDING_RULE_INTERNAL_NAME: o nome da regra de encaminhamento.
    • CIDR: o CIDR a usar para a regra de encaminhamento. Este campo é opcional. Se não for especificado, é reservado automaticamente um IPv4/32 CIDR do conjunto de endereços IP global. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede global. Para mais informações sobre os Subnet recursos, consulte o artigo Faça a gestão das sub-redes.
    • PROTOCOL_PORT: o protocolo e a porta a expor na regra de encaminhamento. Este campo tem de estar no formato ip-protocol=TCP:80. A porta exposta tem de ser a mesma que a aplicação real está a expor dentro da VM.

  6. Para validar o ILB configurado, confirme a condição Ready em cada um dos objetos criados. Valide o tráfego com um pedido curl para o VIP:

    1. Para obter o VIP atribuído, descreva a regra de encaminhamento:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. Valide o tráfego com um pedido curl para o VIP na porta especificada no campo na regra de encaminhamento:

      curl http://FORWARDING_RULE_VIP:PORT

    Substitua o seguinte:

    • FORWARDING_RULE_VIP: o VIP da regra de encaminhamento.
    • PORT: o número da porta da regra de encaminhamento.

API

Crie um ILB que segmenta cargas de trabalho de VMs através da API KRM. Este ILB segmenta todos os cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend. Para criar um ILB global através da API KRM, siga estes passos:

  1. Crie um recurso Backend para definir os pontos finais do ILB. Crie recursos Backend para cada zona em que as cargas de trabalho de VM estão localizadas:

    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

    Substitua o seguinte:

    • MANAGEMENT_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor da API Management zonal. Para mais informações, consulte o artigo Mude para um contexto zonal.
    • PROJECT: o nome do seu projeto.
    • BACKEND_NAME: o nome do recurso Backend
    • APP_NAME: o nome da sua aplicação de VM.

    Pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com diferentes conjuntos de etiquetas para cada zona.

  2. Defina uma verificação de funcionamento global para o 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

    Substitua o seguinte:

    • GLOBAL_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor de API global. Para mais informações, consulte o artigo Mude para um contexto global.
    • PROJECT: o nome do seu projeto.
    • HEALTH_CHECK_NAME: o nome do recurso de verificação de estado, como my-health-check.
    • PORT: a porta na qual realizar a verificação do estado. O valor predefinido é 80.
    • TIMEOUT: o período de tempo em segundos a aguardar antes de declarar a falha. O valor predefinido é 5.
    • CHECK_INTERVAL: a quantidade de tempo em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5.
    • HEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de ser aprovadas para que o ponto final seja considerado em bom estado. O valor predefinido é 2.
    • UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2.

  3. Crie um objeto BackendService com o recurso Backend criado anteriormente. Certifique-se de que inclui o 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

    Substitua o seguinte:

    • GLOBAL_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor da API global.
    • PROJECT: o nome do seu projeto.
    • BACKEND_SERVICE_NAME: o nome escolhido para o seu recurso BackendService.
    • HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente.
    • BACKEND_NAME: o nome do recurso Backend zonal.

    • ZONE: a zona em que o recurso Backend reside. Pode especificar vários backends no campo backendRefs. Por exemplo:

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

      O campo targetPorts é opcional. Este recurso apresenta as portas que este recurso BackendServicetraduz. Se estiver a usar este objeto, faculte valores para o seguinte:

    • PORT: a porta exposta pelo serviço.

    • PROTOCOL: o protocolo de camada 4 com o qual o tráfego tem de corresponder. Apenas são suportados os protocolos TCP e UDP.

    • TARGET_PORT: a porta para a qual o valor é traduzido, como 8080. O valor não pode ser repetido num determinado objeto.

      Um exemplo para targetPorts pode ter o seguinte aspeto:

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

  4. Crie um recurso ForwardingRule interno que defina o endereço IP virtual (VIP) no qual o serviço está disponível.

    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

    Substitua o seguinte:

    • GLOBAL_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor da API global.
    • PROJECT: o nome do seu projeto.
    • FORWARDING_RULE_INTERNAL_NAME: o nome escolhido para o seu recurso ForwardingRuleInternal.
    • CIDR: o CIDR a usar para a regra de encaminhamento. Este campo é opcional. Se não for especificado, é reservado automaticamente um IPv4/32 CIDR do conjunto de endereços IP global. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede global. Para mais informações sobre os Subnet recursos, consulte o artigo Faça a gestão das sub-redes.
    • PORT: a porta a expor na regra de encaminhamento. Use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados para os back-ends configurados com esta regra de encaminhamento. Tem de especificar, pelo menos, uma porta. Use o campo port para especificar um número de porta. A porta exposta tem de ser a mesma que a aplicação real está a expor no contentor.

    • PROTOCOL: o protocolo a usar para a regra de encaminhamento, como TCP. Uma entrada na matriz ports tem de ser semelhante ao seguinte:

      ports:
- port: 80
  protocol: TCP

  5. Para validar o ILB configurado, confirme a condição Ready em cada um dos objetos criados. Valide o tráfego com um pedido curl para o VIP:

    1. Recupere o VIP:

      kubectl get forwardingruleinternal -n PROJECT

      O resultado tem o seguinte aspeto:

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

    2. Teste o tráfego com um pedido curl para o VIP na porta especificada no campo na regra de encaminhamento:

      curl http://FORWARDING_RULE_VIP:PORT

      Substitua o seguinte:

      • FORWARDING_RULE_VIP: o VIP da regra de encaminhamento.
      • PORT: o número da porta do campo na regra de encaminhamento.

Crie um balanceador de carga externo global

Os equilibradores de carga externos (ELB) expõem serviços para acesso a partir do exterior da organização a partir dos endereços IP de um conjunto atribuídos à organização a partir do conjunto de endereços IP externos de instâncias maior.

Conclua os passos seguintes para criar um ELB global para as suas cargas de trabalho de VMs.

gdcloud

Use a CLI gdcloud para criar um ELB global que segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend. O recurso personalizado Backend tem de ter o âmbito de uma zona.

  1. Para que os serviços ELB funcionem, tem de configurar e aplicar a sua própria transferência de dados ProjectNetworkPolicy personalizada na política para permitir o tráfego para as cargas de trabalho deste serviço ELB. As políticas de rede controlam o acesso aos seus workloads e não ao equilibrador de carga propriamente dito. Os ELBs expõem cargas de trabalho à sua rede de clientes, o que requer políticas de rede explícitas para permitir tráfego externo para a porta de carga de trabalho, como 8080.

    Especifique o endereço CIDR externo para permitir tráfego para as cargas de trabalho deste 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

    Substitua o seguinte:

    • GLOBAL_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor de API global. Se ainda não tiver gerado um ficheiro kubeconfig para o servidor de API global, consulte o artigo Gerar manualmente o ficheiro kubeconfig para ver detalhes.
    • PROJECT: o nome do seu projeto.
    • CIDR: o CIDR externo a partir do qual o ELB tem de ser acedido. Esta política é necessária porque o balanceador de carga externo usa o retorno direto do servidor (DSR), que preserva o endereço IP externo de origem e ignora o balanceador de carga no caminho de retorno. Para mais informações, consulte o artigo Crie uma regra de firewall de entrada global para tráfego entre organizações.
    • PORT: a porta de back-end nas VMs atrás do balanceador de carga. Este valor encontra-se no campo .spec.ports[].targetPortfield do manifesto para o recurso Service. Este campo é opcional.

    Esta configuração dá acesso a todos os recursos nos projetos ao intervalo CIDR especificado.

  2. Crie um recurso Backend em cada zona para definir o ponto final do ELB:

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

    Substitua o seguinte:

    • BACKEND_NAME: o nome do recurso de back-end, como my-backend.
    • LABELS: um seletor que define que pontos finais entre VMs usar para este recurso de back-end, como app=web.
    • PROJECT: o nome do seu projeto.

    Pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com diferentes conjuntos de etiquetas para cada zona.

  3. Defina uma verificação de funcionamento global para o 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

    Substitua o seguinte:

    • HEALTH_CHECK_NAME: o nome do recurso de verificação do estado de funcionamento, como my-health-check.
    • CHECK_INTERVAL: o período em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5. Este campo é opcional.
    • HEALTHY_THRESHOLD: o tempo de espera antes de reclamar a falha. O valor predefinido é 5. Este campo é opcional.
    • TIMEOUT: o período de tempo em segundos a aguardar antes de reclamar a falha. O valor predefinido é 5. Este campo é opcional.
    • UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2. Este campo é opcional.
    • PORT: a porta na qual realizar a verificação de funcionamento. O valor predefinido é 80. Este campo é opcional.

  4. Crie um recurso BackendService global:

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

    Substitua o seguinte:

    • BACKEND_SERVICE_NAME: o nome escolhido para este serviço de back-end.
    • PROJECT: o nome do seu projeto.
    • TARGET_PORTS: uma lista separada por vírgulas de portas de destino que este serviço de back-end traduz, em que cada porta de destino especifica o protocolo, a porta na regra de encaminhamento e a porta na instância de back-end. Pode especificar várias portas de destino. Este campo tem de estar no formato protocol:port:targetport, como TCP:80:8080. Este campo é opcional.
    • HEALTH_CHECK_NAME: o nome do recurso de verificação de estado. Este campo é opcional.

  5. Adicione o recurso BackendService global ao recurso zonal criado anteriormente:Backend

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

    Conclua este passo para cada back-end zonal que criou anteriormente.

  6. Crie um recurso ForwardingRule externo que defina o VIP no qual o serviço está disponível:

    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

    Substitua o seguinte:

    • FORWARDING_RULE_EXTERNAL_NAME: o nome da regra de encaminhamento.
    • CIDR: o CIDR a usar para a regra de encaminhamento. Este campo é opcional. Se não for especificado, é reservado automaticamente um IPv4/32 CIDR do conjunto de endereços IP global. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede global. Para mais informações sobre os Subnet recursos, consulte o artigo Faça a gestão das sub-redes.
    • PROTOCOL_PORT: o protocolo e a porta a expor na regra de encaminhamento. Este campo tem de estar no formato ip-protocol=TCP:80. A porta exposta tem de ser a mesma que a aplicação real está a expor na VM.
    • PROJECT: o nome do seu projeto.

  7. Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Valide o tráfego com um pedido curl para o VIP:

    1. Para obter o VIP atribuído, descreva a regra de encaminhamento:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_EXTERNAL_NAME

    2. Valide o tráfego com um pedido curl para o VIP na porta especificada no campo PROTOCOL_PORT na regra de encaminhamento:

      curl http://FORWARDING_RULE_VIP:PORT

      Substitua o seguinte:

      • FORWARDING_RULE_VIP: o VIP da regra de encaminhamento.
      • PORT: o número da porta do campo PROTOCOL_PORT na regra de encaminhamento.

API

Crie um ELB que tenha como destino cargas de trabalho de VMs através da API KRM. Este ELB segmenta todas as cargas de trabalho no projeto que correspondem à etiqueta definida no objeto Backend. Para criar um ELB zonal através da API KRM, siga estes passos:

  1. Para que os serviços ELB funcionem, tem de configurar e aplicar a sua própria transferência de dados ProjectNetworkPolicy personalizada na política para permitir o tráfego para as cargas de trabalho deste serviço ELB. As políticas de rede controlam o acesso aos seus workloads e não ao equilibrador de carga propriamente dito. Os ELBs expõem cargas de trabalho à sua rede de clientes, o que requer políticas de rede explícitas para permitir tráfego externo para a porta de carga de trabalho, como 8080.

    Especifique o endereço CIDR externo para permitir tráfego para as cargas de trabalho deste 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

    Substitua o seguinte:

    • GLOBAL_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor de API global. Se ainda não tiver gerado um ficheiro kubeconfig para o servidor de API global, consulte o artigo Gerar manualmente o ficheiro kubeconfig para ver detalhes.
    • PROJECT: o nome do seu projeto.
    • CIDR: o CIDR externo a partir do qual o ELB tem de ser acedido. Esta política é necessária porque o balanceador de carga externo usa o retorno direto do servidor (DSR), que preserva o endereço IP externo de origem e ignora o balanceador de carga no caminho de retorno. Para mais informações, consulte o artigo Crie uma regra de firewall de entrada global para tráfego entre organizações.
    • PORT: a porta de back-end nas VMs atrás do balanceador de carga. Este valor encontra-se no campo .spec.ports[].targetPortfield do manifesto para o recurso Service. Este campo é opcional.

  2. Crie um recurso Backend para definir os pontos finais do ELB. Crie recursos Backend para cada zona em que as cargas de trabalho estão localizadas:

    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

    Substitua o seguinte:

    • MANAGEMENT_API_SERVER: o caminho kubeconfig do caminho kubeconfig do servidor da API Management zonal. Se ainda não gerou um ficheiro kubeconfig para o servidor da API na sua zona segmentada, consulte o artigo Gere manualmente o ficheiro kubeconfig para ver detalhes.
    • PROJECT: o nome do seu projeto.
    • BACKEND_NAME: o nome do recurso Backend.

    Pode usar o mesmo recurso Backend para cada zona ou criar recursos Backend com diferentes conjuntos de etiquetas para cada zona.

  3. Defina uma verificação de funcionamento global para o 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

    Substitua o seguinte:

    • HEALTH_CHECK_NAME: o nome do recurso de verificação do estado de funcionamento, como my-health-check.
    • PORT: a porta na qual realizar a verificação de funcionamento. O valor predefinido é 80.
    • TIMEOUT: o período de tempo em segundos a aguardar antes de reclamar a falha. O valor predefinido é 5.
    • CHECK_INTERVAL: o período em segundos desde o início de uma sondagem até ao início da seguinte. O valor predefinido é 5.
    • HEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de ser aprovadas para que o ponto final seja considerado em bom estado. O valor predefinido é 2.
    • UNHEALTHY_THRESHOLD: o número de sondagens sequenciais que têm de falhar para que o ponto final seja considerado não saudável. O valor predefinido é 2.

    Uma vez que se trata de um ELB global, crie a verificação de funcionamento na API global.

  4. Crie um objeto BackendService com o recurso Backend criado 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

    Substitua o seguinte:

    • BACKEND_SERVICE_NAME: o nome escolhido para o seu recurso BackendService.
    • HEALTH_CHECK_NAME: o nome do recurso HealthCheck criado anteriormente. Não inclua este campo se estiver a configurar um ELB para cargas de trabalho de pods.
    • ZONE: a zona em que o recurso Backend reside. Pode especificar vários backends no campo backendRefs. Por exemplo:
    - name: my-backend-1
  zone: us-east1-a
- name: my-backend-2
  zone: us-east1-b

  5. Crie um recurso ForwardingRule externo que defina o VIP no qual o serviço está disponível.

    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

    Substitua o seguinte:

    • FORWARDING_RULE_EXTERNAL_NAME: o nome escolhido para o recurso ForwardingRuleExternal.
    • CIDR: o CIDR a usar para a regra de encaminhamento. Este campo é opcional. Se não for especificado, é reservado automaticamente um IPv4/32 CIDR do conjunto de endereços IP global. Especifique o nome de um recurso Subnet no mesmo espaço de nomes que esta regra de encaminhamento. Um recurso Subnet representa as informações de pedido e atribuição de uma sub-rede global. Para mais informações sobre os Subnet recursos, consulte o artigo Faça a gestão das sub-redes.
    • PORT: a porta a expor na regra de encaminhamento. Use o campo ports para especificar uma matriz de portas L4 para as quais os pacotes são encaminhados para os back-ends configurados com esta regra de encaminhamento. Tem de especificar, pelo menos, uma porta. Use o campo port para especificar um número de porta. A porta exposta tem de ser a mesma que a aplicação real está a expor no contentor.
    • PROTOCOL: o protocolo a usar para a regra de encaminhamento, como TCP. Uma entrada na matriz ports tem de ter o seguinte aspeto:
    ports:
- port: 80
  protocol: TCP

  6. Para validar o ELB configurado, confirme a condição Ready em cada um dos objetos criados. Experimente e teste o tráfego com um pedido curl ao VIP.

    1. Recupere o VIP do projeto:

      kubectl get forwardingruleexternal -n PROJECT

      O resultado tem o seguinte aspeto:

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

    2. Valide o tráfego com um pedido curl para o VIP na porta especificada no campo PORT na regra de encaminhamento:

      curl http://FORWARDING_RULE_VIP:PORT

      Substitua FORWARDING_RULE_VIP:PORT pelo VIP e pela porta da regra de encaminhamento, como 192.0.2.0:80.

Configure a replicação de armazenamento assíncrona

Os universos multizona da GDC oferecem a utilização de recursos de armazenamento replicados, como volumes e contentores, no modo assíncrono para cenários de recuperação de desastres. Estas opções de recursos de armazenamento oferecem replicação de dados assíncrona entre quaisquer duas zonas na mesma região. A replicação assíncrona ocorre em segundo plano, oferecendo um objetivo de ponto de recuperação (RPO) baixo, mas não nulo, em caso de desastre. Todos os dados replicados estão online e imediatamente acessíveis, mas podem exigir um procedimento de comutação por falha manual para permitir a escrita na zona secundária.

Pode escolher um dos seguintes tipos de replicação de armazenamento assíncrona para a sua aplicação de VM:

Crie um contentor de zona dupla para armazenamento de objetos

Os dados de armazenamento de objetos são escritos num único contentor cujos dados são armazenados em ambas as zonas. Uma vez que os dados são copiados de forma assíncrona entre zonas, as zonas podem não conter as mesmas versões de objetos em qualquer momento, mas acabam por ficar equivalentes se não forem feitas alterações adicionais. Ao contrário da replicação de volumes, os contentores replicados são graváveis durante as partições de zonas. Cada gravação num objeto produz uma versão diferente, e a versão mais recente em qualquer zona é o estado final após o restauro da conetividade.

  1. Verifique se o operador de infraestrutura (IO) criou o recurso personalizado BucketLocationConfig, que é necessário para a replicação assíncrona entre zonas para o armazenamento de objetos. Este recurso tem de ser implementado no servidor de API global raiz.

  2. Crie o recurso personalizado Bucket de zona dupla:

    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

    Substitua o seguinte:

    • GLOBAL_API_SERVER: o ficheiro kubeconfig para o servidor de API global.
    • BUCKET_NAME: o nome do contentor de armazenamento.
    • PROJECT: o nome do projeto onde o contentor reside.
    • LOCATION_NAME: o local físico onde os dados de objetos no contentor residem. Tem de ser mapeado para o nome de um recurso BucketLocation existente. Para consultar o servidor da API global da sua organização para obter uma lista de recursos BucketLocation disponíveis, execute kubectl --kubeconfig GLOBAL_API_SERVER bucketlocations. Se não existirem recursos BucketLocation, contacte o seu IO para verificar se ativou a replicação assíncrona.

Configure a replicação de armazenamento em blocos assíncrona em várias zonas

O armazenamento de blocos replicado oferece volumes replicados de forma assíncrona (PVs), que mantêm a equivalência de blocos entre os volumes principal e secundário. Devido à natureza assíncrona, o volume secundário reflete o estado da zona principal num determinado momento no passado (RPO diferente de zero). O volume secundário não é montável enquanto permanecer o destino da replicação, o que requer intervenção manual para terminar a relação e permitir que as gravações ocorram.

Tem de implementar um recurso personalizado VolumeReplicationRelationship no servidor de API global para criar dados replicados que estejam disponíveis para a comutação por falha se os dados da zona de origem ficarem indisponíveis.

Antes de começar, verifique se o seu operador de infraestrutura (IO) criou e configurou os recursos personalizados StorageClusterPeering e StorageVirtualMachinePeering para permitir a replicação do armazenamento de blocos em várias zonas. Este recurso tem de ser implementado no servidor de API global raiz.

gdcloud

  1. Defina a relação de volume de replicação assíncrona entre a zona principal e as zonas secundárias:

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

    Substitua o seguinte:

    • PRIMARY_DISK_NAME: o nome do disco de origem que está a ser replicado.
    • PROJECT: o projeto GDC do disco principal.
    • PRIMARY_ZONE: a zona onde o disco principal reside.
    • SECONDARY_DISK_NAME: o nome do disco de destino para o qual replicar.
    • SECONDARY_ZONE: a zona onde o disco secundário tem de residir.

  2. Crie um recurso personalizado VolumeFailover na zona de destino, que interrompe a replicação para a zona de destino se a zona de origem estiver indisponível por qualquer 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

    Substitua o seguinte:

    • MANAGEMENT_API_SERVER: o ficheiro kubeconfig para o servidor da API Management.
    • FAILOVER_NAME: o nome da alternativa.
    • PROJECT: o projeto onde reside a infraestrutura de armazenamento.
    • REPL_NAME: o nome da relação de replicação de volumes.

    Para mais informações sobre a gestão da replicação assíncrona para cargas de trabalho de VMs, consulte o artigo Replique volumes de forma assíncrona.

API

  1. Crie um ficheiro YAML de recursos personalizados VolumeReplicationRelationshipe implemente-o no servidor de 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

    Substitua o seguinte:

    • GLOBAL_API_SERVER: o ficheiro kubeconfig para o servidor da API de gestão global.
    • VRR_NAME: o nome da relação de replicação de volume. Tem de usar o mesmo nome quando parar a replicação assíncrona.
    • PROJECT: o projeto GDC do disco principal.
    • PRIMARY_DISK_NAME: o nome do disco de origem que está a ser replicado.
    • PRIMARY_ZONE: a zona onde o disco principal reside.
    • SECONDARY_DISK_NAME: o nome do disco de destino para o qual replicar.
    • SECONDARY_ZONE: a zona onde o disco secundário tem de residir.

  2. Crie um recurso personalizado VolumeFailover na zona de destino, que interrompe a replicação para a zona de destino se a zona de origem estiver indisponível por qualquer 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

    Substitua o seguinte:

    • MANAGEMENT_API_SERVER: o ficheiro kubeconfig para o servidor da API Management.
    • FAILOVER_NAME: o nome da alternativa.
    • PROJECT: o projeto onde reside a infraestrutura de armazenamento.
    • REPL_NAME: o nome da relação de replicação de volume.

Para mais informações sobre a gestão da replicação assíncrona para cargas de trabalho de VMs, consulte o artigo Replique volumes de forma assíncrona.

O que se segue?