View a markdown version of this page

Restaurar um cluster do Amazon EKS - AWS Backup
Backups do Amazon EKS

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Restaurar um cluster do Amazon EKS

Você pode restaurar os backups do cluster EKS usando o AWS Backup console ou a CLI. Os backups EKS são pontos de recuperação compostos que incluem tanto o estado do cluster EKS quanto os backups de volume persistente.

AWS Backup oferece suporte a várias experiências de restauração, incluindo restaurações granulares em nível de namespace. As restaurações não são destrutivas e não substituirão nenhum objeto Kubernetes existente no cluster EKS de destino. As restaurações também não substituirão as versões Kubernetes do cluster EKS de destino.

Os backups do EKS precisam ser restaurados em um cluster EKS de destino, ou seja, um cluster do Amazon EKS que foi pré-provisionado. Como parte do fluxo de trabalho de restauração, você pode optar por criar um novo cluster EKS que AWS Backup será criado em seu nome.

nota

AWS Backup fornecerá um conjunto limitado de opções para criar um novo cluster EKS como parte de uma restauração. Para todas as funcionalidades de criação de clusters EKS, os clientes podem criar um novo cluster EKS usando o console EKS ou as APIs e selecioná-lo como seu destino de restauração.

Recursos de restauração para o Amazon EKS

Tipo de restauração Destino da restauração Restaurar o comportamento
Restauração de cluster existente Restaurar no cluster EKS de origem ou no cluster EKS existente Restaura todos os recursos e volumes persistentes do Kubernetes nos clusters EKS existentes. Todas as restaurações não são destrutivas e os objetos existentes não são sobrescritos. Para objetos que são ignorados, você pode se inscrever nas notificações do SNS https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-notifications.html
Nova restauração de cluster Cria um novo cluster Amazon EKS como parte da restauração do EKS A restauração cria um novo cluster EKS e restaura todos os recursos e volumes persistentes do Kubernetes no cluster recém-criado
Restauração de namespace Cluster Amazon EKS existente Restaura somente namespaces especificados, seus recursos Kubernetes e as restaurações de armazenamento persistente correspondentes não são destrutivas e os objetos existentes não são sobrescritos. Para objetos que são ignorados, você pode se inscrever nas Notificações do SNS
Restauração persistente do armazenamento Depende do armazenamento persistente Restaure o armazenamento persistente individual como restaurações independentes. Consulte Comportamento de restauração do Amazon EBS, Amazon S3 e Amazon EFS.

Permissões

As permissões necessárias dependem do tipo de restauração e do destino de destino.

  • AWS Backup A política gerenciada da AWSBackupServiceRolePolicyForRestores contém as permissões necessárias para restaurar seu cluster Amazon EKS e o armazenamento persistente EBS e EFS.

  • Se o seu cluster EKS contiver um bucket do S3 ou se você estiver restaurando o ponto de recuperação secundário do S3 sozinho, você precisará garantir que as seguintes políticas ou permissões sejam atribuídas à sua função. AWSBackupServiceRolePolicyForS3Restore

Considerações antes da restauração

