Passo 2 — Configurar os Helm values por cluster

Os values do Helm configuram o plugin Azure, o Backup Storage Location apontando para o container backups da Storage Account RA-GZRS e o Volume Snapshot Location com o Resource Group de cada região. A diferença entre os dois arquivos é apenas o resourceGroup do volumeSnapshotLocation e das credenciais do SP:

# scripts/art-10-velero-aks/velero-values-brazilsouth.yaml

initContainers:
  - name: velero-plugin-for-azure
    image: velero/velero-plugin-for-microsoft-azure:v1.10.0
    imagePullPolicy: IfNotPresent
    volumeMounts:
      - mountPath: /target
        name: plugins

configuration:
  backupStorageLocation:
    - name: default
      provider: azure
      bucket: backups
      config:
        storageAccount: stblogcastilhobrazil
        resourceGroup: rg-blog-castilho-workload-brazilsouth
        storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY

  volumeSnapshotLocation:
    - name: default
      provider: azure
      config:
        resourceGroup: rg-blog-castilho-workload-brazilsouth

credentials:
  useSecret: true
  secretContents:
    cloud: |
      AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
      AZURE_TENANT_ID=${AZURE_TENANT_ID}
      AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
      AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
      AZURE_RESOURCE_GROUP=rg-blog-castilho-workload-brazilsouth
      AZURE_CLOUD_NAME=AzurePublicCloud

features: EnableCSI

deployNodeAgent: true

O arquivo para East US é idêntico, com duas diferenças: resourceGroup do volumeSnapshotLocation muda para rg-blog-castilho-workload-eastus, e AZURE_RESOURCE_GROUP nas credenciais também aponta para East US. O backupStorageLocation continua apontando para a mesma Storage Account de Brazil South, pois a RA-GZRS disponibiliza os dados na réplica de East US automaticamente.

O campo storageAccountKeyEnvVar: AZURE_STORAGE_ACCOUNT_ACCESS_KEY instrui o plugin a usar a chave de acesso da Storage Account em vez de RBAC. Para obter a chave e incluí-la nas credenciais do Helm, adicione ao seu .env:

>SA_KEY=$(az storage account keys list \
  --account-name stblogcastilhobrazil \
  --resource-group rg-blog-castilho-workload-brazilsouth \
  --query "[0].value" -o tsv)

export AZURE_STORAGE_ACCOUNT_ACCESS_KEY="$SA_KEY"

Passo 3 — Instalar o Velero via Helm

O script 01-install-velero.sh instala o Velero nos dois clusters em sequência, aplicando o values file específico de cada região. O Helm chart versão 7.1.0 é o que corresponde ao Velero 1.13.x:

# Carregar credenciais
source .env

# Instalar nos dois clusters
bash scripts/art-10-velero-aks/01-install-velero.sh

O script executa os seguintes passos para cada cluster:

>helm repo add vmware-tanzu https://vmware-tanzu.github.io/helm-charts
helm repo update

helm upgrade --install velero vmware-tanzu/velero \
  --namespace velero \
  --create-namespace \
  --version 7.1.0 \
  --values velero-values-brazilsouth.yaml \
  --kube-context aks-blog-castilho-brazilsouth

kubectl wait --for=condition=ready pod \
  -l app.kubernetes.io/name=velero \
  -n velero \
  --timeout=120s \
  --context aks-blog-castilho-brazilsouth

Passo 4 — Verificar a instalação

Após a instalação, verifique se o velero backup restore aks está conectado ao Storage Account e se os locations estão disponíveis:

# Verificar status no cluster primário
velero backup-location get --kubecontext aks-blog-castilho-brazilsouth
# NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED   ACCESS MODE   DEFAULT
# default   azure      backups         Available   ...              ReadWrite     true

velero snapshot-location get --kubecontext aks-blog-castilho-brazilsouth
# NAME      PROVIDER
# default   azure

# Verificar os pods do Velero e Node Agent
kubectl get pods -n velero --context aks-blog-castilho-brazilsouth
# NAME                      READY   STATUS    RESTARTS
# velero-xxx-yyy            1/1     Running   0
# node-agent-aaa            1/1     Running   0   <- DaemonSet, 1 por node
# node-agent-bbb            1/1     Running   0

# Repetir para East US
velero backup-location get --kubecontext aks-blog-castilho-eastus

O status Available no Backup Storage Location confirma que o Velero conseguiu autenticar no Storage Account e que o container backups está acessível. Se o status for Unavailable, verifique as credenciais do Service Principal e se a Storage Account permite acesso da rede do cluster (o public_network_access_enabled = false do Art. 08 requer que o acesso venha via Private Endpoint ou que você configure a exceção de rede).

Passo 5 — Backup manual de namespace

Com o Velero instalado, faça um backup do namespace app-producao onde a aplicação demo foi deployada no Art. 09:

># Backup do namespace app-producao no cluster primário
bash scripts/art-10-velero-aks/02-create-backup.sh \
  aks-blog-castilho-brazilsouth \
  app-producao

# O script cria um backup com nome: backup-app-producao-YYYYMMDD-HHMM

O script cria o backup e aguarda sua conclusão:

>BACKUP_NAME="backup-app-producao-$(date +%Y%m%d-%H%M)"

velero backup create "$BACKUP_NAME" \
  --include-namespaces app-producao \
  --snapshot-volumes=true \
  --storage-location default \
  --kubecontext aks-blog-castilho-brazilsouth

# Aguardar conclusão
velero backup wait "$BACKUP_NAME" \
  --kubecontext aks-blog-castilho-brazilsouth

