Migre recursos do Config Controller

Esta página mostra como migrar recursos do Config Connector de um cluster do Config Controller para outro. Pode ter de migrar um recurso se o cluster do Config Controller principal falhar e tiver de ser substituído ou se tiver de 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 tem de migrar.
  • Cluster de destino: o cluster para o qual vai migrar os recursos.

Recomendações

  • Antes de fazer alterações na produção, conclua estes passos num ambiente de teste.
  • Se precisar de migrar vários clusters do Config Controller, migre cada um separadamente, começando pelo cluster menos crítico.
  • Se o cluster do Config Sync for sincronizado a partir de mais de uma fonte de informação fidedigna, migre todos os recursos de cada fonte de uma só vez.

Passos de migração para vários cenários

Migre todos os recursos

Para migrar todos os recursos, conclua os seguintes passos:

  1. Crie o cluster de destino.

  2. Pare de enviar alterações para a fonte de verdade a partir da qual o cluster de origem está configurado para sincronizar. A sincronização de configuração deve continuar a sincronizar a partir da fonte de dados tradicional. Só devem ser interrompidas as alterações que o cluster de origem sincroniza.

  3. Certifique-se de que as alterações recentes à fonte de informação fidedigna foram sincronizadas no cluster e que todos os recursos estão atualizados no cluster de origem.

    Se existirem erros para alguns recursos, pode ter de analisar os recursos individualmente. Se um recurso ainda não tiver sido criado devido a um erro, é criado posteriormente através do Config Connector em execução no cluster de destino. Normalmente, estes erros podem ser ignorados. No entanto, para a maioria dos erros, as causas principais devem ser encontradas e corrigidas antes de tentar a migração.

  4. Configure o Config Sync no cluster de destino para ler a mesma fonte de informações verdadeiras a partir da qual o cluster de origem está configurado. Se tiver várias sincronizações configuradas para sincronizar a partir de mais do que uma fonte de informação fidedigna, faça isto para cada sincronização.

  5. Use o comando nomos status para garantir que o cluster de destino sincronizou todos os recursos da fonte prioritária.

  6. Depois de sincronizar os recursos, remova o RootSync ou RepoSync do cluster de origem.

  7. Assim que cada origem de confiança for migrada, elimine o cluster do controlador de configuração de origem.

Migre alguns recursos

Para migrar alguns recursos, conclua os seguintes passos:

  1. Conclua os passos 1 a 6 da secção Migrar todos os recursos anterior.

  2. Anote os recursos que devem ser migrados para o cluster de destino com a anotação cnrm.cloud.google.com/deletion-policy: abandon. Esta anotação impede que o Config Connector elimine os recursos subjacentes quando o recurso do Config Connector é eliminado do cluster do Config Controller.

  3. Elimine os recursos que foram marcados como abandonados do cluster de origem. Esta eliminação só funciona se estes recursos também forem removidos da fonte de informação fidedigna antes de retomar o Config Sync.

  4. Mova estes recursos para uma fonte de informação fidedigna diferente ou para uma pasta diferente na mesma fonte de informação fidedigna.

  5. Configure o cluster de destino para sincronizar a partir da localização para a qual moveu os recursos. O cluster de destino pode agora adquirir estes recursos e começar a geri-los.

Migre recursos individuais

Quando não é possível eliminar um cluster do Config Controller (por exemplo, quando está a migrar apenas um subconjunto de recursos para um cluster diferente), pode eliminar recursos individuais. Para eliminar recursos individuais, desative o Config Sync e, em seguida, defina a anotação cnrm.cloud.google.com/deletion-policy: abandon como on nos recursos individuais que tem de eliminar.

Migre recursos que tenham um resourceID serviço gerado

Para recursos em que o campo resourceID não foi fornecido explicitamente, não é necessário especificar o resourceID para a aquisição de recursos por outra instância do Config Connector. No entanto, existem recursos que têm um ID de recurso gerado pelo serviço que requerem passos adicionais. Embora o resourceID seja gerado pelo serviço, tem de ser fornecido para adquirir estes recursos a partir de outra instância do Config Connector. Para estes recursos, os resourceIDs devem ser adicionados à origem de verdade antes de tentar adquirir recursos do cluster de destino.

Migre recursos através da política de prevenção de conflitos

Por predefinição, a política de prevenção de conflitos está desativada para os recursos. Pode ativá-la num recurso definindo a seguinte anotação:

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

Depois de definido, o Config Connector tem de adquirir uma concessão no recurso subjacente antes de fazer alterações ao mesmo. Isto significa que o cluster de destino não consegue adquirir o arrendamento imediatamente, uma vez que o arrendamento é detido pelo Config Connector no cluster de origem. A concessão é concedida durante 40 minutos. No entanto, após 20 minutos, o Config Connector tenta renovar proativamente a concessão. Devido a este comportamento, se o Config Connector no cluster de origem estiver em bom estado e em execução, o cluster de destino não consegue adquirir a concessão. O cluster de origem tem de libertar a respetiva concessão antes de o cluster de destino a poder adquirir. Isto pode ser feito eliminando o cluster de origem ou eliminando o recurso no cluster de origem.

Assim que o cluster de origem libertar a concessão, o cluster de destino pode adquiri-la. O cluster de destino pode adquirir a concessão após, no máximo, 40 minutos e pode começar a gerir os recursos. Não devem ser feitas alterações aos recursos do Config Connector até que a concessão tenha sido adquirida pelo cluster de destino.

O que se segue?