Migrar recursos do Config Controller

Nesta página, mostramos como migrar os recursos do Config Connector de um cluster do Config Controller para outro. Talvez seja necessário migrar um recurso se o cluster principal do Config Controller falhar e precisar ser substituído ou precisar alterar uma configuração de cluster imutável.

Esta página usa a seguinte terminologia:

  • Cluster de origem: o cluster que contém os recursos do Config Connector que você precisa migrar.
  • Cluster de destino: o cluster para o qual você vai migrar recursos.

Recomendações

  • Antes de fazer alterações na produção, conclua estas etapas em um ambiente de teste.
  • Se você precisar migrar vários clusters do Config Controller, migre cada um separadamente, começando com o cluster menos crítico.
  • Se o cluster do Config Sync for sincronizado de mais de uma fonte de verdade, migre todos os recursos de cada fonte de uma só vez.

Etapas da migração para vários cenários

Migrar todos os recursos

Para migrar todos os recursos, siga estas etapas:

  1. Crie o cluster de destino.

  2. Pare de enviar alterações para a fonte de verdade da qual o cluster de origem está configurado para sincronização. O Config Sync precisa continuar sincronizando a partir da fonte de verdade. Somente as alterações feitas pelo cluster de origem serão sincronizadas.

  3. Verifique se as alterações recentes na fonte de verdade foram sincronizadas no cluster e se todos os recursos estão atualizados no cluster de origem.

    Se houver erros em alguns recursos, talvez seja necessário analisar os recursos individualmente. Se um recurso ainda não tiver sido criado devido a um erro, ele será criado mais tarde usando o Config Connector em execução no cluster de destino. Esses erros geralmente podem ser ignorados. No entanto, para a maioria dos erros, as causas raiz devem ser encontradas e corrigidas antes de tentar a migração.

  4. Configure o Config Sync no cluster de destino para ler a partir da mesma fonte de verdade em que o cluster de origem foi configurado. Se várias sincronizações estiverem configuradas para sincronizar com mais de uma fonte de verdade, faça isso para cada sincronização.

  5. Use o comando nomos status para garantir que o cluster de destino tenha sincronizado todos os recursos da fonte de verdade.

  6. Depois que os recursos forem sincronizados, remova o RootSync ou RepoSync do cluster de origem.

  7. Depois que cada fonte de informações tiver sido migrada, exclua o cluster de origem do Config Controller.

Migrar alguns recursos

Para migrar alguns recursos, siga estas etapas:

  1. Conclua as etapas de 1 a 6 da seção Migrar todos os recursos.

  2. Anote os recursos que precisam ser migrados para o cluster de destino com a anotação cnrm.cloud.google.com/deletion-policy: abandon. Essa anotação impede que o Config Connector exclua os recursos subjacentes quando o recurso do Config Connector for excluído do cluster do Config Controller.

  3. Exclua os recursos que foram marcados como abandonados do cluster de origem. Essa exclusão só funciona se esses recursos também forem removidos da fonte de verdade antes de retomar o Config Sync.

  4. Mova esses recursos para uma fonte de informações diferente ou para uma pasta diferente na mesma fonte de informações.

  5. Configure o cluster de destino para sincronizar com o local para onde os recursos foram movidos. O cluster de destino agora pode adquirir esses recursos e começar a gerenciá-los.

Migrar recursos individuais

Quando não é possível excluir um cluster do Config Controller (por exemplo, ao migrar apenas um subconjunto de recursos para um cluster diferente), você pode excluir recursos individuais. Para excluir recursos individuais, desative o Config Sync e defina a anotação cnrm.cloud.google.com/deletion-policy: abandon nos recursos individuais que você precisa excluir.

Migrar recursos que têm um resourceID gerado pelo serviço

Para recursos em que o campo resourceID não foi fornecido explicitamente, o resourceID não precisa ser especificado para aquisição de recursos por outra instância do Config Connector. No entanto, há recursos com um ID gerado por serviço que precisam de etapas adicionais. Mesmo que o resourceID seja gerado pelo serviço, ele precisará ser fornecido para adquirir esses recursos de outra instância do Config Connector. Para esses recursos, os resourceIDs precisam ser adicionados à fonte da verdade antes de tentar adquirir recursos do cluster de destino.

Migrar recursos usando a política de prevenção de conflitos

Por padrão, a política de prevenção de conflitos é desativada para recursos. É possível ativá-la em um recurso definindo a seguinte anotação:

cnrm.cloud.google.com/management-conflict-prevention-policy: "resource"

Depois de definido, o Config Connector precisa adquirir um lease no recurso subjacente antes de fazer alterações nele. Isso significa que o cluster de destino não pode adquirir o lease imediatamente, já que ele é mantido pelo Config Connector no cluster de origem. O lease é concedido por 40 minutos. No entanto, após 20 minutos, o Config Connector tenta renovar o lease de maneira proativa. Devido a esse comportamento, se o Config Connector no cluster de origem estiver íntegro e em execução, o cluster de destino não poderá adquirir o lease. O cluster de origem precisa liberar o lease antes de o cluster de destino poder adquiri-lo. Isso pode ser feito excluindo o cluster de origem ou excluindo o recurso no cluster de origem.

Depois que o cluster de origem libera o lease, o cluster de destino pode adquiri-lo. O cluster de destino pode adquirir a locação após no máximo 40 minutos e pode começar a gerenciar os recursos. Nenhuma alteração deve ser feita nos recursos do Config Connector até que o lease seja adquirido pelo cluster de destino.

A seguir