# Ver detalhes do backup
velero backup describe "$BACKUP_NAME" --details \
  --kubecontext aks-blog-castilho-brazilsouth

O output de velero backup describe mostra o número de itens coletados por tipo de recurso (Deployments, Services, ConfigMaps, etc.) e o status de cada PVC snapshot. Um backup bem-sucedido tem Phase: Completed e zero warnings críticos:

># Saída esperada (resumida):
# Name:         backup-app-producao-20260603-1430
# Namespace:    velero
# Labels:       velero.io/storage-location=default
# Phase:        Completed
#
# Started:      2026-06-03 14:30:00 +0000 UTC
# Completed:    2026-06-03 14:30:42 +0000 UTC
#
# Expiration:   2026-07-03 14:30:00 +0000 UTC
#
# Resource List:
#   apps/v1/Deployment: 1
#   v1/Namespace:       1
#   v1/Service:         1

Passo 6 — Restore cross-region no cluster East US

Com o velero backup restore aks e o backup concluído e replicado para East US via RA-GZRS, execute o restore no cluster secundário. O script 03-restore-backup.sh recebe o nome do backup como argumento e faz o restore diretamente no contexto de East US:

># Restore no cluster East US
bash scripts/art-10-velero-aks/03-restore-backup.sh \
  backup-app-producao-20260603-1430

O script executa:

>velero restore create "restore-$(date +%Y%m%d-%H%M)" \
  --from-backup backup-app-producao-20260603-1430 \
  --kubecontext aks-blog-castilho-eastus

velero restore wait "restore-..." \
  --kubecontext aks-blog-castilho-eastus

velero restore describe "restore-..." --details \
  --kubecontext aks-blog-castilho-eastus

Após o restore, verifique se os recursos foram recriados no cluster de East US:

># Verificar recursos restaurados
kubectl get all -n app-producao --context aks-blog-castilho-eastus
# NAME                           READY   STATUS    RESTARTS
# pod/dr-demo-xxx-yyy            1/1     Running   0
# pod/dr-demo-xxx-zzz            1/1     Running   0
#
# NAME               TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)
# service/dr-demo    LoadBalancer   10.x.x.x       20.y.y.y       80:30xxx/TCP

# Confirmar que a aplicação responde
kubectl get svc dr-demo -n app-producao \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}' \
  --context aks-blog-castilho-eastus

O restore recria o namespace, o Deployment e o Service. Como a aplicação usa a imagem do ACR geo-replicado (acrblogcastilho.azurecr.io/dr-demo:eastus), o pull é local — sem tráfego cross-region para obter a imagem. O Service do tipo LoadBalancer provisiona um novo IP externo em East US, que pode ser adicionado como origin no Front Door para completar o failover.

Passo 7 — Schedule de backup automático

Para um DR efetivo, o backup precisa ser recorrente. O script 04-schedule-backup.sh cria um schedule diário às 02:00 UTC com TTL de 720 horas (30 dias), garantindo que sempre haja backups recentes disponíveis para restore:

># Criar schedule no cluster primário
bash scripts/art-10-velero-aks/04-schedule-backup.sh \
  aks-blog-castilho-brazilsouth

O schedule é criado com:

>velero schedule create schedule-diario \
  --schedule "0 2 * * *" \
  --include-namespaces app-producao \
  --snapshot-volumes=true \
  --storage-location default \
  --ttl 720h \
  --kubecontext aks-blog-castilho-brazilsouth

# Verificar schedules ativos
velero schedule get --kubecontext aks-blog-castilho-brazilsouth
# NAME             STATUS    CREATED                  SCHEDULE    LAST BACKUP
# schedule-diario  Enabled   2026-06-03 ...           0 2 * * *   n/a

Com o TTL de 720h e execuções diárias, você mantém até 30 backups — suficiente para atender um RPO de 24 horas. Para RPOs menores, reduza o intervalo do schedule (por exemplo, "0 */6 * * *" para de 6 em 6 horas) e ajuste o TTL proporcionalmente. Os backups são nomeados automaticamente pelo Velero como schedule-diario-YYYYMMDD-HHMMSS.

Troubleshooting

Limpeza dos recursos

># Remover schedules e backups
velero schedule delete schedule-diario --kubecontext aks-blog-castilho-brazilsouth --confirm
velero backup delete --all --kubecontext aks-blog-castilho-brazilsouth --confirm

# Desinstalar o Velero dos clusters
helm uninstall velero -n velero --kube-context aks-blog-castilho-brazilsouth
helm uninstall velero -n velero --kube-context aks-blog-castilho-eastus

# Remover o namespace
kubectl delete namespace velero --context aks-blog-castilho-brazilsouth
kubectl delete namespace velero --context aks-blog-castilho-eastus

# Remover o Service Principal
az ad sp delete --id "$(az ad sp list --display-name sp-velero-blog-castilho --query '[0].appId' -o tsv)"

Próximos passos

Com o velero backup restore aks configurado, os backups de namespace são realizados diariamente e podem ser restaurados no cluster secundário em minutos. O Art. 11 avança para a orquestração completa do failover: Runbooks PowerShell no Azure Automation que coordenam o ASR (failover de VMs), o Traffic Manager, o AKS e o Front Door em uma sequência automatizada — transformando as peças individuais desta série em um procedimento de DR executável com um webhook.

Interessado em saber mais sobre artigos relacionados ao Microsoft Azure CLIQUE AQUI

Este guia técnico é exclusivo do Blog do Castilho. Explore nossa para mais conteúdos sobre IA e Cloud.