Partilhar via

Migrar do Amazon EKS para o Serviço Kubernetes do Azure (AKS)

  • Artigo

Este artigo fornece estratégias para migrar cargas de trabalho típicas sem estado e com monitoração de estado do Amazon EKS para o Serviço Kubernetes do Azure (AKS).

Considerações

O processo de implantação real de uma carga de trabalho de produção do mundo real pode variar dependendo dos seguintes fatores:

  • Estratégias de implantação: A escolha entre o GitOps e os métodos tradicionais de DevOps Continuous Integration/Continuous Deployment (CI/CD) influencia significativamente a abordagem de implantação. O GitOps prioriza a infraestrutura declarativa gerenciada por meio de repositórios controlados por versão, enquanto o DevOps CI/CD se concentra em fluxos de trabalho automatizados para entrega de aplicativos.

  • Artefatos de implantação: A seleção de artefatos de implantação desempenha um papel crucial na definição da estrutura de implantação. Arquivos YAML, arquivos de manifesto, gráficos Helm e configurações Kustomize representam várias abordagens para especificar e personalizar configurações de implantação, cada uma com seus pontos fortes e casos de uso.

  • Autenticação e autorização da carga de trabalho: Dependendo da configuração, os métodos de autenticação e autorização podem ser diferentes. Você pode usar funções de gerenciamento de identidade e acesso (IAM) da Amazon Web Services (AWS), mecanismos de identidade de carga de trabalho ou cadeias de conexão para controle de acesso.

  • Monitoramento: A implementação de soluções de monitoramento é um aspeto crítico que pode envolver várias ferramentas e metodologias para garantir o desempenho e a integridade das cargas de trabalho implantadas. Para obter mais informações sobre como o monitoramento AKS se compara ao EKS, consulte Monitoramento e registro em log do Kubernetes.

Antes de iniciar a migração, analise e considere as seguintes orientações gerais e recursos de práticas recomendadas:

  • Analise as práticas recomendadas do operador de cluster e do desenvolvedor.
  • Defina a estratégia de monitoramento e alerta para garantir que o aplicativo esteja funcionando conforme o esperado.
  • Defina os requisitos de segurança e conformidade para o aplicativo e o ambiente AKS.
  • Defina as políticas de controle de acesso e como elas são aplicadas. Identificar quaisquer padrões de conformidade que devem ser cumpridos.
  • Defina o plano de recuperação de desastres e continuidade de negócios para o ambiente AKS e o aplicativo.
  • Defina as políticas e os procedimentos de backup e restauração. Identifique o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação).
  • Identifique quaisquer riscos ou desafios que possam ser encontrados durante a implantação.
  • Teste a funcionalidade para garantir que o aplicativo funcione conforme o esperado antes de redirecionar o tráfego ao vivo para o novo cluster AKS.

Considerações sobre migração de carga de trabalho

Esta seção analisa algumas coisas que você deve considerar antes de migrar suas cargas de trabalho do Amazon EKS para o AKS.

Compreender seu ambiente existente do Amazon EKS

Analise o ambiente EKS existente para entender a arquitetura, os recursos e as configurações atuais.

  • Revise a configuração do EKS: avalie a configuração do cluster EKS, como tipos de nós, número de nós, versão do Kubernetes e política de suporte e configuração de escala.

    Nota

    O EKS permite a criação de imagens AMI personalizadas para nós EKS. O AKS não permite o uso de imagens de nó personalizadas. Se sua implantação exigir personalização de nó, você poderá aplicar a personalização de kubelet e/ou DaemonSets para personalizar seus nós.

  • Revisar cargas de trabalho de aplicativos: identifique todas as cargas de trabalho do Kubernetes em execução no cluster EKS, incluindo implantações, serviços, conjuntos com monitoração de estado, configurações de entrada e declarações de volume persistentes. Certifique-se de ter uma lista completa de aplicativos e seus recursos associados.

  • Verifique as dependências: identifique quaisquer dependências nos serviços da AWS específicos do EKS.

    Serviço do AWS Dependency
    Gerenciador Secreto da AWS Azure Key Vault
    Agente de serviço do AWS Guard Microsoft Defender para contêineres
    Agente de identidade EKS Pod Identidade da carga de trabalho do Microsoft Entra ID
    Drivers Amazon Elastic File System (EFS) ou Elastic Block Store (EBS) Container Storage Interface (CSI) AKS CSI Drivers

  • Backup do cluster EKS: você pode usar uma ferramenta que não seja da Microsoft, como o Velero, para fazer backup e migrar recursos do Kubernetes e volumes persistentes.

Preparar o ambiente do Azure AKS

O Amazon virtual private cloud (VPC) Container Networking Interface (CNI) é o plug-in de rede padrão suportado pelo EKS. Um cluster AKS suporta vários plugins de rede e métodos para implantar um cluster em uma rede virtual, incluindo:

Para preparar o cluster AKS, siga estes passos:

  1. Crie um novo cluster AKS no Azure, definindo as configurações de rede desejadas para corresponder às suas necessidades.
  2. Revise seus manifestos do Kubernetes e arquivos YAML usados no EKS. Verifique se há alguma possível incompatibilidade de versão da API do Kubernetes ou configurações específicas do EKS que o AKS não suporta.
  3. Certifique-se de que as imagens do Docker e o local do registro da imagem do contêiner estejam acessíveis a partir do cluster AKS. Verifique a conectividade de rede e todas as configurações de autenticação e autorização necessárias para acessar as imagens.

Seguindo estas etapas, você pode criar com sucesso um cluster AKS e garantir a compatibilidade para seus manifestos do Kubernetes e imagens do Docker, garantindo um processo de migração suave do EKS para o AKS.

Descrição geral da migração

A migração do Amazon EKS para o AKS envolve várias etapas, como:

  • Migração de imagens de contêiner: migrar imagens de contêiner é uma etapa crucial ao mudar de EKS para AKS. Você pode usar ferramentas como kubectl, Docker ou registros de contêiner para exportar e importar imagens.

    1. Exporte imagens do EKS.
    2. Configure um Registro de Contêiner do Azure e anexe-o ao AKS, caso ainda não o tenha feito.
    3. Envie imagens por push para o Registro de contêiner.

    As imagens de contêiner também podem ser importadas para o Registro de Contêiner diretamente de um repositório público ou privado que não seja do Azure. Para obter mais informações, consulte Importar imagens de contêiner.

  • Migração de manifesto do Kubernetes: o AKS usa o manifesto do arquivo YAML do Kubernetes para definir objetos do Kubernetes. As implantações são normalmente criadas e gerenciadas com kubectl create ou kubectl apply. Crie uma implantação definindo um arquivo de manifesto no formato YAML. Para obter mais informações, consulte este exemplo de manifesto AKS. Você pode saber mais sobre como os arquivos YAML funcionam no Kubernetes examinando Implantações e manifestos YAML.

  • Migração de dados: planeje cuidadosamente a migração de aplicativos com monitoração de estado para evitar perda de dados ou tempo de inatividade inesperado. Para obter mais informações, consulte a seção Considerações sobre migração de carga de trabalho com monitoração de estado.

Considerações sobre migração de carga de trabalho sem estado

A migração dos manifestos do Kubernetes envolve a adaptação da configuração para funcionar no ambiente do Azure, incluindo estas etapas:

  1. Atualizar manifestos: atualize seus manifestos do Kubernetes para usar os novos locais de imagem no Registro de contêiner. Substitua as referências de imagem em seus arquivos YAML pelo caminho do Registro de contêiner.

    1. Analise seus arquivos de manifesto do Kubernetes existentes para configurações específicas da AWS, como funções de VPC e IAM.
    2. Analise as funções do IAM EKS associadas a nós, contas de serviço e outros recursos. Mapeie-o com funções equivalentes de controle de acesso baseado em função (RBAC) do Azure AKS. Para obter mais informações, consulte Identidade e acesso à carga de trabalho do Kubernetes.
    3. Modifique os arquivos de manifesto para substituir configurações específicas da AWS por configurações específicas do Azure, como anotações.

  2. Aplicar manifestos ao AKS:

    1. Conecte-se ao AKS Cluster.
    2. Aplique os arquivos de manifesto do Kubernetes modificados usando kubectl apply -fo .

Considerações sobre migração de carga de trabalho com monitoração de estado

Se seus aplicativos usam Volumes Persistentes (PVs) ou PVCs (Declarações de Volume Persistentes) para armazenamento de dados, certifique-se de fazer backup desses dados. Você pode usar ferramentas como o Velero para executar backups de cluster, inclusive para dados PVs e PVCs. Para obter mais informações, consulte Backup e restauração dos recursos de cluster do Amazon EKS usando o Velero.

Os aplicativos com monitoração de estado geralmente têm requisitos persistentes de armazenamento de dados, o que aumenta a complexidade do processo de migração. Para obter uma comparação dos recursos de armazenamento do Amazon EKS e do AKS, consulte Opções de armazenamento para um cluster do Kubernetes.

Siga estas etapas para fazer backup de dados persistentes:

  1. Configure o Velero no cluster AKS e EKS .
  2. Execute um backup do cluster EKS.
  3. Copie o backup do Velero do bucket do S3 para o armazenamento de blob do Azure, usando o comando az copy.
  4. Como AKS e EKS podem usar diferentes storageClassNames para as declarações de volume persistente, crie um configMap que traduza a origem storageClassNames para um nome de classe compatível com AKS. Você pode ignorar esta etapa se estiver usando a mesma solução de armazenamento nos clusters EKS e AKS Kubernetes.
  5. Restaure o backup para o AKS (usando o comando Velero restore).
  6. Aplique as alterações necessárias aos objetos restaurados, como referências a imagens de contêiner no Amazon Elastic Container Registry (ECR) ou acesso a segredos.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

  • Dixit Arora - Brasil | Engenheiro de Clientes Sénior, ISV DN CoE
  • Ketan Chawda - Brasil | Engenheiro de Clientes Sénior, ISV DN CoE

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos