Partilhar via


Realocar um cluster do Serviço Kubernetes do Azure (AKS) para outra região

Este artigo aborda orientações para realocar um cluster do Serviço Kubernetes do Azure para outra região.

Há vários motivos pelos quais você pode querer mover seus recursos existentes do Azure de uma região para outra. Você pode querer:

  • Aproveite uma nova região do Azure.
  • Implante recursos ou serviços disponíveis apenas em regiões específicas.
  • Atender aos requisitos internos de política e governança.
  • Alinhar-se com fusões e aquisições de empresas
  • Atenda aos requisitos de planejamento de capacidade.

Nota

Os clientes com ciclos de lançamento rápidos geralmente aproveitam os pipelines de CI/CD. Nesses casos, você pode considerar alterar os pipelines de compilação e liberação em vez de reimplantar os clusters AKS na região de destino.

Pré-requisitos

Antes de começar a etapa de planejamento de recolocação, primeiro revise os seguintes pré-requisitos:

  • Verifique se a região de destino tem capacidade suficiente (SKUs de VM) para acomodar os novos nós de cluster.

  • Valide se você tem permissões de criação de recursos para a assinatura de destino. Verifique se a política do Azure não está restringindo as regiões nas quais o AKS pode ser implantado.

  • (Opcional) Colete os modelos ou scripts de Infraestrutura como código (IaC) com os quais você provisionou o cluster AKS de origem.

  • Colete os manifestos do Kubernetes para recriar a carga de trabalho do aplicativo dentro do cluster de destino.

    Gorjeta

    Avalie uma abordagem do GitOps para a implantação da carga de trabalho em que os manifestos de configuração do Kubernetes são armazenados em um repositório git e aplicados automaticamente por um operador GitOps em execução no cluster, como o Flux. Uma abordagem GitOps torna a reimplantação de cargas de trabalho em clusters diferentes tão simples quanto instalar o controlador GitOps e apontá-lo para o repositório.

  • Analise a implementação de entrada de cluster.

  • Documente as alterações de DNS necessárias para apontar um domínio público para o ponto de extremidade de entrada do cluster.

  • Analise se o cluster armazena dados de estado, como volumes persistentes, necessários para migrar para o cluster de destino.

  • Documente o gerenciamento e a distribuição de certificados TLS públicos.

  • Capture todos os endereços IP definidos na lista de permissões do serviço da API do AKS.

  • Compreender todos os recursos dependentes. Alguns dos recursos poderiam ser:

    • Filas, Barramentos de Mensagens, Mecanismos de cache
    • Azure Key Vault
    • Identidade Gerida
    • Configuração de rede virtual. Defina tamanhos de sub-rede suficientes para permitir o crescimento do IP do contêiner se estiver usando o modelo de rede avançado do Azure
    • Endereço IP público
    • Gateway de rede virtual (VNG). Se a comunicação site a site for necessária para um ambiente local na região de destino, um VNG deverá ser criado na rede virtual de destino.
    • Ponto de extremidade privado do Azure. Os recursos de PaaS do Azure que utilizam pontos de extremidade de link privado devem ser revisados e novas instâncias de link privado criadas na região de destino, como ACR, Banco de Dados SQL do Azure, KeyVault, etc.
    • Gateway de Aplicação do Azure
    • Azure DNS
    • Azure Firewall
    • Azure Monitor (Insights de Contêiner)
    • O Registro de Contêiner do Azure pode replicar imagens entre instâncias ACR. Para um desempenho ideal ao extrair imagens, o registro deve existir na região de destino.

      Nota

      Se você usar o Registro de Contêiner do Azure para autenticar no Registro de contêiner, a identidade gerenciada do novo cluster AKS poderá ser a função RBAC concedida AcrPull .

    • Managed Disks do Azure
    • Ficheiros do Azure

Preparação

Antes de iniciar o processo de realocação do cluster, conclua os seguintes preparativos:

  1. Para acomodar os nós e pods do cluster AKS, se estiver usando a rede CNI do Azure, implante a rede virtual com muitas sub-redes de tamanho suficiente.

  2. Se você estiver usando o Cofre da Chave do Azure, implante o Cofre da Chave.

  3. Certifique-se de que os certificados de entrada TLS relevantes estejam disponíveis para implantação, idealmente em um repositório seguro, como o Azure Key Vault.

  4. Implante um registro de contêiner. Sincronize as imagens do registro de origem automaticamente ou reconstrua e envie novas imagens para o registro de destino usando um pipeline ou script de CI/CD.

  5. Implante um espaço de trabalho do Azure Monitor.

  6. (Opcional) Implantar o Gateway de Aplicativo do Azure para lidar com o tráfego de entrada O Controlador de Ingresso do Gateway de Aplicativo (AGIC) pode se integrar perfeitamente ao cluster

  7. Implante todas as fontes de dados exigidas pela carga de trabalho do cluster e restaure ou sincronize os dados de origem.

  8. Execute artefatos de IaC existentes definidos em um pipeline de CI/CD que foram usados para implantar o cluster de origem e os serviços dos quais ele depende. Altere o código ou os parâmetros de entrada do modelo para reimplantar em um grupo de recursos diferente e na região do Azure.

Voltar a implementar

Implante o cluster AKS sem qualquer migração de dados, seguindo estas etapas:

  1. Para criar o ambiente de destino no Azure, execute manualmente os artefatos IaC existentes em uma estação de trabalho local.

  2. Se não houver ativos IaC existentes, a configuração de cluster atual poderá ser exportada como um modelo ARM e executada na região de destino. Os modelos IaC são criados do zero ou são versões modificadas de modelos de exemplo usando Bicep, JSON, Terraform ou outra solução.

    Nota

    • As conexões de Link Privado, os registros conectados ao ACR e as fontes de dados do espaço de trabalho do Azure Monitor não são exportados atualmente usando esse método e, portanto, devem ser removidos do modelo gerado antes da execução.
  3. Implante a carga de trabalho do contêiner no cluster AKS, o que pode ser alcançado de duas maneiras:

    • Os Pull Manifests são extraídos de um repositório e aplicados por um controlador em execução dentro do cluster, conhecido como uma abordagem GitOps.
    • Push (Git: Emitir). Os manifestos são enviados por push para o cluster usando o serviço de API do Kubernetes e a ferramenta de linha de comando kubectl, seja de um pipeline de CI/CD ou estação de trabalho local.
  4. Para garantir que o novo cluster tenha o desempenho previsto, execute testes e validação.

  5. Altere suas entradas DNS públicas para apontar para o IP de entrada externo do cluster de destino (IP do Balanceador de Carga Público do Azure ou IP Público do Gateway de Aplicativo).

  6. Uma implantação usando uma solução de balanceamento de carga global, como o DNS do Azure ou o Gerenciador de Tráfego do Azure, precisa adicionar a região à configuração.

Reimplantar com migração de dados

As cargas de trabalho do AKS que usam armazenamento local, como volumes persistentes, para armazenar dados ou hospedar serviços de banco de dados dentro do cluster podem ser copiadas em um cluster de origem e restauradas em um cluster de destino. Para saber como executar backup e restauração, consulte Fazer backup do Serviço Kubernetes do Azure usando a CLI do Azure.