Container Service for Kubernetes:Migração de aplicações entre versões com o centro de backup

Observações

• Os clusters de backup e de restauração devem estar na mesma região. O cluster de backup deve executar o Kubernetes 1.16 ou superior. Para evitar problemas de compatibilidade de versão da API, não use o centro de backup para migrar aplicações de uma versão mais recente do Kubernetes para uma mais antiga.

• O centro de backup não faz backup de recursos em processo de exclusão.

• Durante a restauração de uma aplicação, os recursos são restaurados preferencialmente com a apiVersion recomendada para a versão do Kubernetes do cluster de destino. Se um recurso não tiver uma apiVersion suportada por ambas as versões dos clusters, implante esse recurso manualmente. Exemplos:

  • Um Deployment em um cluster Kubernetes 1.16 suporta as versões de API extensions/v1beta1, apps/v1beta1, apps/v1beta2 e apps/v1. Ao ser restaurado em um cluster Kubernetes 1.28, ele usa apps/v1.

  • Um Ingress em um cluster Kubernetes 1.16 suporta as versões de API extensions/v1beta1 e networking.k8s.io/v1beta1. Não é possível restaurá-lo diretamente em um cluster com Kubernetes 1.22 ou superior.

  Para obter mais informações sobre alterações de API entre versões do Kubernetes, consulte Notas de versão do ACK e Guia de Migração de API Obsoleta.

  Importante

  Em um cluster Kubernetes 1.16, grupos de API como apps e rbac.authorization.k8s.io já suportam a versão v1. Ao migrar aplicações para um cluster Kubernetes 1.28, restaure manualmente recursos como Ingress e CronJob.

Casos de uso

• Migração de aplicações entre plug-ins de armazenamento

  Clusters ACK com Kubernetes 1.20 ou superior não suportam mais o plug-in de armazenamento FlexVolume. Use o centro de backup para migrar aplicações com estado de um cluster FlexVolume para um cluster CSI.

  Nota

  É possível migrar aplicações de clusters que usam o plug-in FlexVolume ou CSI, mas o cluster de restauração deve obrigatoriamente usar o plug-in CSI.

• Troca entre clusters com grande diferença de versão do Kubernetes

  Em alguns cenários, pode ser necessário migrar serviços de um cluster Kubernetes mais antigo (1.16 ou superior) para um novo cluster, por exemplo, ao trocar o plug-in de rede de Flannel para Terway. O centro de backup suporta a migração de aplicações com grandes diferenças de versão e ajusta automaticamente configurações básicas, como a apiVersion nos modelos de aplicação, para corresponder à nova versão do Kubernetes.

Pré-requisitos

• Ativar o Cloud Backup. Ao fazer backup de volumes persistentes NAS, OSS ou de disco local, e em cenários de nuvem híbrida, o centro de backup precisa usar o Cloud Backup para Backup de Arquivos.

• Crie um cluster onde o volume será restaurado. Para garantir o uso de snapshots de instâncias do Elastic Compute Service (ECS) na restauração de dados de disco, atualize a versão do Kubernetes do cluster para 1.18 ou superior. Para mais informações, consulte Criar um cluster gerenciado ACK, Criar um cluster dedicado ACK (descontinuado) ou Criar um cluster registrado ACK One.

  Importante

  • O cluster de restauração deve usar o plug-in Container Storage Interface (CSI). A restauração de aplicações não é suportada em clusters que utilizam FlexVolume ou que usam csi-compatible-controller juntamente com FlexVolume.

  • O centro de backup faz backup e restaura aplicações. Antes de executar uma tarefa de restauração, instale e configure os componentes do sistema no cluster de restauração. Exemplo:

    • aliyun-acr-credential-helper: Conceda permissões ao cluster de restauração e configure o acr-configuration.

    • alb-ingress-controller: Configure um ALBConfig.

• Conectar-se ao cluster usando kubectl.

Fluxo de trabalho de migração

O fluxo de trabalho de migração varia conforme o plug-in de armazenamento do cluster de backup. As figuras a seguir detalham esses processos.

Cluster de backup sem aplicações de armazenamento

Cluster de backup usando FlexVolume

Cluster de backup usando CSI

Procedimento