Antes de iniciar um trabalho de restauração do EKS, revise o seguinte. Se você estiver restaurando um backup do EKS que foi copiado em uma conta ou região, certifique-se de verificar essas considerações antes das restaurações para evitar falhas na restauração.

  1. Funções do IAM: ao restaurar em um cluster diferente, as funções do IAM usadas no cluster de origem (como Pod identity, IRSA). As configurações do provedor OIDC (etc.) devem estar presentes na conta/região como o cluster de destino.

  2. Garanta a versão e a compatibilidade do EKS: as versões da API dos objetos que você deseja restaurar devem ser da mesma versão (ou a mais próxima possível) e ter suporte no novo cluster. AWS Backup realizará a melhor restauração entre as versões do EKS, embora possam surgir problemas de compatibilidade ao restaurar entre versões significativamente diferentes.

  3. Classes de armazenamento correspondentes: para restaurações em um cluster EKS existente, certifique-se de que os complementos apropriados do CSI Storage Driver estejam instalados antes da restauração

  4. S3 Buckets: Ao restaurar um cluster EKS com S3 Buckets, certifique-se de que seu bucket S3 esteja versionado e acessível na conta ou região de destino.

  5. Repositório de imagens: ao restaurar um cluster EKS, certifique-se de que a conta ou região do cluster EKS de destino tenha acesso às imagens que estão sendo referenciadas como parte da restauração. Verifique se seu registro tem permissões suficientes de política entre regiões/contas.

  6. Grupos de segurança: os grupos de segurança devem ser pré-criados para ALB, Pod Identities, EKS Node Groups etc. na conta e região de destino se criar um novo cluster EKS como parte de sua restauração

  7. Zonas de disponibilidade e nós do EBS: as zonas de disponibilidade em que você recupera seus volumes do EBS devem ser mapeadas para a zona de disponibilidade de um nó EKS existente

  8. Non-destructive restaurações: todas as restaurações do EKS não serão destrutivas e não substituirão os objetos Kubernetes da restauração de destino.

  9. Ativar registros de auditoria do EKS: habilite os registros de auditoria do EKS para registro adicional e solução de problemas antes da restauração. Você também pode se inscrever nas notificações do SNS para notificar sobre objetos ignorados ou com falha na restauração.

  10. Novo buffer de restauração de criação de cluster EKS: ao criar um novo cluster EKS durante a restauração, AWS Backup introduz um buffer de 15 minutos após o cluster EKS atingir um estado disponível, mas antes de criar qualquer recurso EKS adicional. Esse buffer garante que todos os componentes subjacentes do EKS sejam totalmente inicializados antes que os recursos dependentes sejam criados.

  11. Dados do usuário no modelo de execução: ao criar um grupo de nós usando um modelo de execução, não especifique spec.cluster na seção de dados do usuário do modelo de execução. O Amazon EKS injeta automaticamente os parâmetros de identidade do cluster (apiServerEndpointcertificateAuthority,, eserviceIpv4Cidr) e os mescla com qualquer configuração adicional definida nos dados do usuário.

Configurações do EKS

Ao restaurar o Amazon composto AWS Backup, você escolhe o tipo de restauração e o destino de destino. Você pode optar por restaurar para o cluster EKS de origem, um cluster EKS existente ou criar um novo cluster EKS como destino da restauração. Para novos clusters EKS, você pode escolher usar as mesmas configurações de infraestrutura existentes (por exemplo, VPC, sub-redes) do cluster de backup ou configurar novas. AWS Backup foi projetado para realizar uma restauração não destrutiva que não substitui os recursos existentes.

Para restaurações de namespaces, você pode especificar até 5 namespaces para restaurar seletivamente. Somente recursos com escopo de namespace são restaurados, enquanto recursos com escopo de cluster são excluídos, exceto os volumes persistentes relacionados.

Como configuração avançada, você pode optar por alterar a ordem de restauração dos objetos do Kubernetes. Por padrão, AWS Backup restaurará todos os objetos do Kubernetes na seguinte ordem:

Recursos do Kubernetes com escopo de cluster

  1. Definições de recursos personalizados

  2. Namespaces (o namespace em si, não os recursos dentro desse namespace)

  3. StorageClasses

  4. PersistentVolumes

Recursos do Kubernetes com escopo de namespace

  1. PersistentVolumeClaims

  2. Segredos

  3. ConfigMaps

  4. ServiceAccounts

  5. LimitRanges

  6. Pods

  7. ReplicaSets

Configurações de armazenamento persistente

Como parte da restauração composta de backup do Amazon EKS, a segunda etapa será configurar suas configurações de armazenamento persistente. Isso variará com base no armazenamento persistente do backup como parte do seu cluster EKS.

Para os snapshots do Amazon EBS, é necessário fornecer uma zona de disponibilidade, na qual o volume do Amazon EBS será restaurado e criado. AWS Backup Em seguida, tentará criar o pod EKS na mesma zona de disponibilidade selecionada para que seu volume possa ser remontado no cluster EKS como parte da restauração.

Como parte da restauração, AWS Backup remontará seus volumes do Amazon EBS e buckets do Amazon S3 em seu cluster EKS restaurado. Os sistemas de arquivos do Amazon EFS são restaurados em prefixos aleatórios e exigem a criação manual de pontos de acesso após a restauração para serem remontados em seu cluster EKS. AWS Backup não cria pontos de acesso nem monta alvos em seu nome, consulte as orientações aqui para pontos de acesso e monta alvos.

Procedimento de restauração do Amazon EKS

Siga estas etapas para restaurar os backups do Amazon EKS usando o AWS Backup console ou AWS CLI:

Console
Para restaurar seu cluster Amazon EKS

  1. Abra o AWS Backup console em https://console.aws.amazon.com/backup.

  2. No painel de navegação, selecione Cofres de Backup.

  3. Escolha o cofre de backup que contém seu backup do Amazon EKS e selecione o ponto de recuperação para seu backup do Amazon EKS.

  4. Escolha Restore.

  5. No painel Opções de restauração, escolha seu tipo de restauração:

    • Restaurar cluster EKS completo - Restaura todo o ponto de recuperação composto do Amazon EKS

    • Selecionar namespaces para restaurar - Restaura até cinco namespaces específicos

  6. Configure o destino de destino:

    • Para restauração de cluster, escolha criar um novo cluster ou usar um cluster existente

    • Para novos clusters, especifique o nome do cluster, a versão do Kubernetes, a configuração da VPC, as funções do IAM, as sub-redes, os grupos de segurança adicionais, as configurações do grupo de nós, os perfis de fargate e as funções do IAM da identidade do pod

    • Para clusters existentes, selecione o cluster de destino no menu suspenso

    • Para restauração de namespaces, especifique os nomes do cluster e do namespace de destino

  7. Opcionalmente, defina as configurações avançadas para a ordem de restauração personalizada dos recursos do Kubernetes.

  8. Escolha o perfil de restauração do IAM para o trabalho. Se não estiver usando a função padrão, certifique-se de que a função selecionada inclua a PassRole permissão iam:.

    nota

    Se o gerente de funções estiver habilitado em sua conta, AWS Backup selecionará a função de serviço padrão para você e uma opção Personalizar estará disponível. Consulte mais informações em Criar um perfil do IAM no Guia do usuário do IAM.

  9. Escolha Restaurar backup.

AWS CLI

Use o aws backup start-restore-job comando com os EKS-specific metadados da Amazon.

Os metadados necessários dependem do seu tipo de restauração. Todas as operações de restauração exigem o clusterName parâmetro.

Restaure os pontos de recuperação do Amazon EKS por meio AWS CLI

Uso StartRestoreJob. Você pode especificar os seguintes metadados durante as restaurações do Amazon EKS:

Metadados obrigatórios:

  • clusterName- Nome do cluster a ser restaurado

Metadados opcionais:

  • newCluster- (true/false) Se devemos criar um novo cluster EKS durante a restauração. Se newCluster for “verdadeiro”, os seguintes campos de metadados se aplicam:

    • eksClusterVersion- Versão K8s desejada do cluster se quiser aumentar a versão do cluster durante a restauração

    • clusterRole- O ARN da função IAM a ser anexado ao cluster EKS criado

    • encryptionConfigProviderKeyArn- Especifique o ARN da chave KMS para criptografar o cluster de destino. Ela pode ser a chave KMS do cluster de origem ou uma chave KMS diferente. Uma chave KMS diferente deve ser fornecida ao realizar a restauração entre regiões ou contas. Omita totalmente esses metadados se o cluster de origem não estiver criptografado.

    • clusterVpcConfig- VPC/Networking configuração para o cluster EKS criado. Esse campo tem os seguintes campos aninhados:

      • vpcId- A VPC associada ao seu cluster

      • subnetIds [Required]- As sub-redes associadas ao seu cluster

      • securityGroupIds [Required]- Os grupos de segurança adicionais associados ao seu cluster

    • nodeGroups- Os grupos de nós gerenciados a serem criados no cluster EKS. O NodeGroups for restore deve ter todos os mesmos grupos de nós do momento do backup e ter um nó correspondenteGroupId.

      • nodeGroupId [Required]- O ID do grupo de nós

      • subnetIds [Required]- As sub-redes que foram especificadas para o grupo Auto Scaling associado ao seu grupo de nós

      • instanceTypes- Se o grupo de nós não foi implantado com um modelo de execução, esse é o tipo de instância associado ao grupo de nós

      • nodeRole [Required]- A função do IAM associada ao seu grupo de nós

      • securityGroupIds- Os IDs dos grupos de segurança aos quais é permitido o acesso SSH aos nós

      • remoteAccessEc2SshKey- O nome da chave SSH do Amazon EC2 que fornece acesso para comunicação SSH com os nós no grupo de nós gerenciados

      • launchTemplateId- Especifique o ID do modelo de lançamento para criar o grupo de nós. Isso pode ser o ID do modelo de execução do cluster de origem ou um ID de modelo de execução diferente. Se o modelo de execução do cluster de origem contiver um endpoint codificado que aponte para o próprio cluster de origem, você deverá fornecer um ID de modelo de execução diferente. Omita totalmente esses metadados se o cluster de origem não usar um modelo de execução.

      • launchTemplateVersion- Versão do modelo de lançamento associada ao ID do modelo de lançamento especificado.

    • fargateProfiles- Os perfis Fargate a serem criados no cluster EKS. Os perfis Fargate para restauração devem ter todos os mesmos perfis Fargate do momento do backup e ter o nome correspondente.

      • name [Required]- O nome do perfil do Fargate

      • subnetIds- Os IDs das sub-redes nas quais lançar um pod

      • podExecutionRoleArn [Required]- O ARN da função IAM da função de execução do pod a ser usado em um pod que corresponda aos seletores no perfil do Fargate

    • podIdentityAssociations- As associações de identidade de pod a serem criadas no cluster EKS

      • associationId- O ID da Pod Identity Association

      • roleArn- A função IAM ARN para a Pod Identity Association

  • kubernetesRestoreOrder- Substitua a ordem em que os manifestos do Kubernetes são restaurados. Esse pedido terá precedência sobre o pedido padrão de restauração do serviço. Isso segue o formato: group/version /kind ou version/kind

    Ex: ["v1/persistentvolumes","v1/pods","customresource/v2/custom"]

  • namespaceLevelRestore- (true/false) Se você quiser realizar uma restauração em nível de namespace

  • namespaces- Uma lista de namespaces a serem restaurados se o namespace LevelRestore for “verdadeiro”. Pode fornecer até 5 namespaces para restauração.

    Ex: ["ns-1","ns-2","ns-3","ns-4","ns-5"]

  • restoreKubernetesManifestsOnly- (true/false) Se você quiser restaurar apenas os arquivos de manifesto do Kubernetes e nenhum sistema de armazenamento persistente (EBS, S3, EFS etc.)

  • nestedRestoreJobs- Restaure a configuração de metadados de todos os pontos de recuperação aninhados dos sistemas PersistentVolume de armazenamento no ponto de recuperação composto. Este é um mapa de RecoveryPointArn: RestoreMetadata desse ponto de recuperação

