Container Service for Kubernetes:Sistema de recuperação de desastres entre zonas

Visão geral da recuperação de desastres

As soluções de recuperação de desastres baseadas em nuvem geralmente se dividem em três categorias:

• Recuperação de desastres entre zonas (Cross-AZ): Abrange estratégias ativo-ativo e ativo-passivo. Como os data centers na mesma região estão fisicamente próximos, a latência de rede é baixa. Essa configuração protege contra desastres no nível de zona de disponibilidade, como incêndios, interrupções de rede ou falhas de energia. Trata-se de uma solução prática, que oferece backup de dados simples e recuperação rápida.

• Redundância geográfica ativa: Embora resulte em maior latência de rede, protege contra desastres no nível de região, como terremotos e inundações.

• Duas regiões, três centros: Combina uma configuração de centro duplo em uma região com um site de recuperação de desastres em outra, reunindo as vantagens de ambas. É ideal para cenários que exigem alta continuidade e disponibilidade de aplicativos e dados.

Do ponto de vista da arquitetura de negócios, um sistema empresarial típico divide-se em camada de acesso, camada de aplicativo e camada de dados.

• Camada de acesso: Funciona como ponto de entrada de tráfego, recebendo e encaminhando solicitações para a camada de aplicativo de backend com base em regras de roteamento.

• Camada de aplicativo: Contém os serviços de aplicativo que processam dados conforme as solicitações e retornam respostas para a camada superior.

• Camada de dados: Fornece serviços de armazenamento de dados para a camada de aplicativo.

Para alcançar a recuperação de desastres de ponta a ponta nos negócios, implemente medidas de recuperação em cada uma dessas camadas.

• Camada de acesso: O gateway multicluste ALB do ACK One atua como camada de acesso e fornece alta disponibilidade integrada entre zonas de disponibilidade na mesma região.

• Camada de aplicativo: O gateway multicluste ALB do ACK One gerencia a recuperação de desastres para a camada de aplicativo, habilitando recuperação de desastres entre zonas (ativo-ativo/ativo-passivo) e redundância geográfica ativa.

• Camada de dados: A recuperação de desastres e a sincronização de dados nesta camada dependem das capacidades do middleware utilizado.

Benefícios

O uso do gateway multicluste ALB do ACK One para recuperação de desastres oferece as seguintes vantagens em comparação às soluções baseadas em DNS:

• A recuperação baseada em DNS exige vários endereços IP de balanceador de carga (um para cada cluster). Já a solução baseada em gateway requer apenas um IP de balanceador de carga por região e fornece alta disponibilidade entre várias zonas de disponibilidade por padrão.

• A solução baseada em gateway suporta roteamento da Camada 7, enquanto as soluções baseadas em DNS não oferecem esse suporte.

• Em soluções baseadas em DNS, alterações de endereço IP podem causar interrupções temporárias no serviço devido ao cache de DNS no lado do cliente. A solução baseada em gateway permite o failover de tráfego contínuo para o backend do serviço em outro cluster.

• O gateway multicluste é um recurso regional. Todas as operações são gerenciadas a partir de uma instância Fleet central, eliminando a necessidade de instalar um controlador de Ingress e criar recursos de Ingress em cada cluster ACK. Isso proporciona gerenciamento de tráfego regional e reduz a sobrecarga de gerenciamento multicluste.

Arquitetura da solução

Este tópico utiliza um exemplo de aplicativo web, que inclui recursos de Deployment e Service, para demonstrar a arquitetura de uma solução de recuperação de desastres entre zonas construída com um gateway multicluste ALB.

• Crie dois clusters ACK, Cluster 1 e Cluster 2, em duas zonas de disponibilidade diferentes (AZ 1 e AZ 2) dentro da mesma região.

• Use o ACK One GitOps para distribuir o aplicativo para o Cluster 1 e o Cluster 2.

• Crie um gateway multicluste ALB criando um recurso AlbConfig na instância ACK One Fleet.

• Após criar o gateway multicluste ALB, crie um Ingress para rotear o tráfego com base em pesos ou cabeçalhos. Se um cluster ficar indisponível, o tráfego será roteado automaticamente para o cluster íntegro.

• A sincronização de dados para o ApsaraDB RDS depende das capacidades do middleware.

Pré-requisitos

• Ative o serviço Application Load Balancer (ALB).

• Ative o recurso de gerenciamento de fleet.

• Associe dois clusters ACK ao ACK One Fleet. Os clusters devem estar na mesma Virtual Private Cloud (VPC) da instância Fleet. Para mais informações, consulte Gerenciar clusters associados.

• Obtenha o KubeConfig da instância Fleet no console do ACK One e conecte-se à instância Fleet usando kubectl.