Esta seção apresenta um exemplo de migração de aplicações, configurações e dados de volume de um cluster ACK com FlexVolume e Kubernetes 1.16 para um cluster ACK com CSI e Kubernetes 1.28. A migração utiliza alteração da fonte de dados ou fonte de dados inalterada. Caso deseje migrar aplicações que não utilizam armazenamento ou se o seu cluster de backup já usar o plug-in CSI, ignore as etapas marcadas como Opcional.

kubectl patch pv/<pv-name> --type='json' -p '[{"op":"replace","path":"/spec/persistentVolumeReclaimPolicy","value":"Retain"}]'

Preparar o ambiente

Etapa 1: Implantar uma aplicação de teste

1. Execute o comando a seguir para implantar um volume de disco provisionado dinamicamente.

   Substitua alicloud-disk-topology pelo nome da StorageClass de disco padrão do plug-in FlexVolume no seu cluster.

   cat << EOF | kubectl apply -f -
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: disk-essd
   spec:
     accessModes:
       - ReadWriteOnce
     storageClassName: alicloud-disk-topology
     resources:
       requests:
         storage: 20Gi
   EOF

2. Execute o comando a seguir para implantar um volume NAS provisionado estaticamente.

   Substitua server pelo ponto de montagem do sistema de arquivos NAS na sua conta.

   cat << EOF | kubectl apply -f -
   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-nas
   spec:
     capacity:
       storage: 5Gi
     storageClassName: nas
     accessModes:
       - ReadWriteMany
     flexVolume:
       driver: "alicloud/nas"
       options:
         server: "1758axxxxx-xxxxx.cn-beijing.nas.aliyuncs.com"
         vers: "3"
         options: "nolock,tcp,noresvport"
   ---
   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: pvc-nas
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: nas
     resources:
       requests:
         storage: 5Gi
   EOF

3. Execute o comando a seguir para implantar a aplicação. Esta aplicação monta tanto os volumes de disco quanto os volumes NAS das etapas anteriores.

   A apiVersion no código abaixo utiliza extensions/v1beta1. Esta apiVersion foi descontinuada em clusters da versão 1.28.

   cat << EOF | kubectl apply -f -
   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx
           ports:
           - containerPort: 80
           volumeMounts:
             - name: nas
               mountPath: /cold
             - name: disk
               mountPath: /hot
         volumes:
           - name: nas
             persistentVolumeClaim:
               claimName: pvc-nas
           - name: disk
             persistentVolumeClaim:
               claimName: disk-essd   
   EOF

4. Execute o comando a seguir para verificar se a aplicação implantada foi iniciada.

   kubectl get pod -l app=nginx

   Saída esperada:

   NAME                    READY   STATUS    RESTARTS   AGE
   nginx-5ffbc895b-xxxxx   1/1     Running   0          2m28s

Etapa 2: Instalar o centro de backup

1. No cluster de backup, instale o componente de serviço de backup migrate-controller.

   Nota

   • Para clusters com Kubernetes 1.16 ou superior, instale diretamente o componente de serviço de backup V1.7.6 ou superior a partir do marketplace de componentes.

   • Se o seu cluster de backup for um Cluster Dedicado ACK ou um cluster registrado, ou se utilizar um plug-in de armazenamento diferente do CSI (como FlexVolume), configure permissões adicionais. Para mais informações, consulte Cluster registrado.

2. (Opcional) Se o seu cluster for FlexVolume, execute o comando a seguir para confirmar que as permissões necessárias estão configuradas.

   kubectl -n csdr get secret alibaba-addon-secret

3. (Opcional) Se o seu cluster for FlexVolume, execute o comando a seguir para adicionar a variável de ambiente USE_FLEXVOLUME ao migrate-controller no namespace kube-system.

   Importante

   Em um cluster FlexVolume, após a instalação do componente de serviço de backup migrate-controller, o pod migrate-controller encerra inesperadamente, e a abertura da página Application Backup do cluster retorna um erro 404. Nesse caso, edite o arquivo YAML do componente para adicionar a variável de ambiente USE_FLEXVOLUME.

   kubectl -n kube-system patch deployment migrate-controller --type json -p '[{"op":"add","path":"/spec/template/spec/containers/0/env/-","value":{"name":"USE_FLEXVOLUME","value":"true"}}]'