Restaurar para um cluster existente 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false"}' \
    --resource-type "EKS"

Restaure namespaces específicos em um cluster existente: 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","namespaces":"[\"ns-1\",\"ns-2\",\"ns-3\",\"ns-4\",\"ns-5\"]"}' \
    --resource-type "EKS"

Restaure volumes persistentes aninhados em um cluster existente: 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"existing-cluster","newCluster":"false","namespaceLevelRestore":"true","nestedrestorejobs":"{\"arn:aws:ec2:us-west-2::snapshot/snap-abc123\":\"{\\\"AvailabilityZone\\\":\\\"us-west-2a\\\"}\",\"arn:aws:backup:us-west-2:123456789012:recovery-point:fa71a304-2555-4c37-8128-f154b9578032\":\"{\\\"DestinationBucketName\\\":\\\"bucket-name\\\"}\"}"}' \
    --resource-type "EKS"

Restaurar para um novo cluster 

aws backup start-restore-job \
    --recovery-point-arn "arn:aws:backup:us-west-2:123456789012:recovery-point:composite:eks/my-cluster-20240115" \
    --iam-role-arn "arn:aws:iam::123456789012:role/AWSBackupDefaultServiceRole" \
    --metadata '{"clusterName":"new-cluster","newCluster":"true","clusterRole":"arn:aws:iam::123456789012:role/EKSClusterRole","eksClusterVersion":"1.33","encryptionConfigProviderKeyArn":"arn:aws:kms:us-west-2:123456789012:key/ecb2b326-784d-4ec0-8d07-20ab826b5a13","clusterVpcConfig":"{\"vpcId\":\"vpc-1234\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"securityGroupIds\":[\"sg-123\"]}","nodeGroups":"[{\"nodeGroupId\":\"nodegroup-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"nodeRole\":\"arn:aws:iam::123456789012:role/EKSNodeGroupRole\",\"instanceTypes\":[\"t3.small\"],\"launchTemplateId\":\"lt-0b13949aae3f2b867\",\"launchTemplateVersion\":\"1\"}]","fargateProfiles":"[{\"name\":\"fargate-profile-1\",\"subnetIds\":[\"subnet-1\",\"subnet-2\",\"subnet-3\"],\"podExecutionRoleArn\":\"arn:aws:iam::123456789012:role/EKSFargateProfileRole\"}]"}' \
    --resource-type "EKS"

Depois de iniciar o trabalho de restauração, use describe-restore-job para monitorar o progresso:

aws backup describe-restore-job --restore-job-id restore-job-id

Você pode se inscrever em eventos de notificação para restaurar objetos falhados e ignorados. Para obter mais informações, consulte Opções de notificação com AWS Backup.