• Instale a versão mais recente da CLI do Cloud Assistant e configure a CLI do Cloud Assistant.

Etapa 1: Implantar aplicativos em vários clusters

O ACK One suporta a implantação de aplicativos em vários clusters por meio do GitOps multicluste ou da distribuição de aplicativos multicluste. Para mais informações, consulte Início rápido do GitOps, Criar um aplicativo multicluste e Início rápido para distribuição de aplicativos. Este tópico usa o GitOps como exemplo.

1. Faça login no console do ACK One. No painel de navegação à esquerda, escolha Fleet > Multi-cluster GitOps.

2. No canto superior esquerdo da página Multi-cluster GitOps, clique em ao lado do nome do fleet e selecione o fleet desejado na lista suspensa.

3. Clique em Create Multi-cluster Application > GitOps para acessar a página Create Multi-cluster Application - GitOps.

   Nota

   • Certifique-se de que o GitOps esteja ativado para a instância ACK One Fleet. Para mais informações, consulte Ativar GitOps em uma instância ACK One Fleet.

   • Para acessar o GitOps pela internet, consulte Ativar acesso público ao GitOps.

4. Na aba Create from YAML, copie o seguinte conteúdo YAML para o editor e clique em OK para criar e implantar o aplicativo.

   Nota

   O YAML a seguir implanta o aplicativo web-demo em todos os clusters associados. Também é possível selecionar clusters específicos na aba Quick Create, e suas seleções serão refletidas no conteúdo da aba Create from YAML.

   apiVersion: argoproj.io/v1alpha1
   kind: ApplicationSet
   metadata:
     name: appset-web-demo
     namespace: argocd
   spec:
     template:
       metadata:
         name: '{{.metadata.annotations.cluster_id}}-web-demo'
         namespace: argocd
       spec:
         destination:
           name: '{{.name}}'
           namespace: gateway-demo
         project: default
         source:
           repoURL: https://github.com/AliyunContainerService/gitops-demo.git
           path: manifests/helm/web-demo
           targetRevision: main
           helm:
             valueFiles:
               - values.yaml
             parameters:
               - name: envCluster
                 value: '{{.metadata.annotations.cluster_name}}'
         syncPolicy:
           automated: {}
           syncOptions:
             - CreateNamespace=true
     generators:
       - clusters:
           selector:
             matchExpressions:
               - values:
                   - cluster
                 key: argocd.argoproj.io/secret-type
                 operator: In
               - values:
                   - in-cluster
                 key: name
                 operator: NotIn
     goTemplateOptions:
       - missingkey=error
     syncPolicy:
       preserveResourcesOnDeletion: false
     goTemplate: true

Etapa 2: Criar um gateway multicluste ALB

Crie um objeto AlbConfig na instância ACK One Fleet para configurar um gateway multicluste ALB do ACK One e associar clusters a ele.

1. Obtenha dois IDs de vSwitch da VPC onde o ACK One Fleet está localizado.

2. Crie um arquivo chamado gateway.yaml com o seguinte conteúdo.

   Nota

   • Substitua ${vsw-id1} e ${vsw-id2} pelos IDs de vSwitch obtidos na etapa anterior. Substitua ${cluster1} e ${cluster2} pelos IDs dos clusters associados que deseja adicionar.

   • Para os clusters associados ${cluster1} e ${cluster2}, configure as regras de entrada de seus grupos de segurança para permitir tráfego do bloco CIDR do vSwitch em todas as portas.

   apiVersion: alibabacloud.com/v1
   kind: AlbConfig
   metadata:
     name: ackone-gateway-demo
     annotations:
       # Add the associated clusters that will process traffic to the ALB multi-cluster instance.
       alb.ingress.kubernetes.io/remote-clusters: ${cluster1},${cluster2}
   spec:
     config:
       name: one-alb-demo
       addressType: Internet
       addressAllocatedMode: Fixed
       zoneMappings:
       - vSwitchId: ${vsw-id1}
       - vSwitchId: ${vsw-id2}
     listeners:
     - port: 8001
       protocol: HTTP
   ---
   apiVersion: networking.k8s.io/v1
   kind: IngressClass
   metadata:
     name: alb
   spec:
     controller: ingress.k8s.alibabacloud/alb
     parameters:
       apiGroup: alibabacloud.com
       kind: AlbConfig
       name: ackone-gateway-demo

   A tabela a seguir descreve os parâmetros.

   Parâmetro	Obrigatório	Descrição
   metadata.name	Sim	Nome do AlbConfig.
   metadata.annotations: alb.ingress.kubernetes.io/remote-clusters	Sim	Clusters associados a serem adicionados ao gateway multicluste ALB. Os IDs de cluster especificados aqui já devem estar associados à instância Fleet.
   spec.config.name	Não	Nome da instância ALB.
   spec.config.addressType	Não	Tipo de rede da instância ALB. Valores válidos: Internet (padrão): Instância voltada para a internet que fornece serviços através da rede pública. Nota O Application Load Balancer usa um elastic IP address (EIP) para fornecer serviços pela internet. Se você usar uma instância ALB voltada para a internet, haverá cobrança de taxas de instância e taxas de largura de banda ou transferência de dados para o EIP. Para mais informações, consulte Pagamento conforme o uso. Intranet: Instância de rede privada que fornece serviços dentro de uma VPC e não pode ser acessada pela internet.
   spec.config.zoneMappings	Sim	IDs dos vSwitches para a instância ALB. Para mais informações sobre como criar um vSwitch, consulte Criar e gerenciar vSwitches. Nota Os vSwitches especificados devem estar em zonas de disponibilidade suportadas pelo ALB e na mesma VPC dos seus clusters. Para mais informações sobre as regiões e zonas de disponibilidade suportadas pelo ALB, consulte Regiões e zonas. Para garantir alta disponibilidade, selecione vSwitches de pelo menos duas zonas de disponibilidade diferentes, caso a região ofereça essa opção.
   spec.listeners	Não	Porta e protocolo do listener da instância ALB. Este exemplo configura um listener HTTP na porta 8001. Um listener define como o tráfego entra no balanceador de carga. Mantenha esta configuração; caso contrário, será necessário criar um listener antes de usar o ALB Ingress.