4. Execute os comandos a seguir para confirmar que o componente de serviço de backup está funcionando corretamente.

   kubectl -n kube-system get pod -l app=migrate-controller
   kubectl -n csdr get pod 

   Saída esperada:

   NAME                                  READY   STATUS    RESTARTS   AGE
   migrate-controller-6c8b9c6cbf-967x7   1/1     Running   0          3m55s
   NAME                               READY   STATUS    RESTARTS   AGE
   csdr-controller-69787f6dc8-f886h   1/1     Running   0          3m39s
   csdr-velero-58494f6bf4-52mv6       1/1     Running   0          3m37s

Etapa 3: Criar um backup

1. Na mesma região do cluster de backup, crie um Bucket OSS nomeado no formato cnfs-oss-* para armazenar os backups. Para mais informações, consulte Criar bucket.

   Nota

   Clusters gerenciados ACK possuem permissões para Buckets OSS cujos nomes começam com cnfs-oss-* por padrão. Se o formato de nomenclatura do seu bucket não atender aos requisitos, configure permissões adicionais. Para mais informações, consulte Instalar componentes e configurar permissões no console.

2. Criar um cofre de backup.

3. Execute o comando a seguir para criar uma tarefa de backup imediato.

   Para informações sobre como definir configurações de backup no console ACK, consulte Fazer backup e restaurar aplicações em um cluster. Esta etapa fornece a configuração recomendada para o cenário de exemplo. Ajuste as configurações conforme o seu cenário específico.

   cat << EOF | kubectl apply -f -
   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationBackup
   metadata:
     annotations:
       csdr.alibabacloud.com/backuplocations: '{"name":"<your-backup-vault-name>","region":"<your-region-id>","bucket":"<your-oss-bucket-name>","provider":"alibabacloud"}'
     labels:
       csdr/schedule-name: fake-name
     name: <your-backup-name>
     namespace: csdr
   spec:
     excludedNamespaces:
     - csdr
     - kube-system
     - kube-public
     - kube-node-lease
     excludedResources:
     - storageclasses
     - clusterroles
     - clusterrolebindings
     - events
     - persistentvolumeclaims
     - persistentvolumes
     includeClusterResources: true
     pvBackup:
       defaultPvBackup: true
     storageLocation: <your-backup-vault-name>
     ttl: 720h0m0s
   EOF

   Parâmetro	Descrição
   excludedNamespaces	Namespaces a serem excluídos do backup. Recomendamos excluir os seguintes namespaces: csdr: Namespace de trabalho do centro de backup. O centro de backup possui lógica de sincronização entre clusters. Não faça backup manual de tarefas, como backup ou restauração, no namespace csdr. Essa ação pode causar comportamento inesperado. kube-system, kube-public e kube-node-lease são namespaces padrão em clusters ACK. Eles não podem ser facilmente restaurados entre clusters devido a diferenças nos parâmetros e configurações do cluster.
   excludedResources	Recursos a serem excluídos. Configure este parâmetro conforme suas necessidades de negócio.
   includeClusterResources	Define se deve fazer backup de recursos no nível do cluster, como StorageClasses, CRDs e webhooks. true: Faz backup de todos os recursos no nível do Cluster. false: Faz backup apenas de recursos no nível do Cluster referenciados por recursos no nível de Namespace no namespace selecionado. Por exemplo, ao fazer backup de um Pod, se a ServiceAccount referenciada for autorizada por uma ClusterRole, a ClusterRole é incluída automaticamente no backup. Ao fazer backup de um CR, o CRD também é incluído automaticamente. Nota Por padrão, IncludeClusterResources é definido como false para tarefas de backup criadas no console ACK.
   defaultPvBackup	Define se deve fazer backup dos dados de volume. true: Faz backup da aplicação e dos dados nos volumes utilizados pelos Pods em execução. false: Faz backup apenas da aplicação. Importante Para clusters que executam Kubernetes e CSI nas versões 1.18 ou superior, o centro de backup utiliza snapshots do ECS para fazer backup de dados de disco por padrão. Para outros tipos de armazenamento ou para dados de disco em clusters com versões do Kubernetes a partir de 1.16 até (mas não incluindo) 1.18, o Cloud Backup é utilizado. Para volumes não utilizados por pods em execução, utilize apenas o método de fonte de dados inalterada. Isso requer a criação manual de um PV e PVC estáticos no novo cluster, especificando a fonte de dados original, como um ID de disco ou um bucket OSS. Se sua aplicação exigir forte consistência de dados, pause a escrita de dados durante o período de backup. Alternativamente, escolha o método de fonte de dados inalterada e faça backup apenas da aplicação.