Mensagens de status de restauração do Amazon EKS

Quando um trabalho de restauração for concluído, você poderá ver as seguintes mensagens de status. A tabela mostra os cenários possíveis e seus valores de status de trabalho correspondentes:

Cenário Status do trabalho Exemplo de mensagem
Todos os objetos restaurados com sucesso CONCLUÍDO —
Um ou mais objetos falharam ao serem restaurados CONCLUÍDO “Falha na restauração de um ou mais objetos do Kubernetes. Para receber um aviso sobre essas falhas, ative as notificações de eventos do SNS.”
A restauração não pôde ser concluída FAILED (detalhes do erro)

Objetos ignorados durante a restauração

Os seguintes objetos do Kubernetes são restaurados da melhor maneira possível. Se não conseguirem restaurar, serão movidos para a lista ignorada. Esses objetos são gerenciados pelo sistema e recriados pelo Kubernetes ou pelo Amazon EKS:

  • FlowSchemas com a apf.kubernetes.io/autoupdate-spec: "true" anotação

  • PriorityLevelConfigurations com a apf.kubernetes.io/autoupdate-spec: "true" anotação

  • O eks-exempt FlowSchema (EKS-managed, faz referência ao isento PriorityLevelConfiguration protegido)

  • O kubernetes serviço no default namespace (endpoint do servidor API)

  • O kube-dns serviço no kube-system namespace (CoreDNS)

Os seguintes objetos do Kubernetes são sempre ignorados durante uma restauração. Esses objetos incluem infraestrutura de nós e componentes de rede. Eles fazem referência ao estado específico do cluster. Os controladores do Kubernetes recriam automaticamente esses objetos quando nós e serviços se tornam ativos no cluster de destino. Se você restaurar esses objetos a partir de um backup, eles poderão causar conflitos ou erros. Esses conflitos ocorrem porque os objetos restaurados fazem referência a recursos que não existem no cluster de destino.

  • Endpoints (v1/endpoints) - Endpoints de rede que definem endereços IP para serviços. O controlador Endpoints os gerencia automaticamente com base nos seletores de serviço.

  • EndpointSlices (discovery.k8s.io/v1/endpointslices) - O EndpointSlice controlador gerencia automaticamente esses objetos.

  • ipAddresses (networking.k8s.io/v1/ipaddresses) - A rede Kubernetes gerencia essas alocações de IP internas do cluster.

  • csinodes (storage.k8s.io/v1/csinodes) - O kubelet cria automaticamente esses objetos quando os drivers CSI se registram em um nó.

  • VolumeAttachments (storage.k8s.io/v1/volumeattachments) - O attach/detach controlador cria automaticamente esses objetos quando os pods precisam de volumes.

Objetos que já existem no cluster de destino também são ignorados. As restaurações do EKS não são destrutivas — os objetos existentes nunca são sobrescritos ou excluídos.

Para receber notificações sobre objetos ignorados ou com falha durante a restauração, assine as notificações de eventos do SNS. Para obter mais informações, consulte Opções de notificação com AWS Backup.

Considerações sobre OIDC e IRSA para restauração entre clusters

Ao restaurar um backup do Amazon EKS em um cluster diferente do de origem, os objetos do Kubernetes que fazem referência ao IAM Roles for Service Accounts (IRSA) retêm o endpoint do provedor OIDC do cluster de origem. Essas referências existem nas anotações da conta de serviço e nas políticas de confiança do IAM. AWS Backup não os atualiza automaticamente durante a restauração.

Se suas cargas de trabalho usam IRSA, uma restauração entre clusters exige:

  • O cluster de destino deve ter um provedor OIDC configurado.

  • Todas as funções do IAM referenciadas pelas contas de serviço do Kubernetes devem ter suas políticas de confiança atualizadas para incluir o endpoint do provedor OIDC do cluster de destino.

  • As anotações da conta de serviço (eks.amazonaws.com/role-arn) ainda farão referência às funções originais — verifique se elas correspondem às funções válidas na conta de destino.

Se essas dependências não forem satisfeitas, os pods não assumirão as funções do IAM após a restauração, e as tarefas de restauração poderão relatar falhas durante a validação.

Recomendação: Para cargas de trabalho que exigem portabilidade de restauração entre clusters ou contas, recomendamos usar o EKS Pod Identity em vez do IRSA. O EKS Pod Identity não depende de provedores OIDC específicos do cluster e simplifica os cenários de restauração entre clusters.