Container Service for Kubernetes:Recuperação de desastres entre zonas com um gateway multi-cluster ACK One MSE

Implantar usando a interface do Argo CD

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

2. Na página Multi-cluster GitOps, clique em GitOps Console.

   Se o GitOps ainda não estiver habilitado, clique em Enable GitOps . Para acessar o GitOps pela rede pública, consulte Habilitar acesso público ao Argo CD .

3. Adicione o repositório da aplicação.

   1. No painel de navegação à esquerda do Argo CD, clique em Settings e escolha Repositories > + Connect Repo.

   2. Configure os seguintes parâmetros e clique em CONNECT.

      Seção	Parâmetro	Valor
      Choose your connection method	—	VIA HTTP/HTTPS
      CONNECT REPO USING HTTP/HTTPS	Type	git
      	Project	default
      	Repository URL	https://github.com/AliyunContainerService/gitops-demo.git
      	Skip server verification	Selecione esta caixa de seleção

      

      Quando a conexão for bem-sucedida, CONNECTION STATUS exibirá Successful.

      

4. Crie uma aplicação para cada cluster. Na página Applications, clique em + NEW APP e configure os parâmetros a seguir. Repita esta etapa para o Cluster 2, substituindo a URL do cluster e o valor de envCluster adequadamente.

   Seção	Parâmetro	Valor
   GENERAL	Application Name	Um nome exclusivo para a aplicação
   	Project Name	default
   	SYNC POLICY	Manual (sincronização sob demanda) ou Automatic (o Argo CD verifica o repositório git a cada 3 minutos e implanta alterações automaticamente)
   SYNC OPTIONS	—	Selecione AUTO-CREATE NAMESPACE
   SOURCE	Repository URL	https://github.com/AliyunContainerService/gitops-demo.git
   	Revision	Branches: gateway-demo
   	Path	manifests/helm/web-demo
   DESTINATION	Cluster URL	Selecione a URL do Cluster 1 (ou do Cluster 2 para a segunda aplicação)
   	Namespace	gateway-demo
   Helm > Parameters	envCluster	cluster-demo-1 para o Cluster 1, cluster-demo-2 para o Cluster 2

Implantar usando a CLI do Argo CD

1. Adicione o repositório git.

   argocd repo add https://github.com/AliyunContainerService/gitops-demo.git --name ackone-gitops-demos

   Saída esperada:

   Repository 'https://github.com/AliyunContainerService/gitops-demo.git' added

2. Verifique se o repositório foi adicionado e confirme se ambos os clusters estão registrados.

   argocd repo list

   Saída esperada:

   TYPE  NAME  REPO                                                       INSECURE  OCI    LFS    CREDS  STATUS      MESSAGE  PROJECT
   git         https://github.com/AliyunContainerService/gitops-demo.git  false     false  false  false  Successful           default

   argocd cluster list

   Saída esperada da lista de clusters:

   SERVER                          NAME                                        VERSION  STATUS      MESSAGE                                                  PROJECT
   https://1.1.XX.XX:6443      c83f3cbc90a****-temp01   1.22+    Successful
   https://2.2.XX.XX:6443      c83f3cbc90a****-temp02   1.22+    Successful
   https://kubernetes.default.svc  in-cluster                                           Unknown     Cluster has no applications and is not being monitored.

3. Crie o manifesto da aplicação. Substitua repoURL pela URL real do seu repositório e substitua ${cluster1_url} e ${cluster2_url} pelas URLs do servidor de API dos clusters obtidas na etapa anterior. apps-web-demo.yaml

   apiVersion: argoproj.io/v1alpha1
   kind: Application
   metadata:
     name: app-demo-cluster1
     namespace: argocd
   spec:
     destination:
       namespace: gateway-demo
       # https://1.1.XX.XX:6443
       server: ${cluster1_url}
     project: default
     source:
       helm:
         releaseName: "web-demo"
         parameters:
         - name: envCluster
           value: cluster-demo-1
         valueFiles:
         - values.yaml
       path: manifests/helm/web-demo
       repoURL: https://github.com/AliyunContainerService/gitops-demo.git
       targetRevision: gateway-demo
     syncPolicy:
       syncOptions:
       - CreateNamespace=true
   ---
   apiVersion: argoproj.io/v1alpha1
   kind: Application
   metadata:
     name: app-demo-cluster2
     namespace: argocd
   spec:
     destination:
       namespace: gateway-demo
       server: ${cluster2_url}
     project: default
     source:
       helm:
         releaseName: "web-demo"
         parameters:
         - name: envCluster
           value: cluster-demo-2
         valueFiles:
         - values.yaml
       path: manifests/helm/web-demo
       repoURL: https://github.com/AliyunContainerService/gitops-demo.git
       targetRevision: gateway-demo
     syncPolicy:
       syncOptions:
       - CreateNamespace=true

4. Implante as aplicações.

   kubectl apply -f apps-web-demo.yaml

5. Verifique se ambas as aplicações estão sincronizadas e íntegras.

   argocd app list

   Saída esperada:

   NAME                      CLUSTER                  NAMESPACE  PROJECT  STATUS  HEALTH   SYNCPOLICY  CONDITIONS  REPO                                                       PATH                     TARGET
   argocd/web-demo-cluster1  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main
   argocd/web-demo-cluster2  https://10.1.XX.XX:6443             default  Synced  Healthy  Auto        <none>      https://github.com/AliyunContainerService/gitops-demo.git  manifests/helm/web-demo  main

Redundância ativa entre zonas

No modo de redundância ativa entre zonas, o tráfego é balanceado entre todos os backends do cluster pela proporção de réplicas. Caso um cluster apresente falha, o gateway redireciona automaticamente sua parcela de tráfego para os demais clusters íntegros.

Exemplo: Com 9 réplicas no Cluster 1 e 1 réplica no Cluster 2, 90% do tráfego vai para o Cluster 1 e 10% para o Cluster 2 por padrão. Se todos os backends do Cluster 1 falharem, 100% do tráfego será transferido para o Cluster 2.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-demo
spec:
  ingressClassName: mse
  rules:
  - host: example.com
    http:
      paths:
      - path: /svc1
        pathType: Exact
        backend:
          service:
            name: service1
            port:
              number: 80

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

Recuperação de desastres primário/secundário

No modo primário/secundário, todo o tráfego vai para o Cluster 1 (primário) em condições normais. Se o Cluster 1 apresentar falha, o gateway redireciona automaticamente o tráfego para o Cluster 2 (secundário).

Este modo utiliza duas anotações específicas do MSE para fixar as rotas do Ingress em um cluster específico:

Para obter uma lista completa das anotações do MSE Ingress, consulte Anotações suportadas pelos gateways MSE Ingress.