4. Execute o comando a seguir para consultar o status da tarefa de backup.

   kubectl -ncsdr describe applicationbackup <your-backup-name>

   Na saída esperada, o parâmetro Phase de Status muda para Completed, indicando que a tarefa de backup foi criada com sucesso.

5. Execute os comandos a seguir para confirmar a lista de recursos deste backup.

   kubectl -ncsdr get pod | grep csdr-velero
   kubectl -ncsdr exec -it <csdr-velero-pod-name> -- /velero describe backup <your-backup-name> --details

   Verifique na lista se há recursos que não foram incluídos no backup e ajuste a configuração para executar o backup novamente.

   Resource List:
     apiextensions.k8s.io/v1/CustomResourceDefinition:
       - volumesnapshots.snapshot.storage.k8s.io
     v1/Endpoints:
       - default/kubernetes
     v1/Namespace:
       - default
     v1/PersistentVolume:
       - d-2ze88915lz1il01v1yeq
       - pv-nas
     v1/PersistentVolumeClaim:
       - default/disk-essd
       - default/pvc-nas
     v1/Secret:
       - default/default-token-n7jss
       - default/oss-secret
       - default/osssecret
     v1/Service:
       - default/kubernetes
     v1/ServiceAccount:
       - default/default
     ...

Etapa 4: Instalar o centro de backup

1. Instale o centro de backup no cluster de restauração. Para mais informações, consulte Etapa 2: Instalar o centro de backup.

2. Associe o cofre de backup criado ao cluster de restauração.

   1. Faça login no console ACK.

   2. Na página Clusters, clique em Operations > > > Application Backup.

   3. Na página Application Backup, clique em Restore.

   4. Selecione o Backup Vault usado para o backup, clique em Initialize Backup Vault e aguarde a sincronização do backup com este cluster.

(Opcional) Etapa 5: Criar PVCs e PVs manualmente

Na maioria dos cenários, basta seguir a Etapa 6 para criar uma tarefa de restauração diretamente no cluster de restauração. O componente do centro de backup gera automaticamente as reivindicações de armazenamento e volumes com base no backup.

Quando o centro de backup executa uma tarefa de restauração, ele ignora a restauração de PVCs e PVs com os mesmos nomes para proteger os dados existentes. Isso significa que ele não os recria nem sobrescreve os dados dentro dos volumes. Portanto, nos cenários a seguir, pré-crie os PVCs e PVs antes da tarefa de restauração para obter uma recuperação mais flexível:

• Você fez backup de volumes, mas alguns contêm dados que não precisam ser migrados, como logs. Pré-crie volumes vazios.

• Você fez backup de volumes, mas volumes no cluster de backup que não são usados por pods em execução também precisam ser migrados para o cluster de restauração.

• Você não fez backup de volumes e a lista excludedResources inclui persistentvolumeclaims e persistentvolumes, ou a migração envolve mover uma aplicação de um cluster FlexVolume para um cluster CSI.

Siga as etapas específicas abaixo:

1. (Opcional) Se o seu cluster de backup for FlexVolume, utilize uma ferramenta de linha de comando para converter arquivos YAML em lote, pois o YAML para PVs e PVCs difere entre FlexVolume e CSI. Para mais informações, consulte Usar a ferramenta de linha de comando FlexVolume2CSI para converter arquivos YAML em lote.