3. Execute o comando a seguir para implantar o gateway.yaml e criar o gateway multicluste ALB e o IngressClass:

   kubectl apply -f gateway.yaml

4. Aguarde de 1 a 3 minutos e execute o comando abaixo para verificar se o gateway multicluste ALB foi criado:

   kubectl get albconfig ackone-gateway-demo

   Saída esperada:

   NAME      		      ALBID      DNSNAME                                  PORT&PROTOCOL   CERTID   AGE
   ackone-gateway-demo           alb-xxxx   alb-xxxx.<regionid>.alb.aliyuncsslb.com                           4d9h

5. Execute o seguinte comando para confirmar que os clusters associados foram adicionados:

   kubectl get albconfig ackone-gateway-demo -ojsonpath='{.status.loadBalancer.subClusters}'

   A saída esperada é uma lista de IDs de cluster.

Etapa 3: Implementar recuperação de desastres com Ingress

O gateway multicluste utiliza um Ingress para gerenciar o tráfego entre vários clusters. Crie um objeto Ingress na instância ACK One Fleet para implementar a recuperação de desastres entre zonas no modelo ativo-ativo.

1. Na instância Fleet, crie o namespace onde o Service reside. Neste exemplo, o namespace é gateway-demo.

2. Crie um arquivo chamado ingress-demo.yaml com o conteúdo a seguir.

   Nota

   • A soma dos pesos especificados nas anotações alb.ingress.kubernetes.io/cluster-weight deve ser igual a 100.

   • Esta regra de roteamento expõe o serviço de backend service1 no caminho /svc1 do domínio alb.ingress.alibaba.com. Substitua ${cluster1-id} e ${cluster2-id} pelos IDs dos seus clusters.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     annotations:
       alb.ingress.kubernetes.io/listen-ports: |
        [{"HTTP": 8001}]
       alb.ingress.kubernetes.io/cluster-weight.${cluster1-id}: "20"
       alb.ingress.kubernetes.io/cluster-weight.${cluster2-id}: "80"
     name: web-demo
     namespace: gateway-demo
   spec:
     ingressClassName: alb
     rules:
     - host: alb.ingress.alibaba.com
       http:
         paths:
         - path: /svc1
           pathType: Prefix
           backend:
             service:
               name: service1
               port:
                 number: 80

3. Execute o comando abaixo para implantar o Ingress na instância ACK One Fleet:

   kubectl apply -f ingress-demo.yaml -n gateway-demo

Etapa 4: Verificar a recuperação de desastres entre zonas

curl -H "host: alb.ingress.alibaba.com" alb-xxxx.<regionid>.alb.aliyuncsslb.com:<listeners port>/svc1

for i in {1..500}; do curl -H "host: alb.ingress.alibaba.com" alb-xxxx.cn-beijing.alb.aliyuncsslb.com:8001/svc1; done > res.txt

grep poc-ack-1 res.txt |wc -l
      108
grep poc-ack-2 res.txt |wc -l
      392

for i in {1..500}; do curl -H "host: alb.ingress.alibaba.com" alb-xxxx.cn-beijing.alb.aliyuncsslb.com:8001/svc1; sleep 1; done

This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-2!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!
This is poc-ack-1!