2. Execute o comando a seguir para implantar o arquivo YAML CSI obtido do FlexVolume2CSI.

   onde outputfile.txt é a saída da conversão YAML da ferramenta de linha de comando.

   Expandir para visualizar o arquivo outputfile.txt

   ---
   apiVersion: v1
   kind: PersistentVolume
   metadata:
     labels:
       alicloud-pvname: d-2ze88915lz1il0**** # The dynamically created disk.
     name: d-2ze88915lz1il0****
   spec:
     accessModes:
     - ReadWriteOnce
     capacity:
       storage: 20Gi
     csi:
       driver: diskplugin.csi.alibabacloud.com
       fsType: ext4
       volumeHandle: d-2ze88915lz1il0****
     nodeAffinity:
       required:
         nodeSelectorTerms:
         - matchExpressions:
           - key: topology.diskplugin.csi.alibabacloud.com/zone
             operator: In
             values:
             - cn-beijing-i
     persistentVolumeReclaimPolicy: Delete
     storageClassName: alicloud-disk-essd
     volumeMode: Filesystem
   
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: disk-essd
     namespace: default
   spec:
     accessModes:
     - ReadWriteOnce
     resources:
       requests:
         storage: 20Gi
     selector:
       matchLabels:
         alicloud-pvname: d-2ze88915lz1il0****
     storageClassName: alicloud-disk-essd
     volumeMode: Filesystem
   
   ---
   apiVersion: v1
   kind: PersistentVolume
   metadata:
     labels:
       alicloud-pvname: pv-nas
     name: pv-nas
   spec:
     accessModes:
     - ReadWriteMany
     capacity:
       storage: 5Gi
     csi:
       driver: nasplugin.csi.alibabacloud.com
       volumeAttributes:
         server: 1758axxxxx-xxxxx.cn-beijing.nas.aliyuncs.com
       volumeHandle: pv-nas
     mountOptions:
     - vers=3
     - nolock,tcp,noresvport
     persistentVolumeReclaimPolicy: Retain
     storageClassName: nas
     volumeMode: Filesystem
   
   ---
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: pvc-nas
     namespace: default
   spec:
     accessModes:
     - ReadWriteMany
     resources:
       requests:
         storage: 5Gi
     selector:
       matchLabels:
         alicloud-pvname: pv-nas
     storageClassName: nas
     volumeMode: Filesystem
   

   kubectl apply -f outputfile.txt

3. Execute o comando a seguir para confirmar que o PVC no cluster de restauração está no estado Bound.

   kubectl get pvc 

   Saída esperada:

   NAME        STATUS   VOLUME                   CAPACITY   ACCESS MODES   STORAGECLASS         AGE
   disk-essd   Bound    d-2ze88915lz1il0xxxxxx   20Gi       RWO            alicloud-disk-essd   29m
   pvc-nas     Bound    pv-nas                   5Gi        RWX            nas                  29m

Etapa 6: Criar uma tarefa de restauração

Se você fez backup de volumes ao criar o backup, estará usando o método de alteração da fonte de dados para backup e restauração. Altere o tipo de armazenamento usando a conversão de StorageClass (convertedarg). Por exemplo, converta armazenamento NAS em armazenamento de disco. Selecione a StorageClass de destino conforme suas necessidades.

• Neste exemplo, como o cluster de backup é um cluster FlexVolume v1.16 e os backups de volume de disco usam o Cloud Backup, selecione alicloud-disk como a StorageClass de destino para a reivindicação de armazenamento disk-essd (que é convertida para uma classe de disco CSI e tem como padrão alicloud-disk-topology-alltype). Se o seu cluster de backup for um cluster CSI v1.18 ou superior, não é necessário realizar configurações relacionadas para volumes de disco.

• Este exemplo também converte o volume NAS FlexVolume em um volume NAS isolado gerenciado por CNFS, selecionando a StorageClass de destino alibabacloud-cnfs-nas para o PVC pvc-nas. Se o seu cluster não tiver a StorageClass alibabacloud-cnfs-nas, consulte Gerenciar sistemas de arquivos NAS usando CNFS.

Siga as etapas específicas abaixo:

1. Execute o comando a seguir para criar uma tarefa de restauração.

   Para informações sobre como configurar uma tarefa de restauração no console ACK, consulte Restaurar aplicações e volumes de dados. Esta etapa fornece a configuração recomendada para o cenário de exemplo. Ajuste as configurações conforme o seu cenário específico.

   cat << EOF | kubectl apply -f -
   apiVersion: csdr.alibabacloud.com/v1beta1
   kind: ApplicationRestore
   metadata:
     annotations:
       csdr.alibabacloud.com/backuplocations: >-
         '{"name":"<your-backup-vault-name>","region":"<your-region-id>","bucket":"<your-oss-bucket-name>","provider":"alibabacloud"}'
     name: <your-restore-name>
     namespace: csdr
   spec:
     backupName: <your-backup-name>
     excludedNamespaces:
     - arms-prom
     excludedResources:
     - secrets
     appRestoreOnly: false
     convertedarg:
     - convertToStorageClassType: alicloud-disk-topology-alltype
       namespace: default
       persistentVolumeClaim: alicloud-disk
     - convertToStorageClassType: alibabacloud-cnfs-nas
       namespace: default
       persistentVolumeClaim: pvc-nas
     namespaceMapping:
       <backupNamespace>: <restoreNamespace>
   EOF

   Parâmetro	Descrição
   excludedNamespaces	Namespaces a serem excluídos. Exclua namespaces indesejados da lista de recursos de backup.
   excludedResources	Recursos a serem excluídos. Exclua tipos de recursos indesejados da lista de recursos de backup.
   appRestoreOnly	Para um backup que inclui volumes, este parâmetro define se os volumes devem ser restaurados. true: Cria volumes dinâmicos e reivindicações de armazenamento que apontam para uma nova fonte de dados durante a restauração. Tarefas de backup criadas no console têm como padrão true. false: Um volume estático não é criado. Implante manualmente um volume estático com antecedência. Nota Normalmente, defina como true para alteração da fonte de dados e como false para fonte de dados inalterada.
   convertedarg	Lista de conversão de StorageClass. Para volumes do tipo FileSystem, como OSS, NAS, CPFS e volumes locais, configure este parâmetro para converter as StorageClasses de seus PVCs para a StorageClass especificada durante o processo de restauração. Por exemplo, converta volumes NAS em volumes de disco. convertToStorageClassType: a StorageClass desejada. Certifique-se de que a StorageClass exista no cluster atual. Especifique apenas a StorageClass de disco ou NAS. namespace: o namespace do PVC. persistentVolumeClaim: o nome do PVC. Estes são os parâmetros obrigatórios para o recurso de conversão de StorageClass.

2. Execute o comando a seguir para consultar o status da tarefa de restauração.

   kubectl -ncsdr describe applicationrestore <your-restore-name>

   Na saída esperada, o Phase de Status muda para Completed, indicando que a tarefa foi restaurada com sucesso.

3. Execute os comandos a seguir para verificar se houve falha na restauração de algum recurso e identificar a causa da falha.

   kubectl -ncsdr get pod | grep csdr-velero
   kubectl -ncsdr exec -it <csdr-velero-pod-name> -- /velero describe restore <your-restore-name> --details

   Saída esperada:

   Warnings:
     Velero:     <none>
     Cluster:  could not restore, ClusterRoleBinding "kubernetes-proxy" already exists. Warning: the in-cluster version is different than the backed-up version.
     Namespaces:
       demo-ns:  could not restore, ConfigMap "kube-root-ca.crt" already exists. Warning: the in-cluster version is different than the backed-up version.
                  could not restore, Endpoints "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version.
                  could not restore, Service "kubernetes" already exists. Warning: the in-cluster version is different than the backed-up version.
   
   Errors:
     Velero:     <none>
     Cluster:    <none>
     Namespaces:
       demo-ns:  error restoring endpoints/xxxxxx/kubernetes: Endpoints "kubernetes" is invalid: subsets[0].addresses[0].ip: Invalid value: "169.254.128.9": may not be in the link-local range (169.xxx.0.0/16, fe80::/10)
                  error restoring endpointslices.discovery.k8s.io/demo-ns/kubernetes: EndpointSlice.discovery.k8s.io "kubernetes" is invalid: endpoints[0].addresses[0]: Invalid value: "169.xxx.128.9": may not be in the link-local range (169.xxx.0.0/16, fe80::/10)
                  error restoring services/xxxxxx/kubernetes-extranet: Service "kubernetes-extranet" is invalid: spec.ports[0].nodePort: Invalid value: 31882: provided port is already allocated

   A partir da saída anterior, verifique se algum recurso no cluster de restauração não foi restaurado. Por exemplo, os Warnings indicam que um recurso já existe e foi ignorado. Os Errors indicam um conflito de NodePort, pois a porta original é retida durante uma restauração entre clusters.

4. Confirme se a aplicação restaurada está funcionando corretamente.

   1. Após a restauração da aplicação, verifique se algum recurso está em estado anormal devido a restrições da aplicação, exceções de runtime do container ou outros motivos. Se houver, corrija-os manualmente.

   2. Após a verificação da recuperação, a apiVersion da aplicação Nginx é ajustada por padrão para apps/v1, que é a recomendada para clusters da versão 1.28.