Nesta página, mostramos como usar o Config Controller da melhor maneira possível ao operar serviços altamente disponíveis ou gerenciar recursos em várias regiões do Google Cloud.
Esta página é destinada a administradores, arquitetos e operadores que gerenciam o ciclo de vida da infraestrutura tecnológica subjacente e planejam as necessidades de capacidade e infraestrutura. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.
O Config Controller é executado em uma única região. Portanto, ele tolera a falha de uma zona de disponibilidade. No entanto, se uma região inteira falhar, o Config Controller perderá a disponibilidade. Existem duas estratégias diferentes para lidar com falhas regionais, e sua escolha depende do que você faria se uma região falhar:
Se você faria alterações de configuração em resposta a uma falha regional, crie uma segunda instância do Config Controller.
Se você não faria alterações na configuração, use uma única instância do Config Controller.
Noções básicas sobre os cenários de falha
O Config Controller usa um cluster regional do GKE. Embora o cluster regional tolere a falha de uma única zona em uma região, o cluster fica indisponível se várias zonas na região falharem.
Se a instância do Config Controller falhar, os recursos atuais do Google Cloud permanecem no estado atual. No entanto, mesmo que os aplicativos ainda estejam em execução, não será possível alterar a configuração deles enquanto o Config Controller não estiver disponível. Isso se aplica a recursos na mesma região e a recursos em outras regiões que você está gerenciando no Config Controller na região indisponível.
Como não é possível reconfigurar recursos na mesma região, se uma falha regional afeta os recursos existentes do Google Cloud na região do Config Controller, não é possível reparar esses recursos.
Como também não é possível reconfigurar recursos em outras regiões, uma falha em uma região agora afetou a capacidade de fazer alterações em outra região.
Outros cenários de falha também são possíveis. Por exemplo, se você configurar o Config Sync para extrair de um provedor Git externo, considere os modos de falha desse provedor Git. Talvez não seja possível fazer alterações de configuração porque não é possível enviar alterações para esse provedor Git. Ou, se o Config Sync não puder ler do Git, as alterações do Git não serão aplicadas ao cluster, e o Config Connector não as aplicará. No entanto, a falha regional geralmente é o cenário de falha mais importante, porque outros cenários de falha normalmente não estão relacionados à falha do Config Controller.
Usar um único cluster para disponibilidade regional
Em muitos cenários, você não realizará nenhuma reconfiguração se uma região falhar. Nesse caso, é possível aceitar que uma falha regional fará com que o plano de controle da configuração fique indisponível.
Por exemplo, se você atua em uma única região, não haverá nenhuma reconfiguração útil que você poderá fazer se essa região falhar. Da mesma forma, se você tiver um banco de dados de ponto único de falha em uma única região, talvez não seja possível recuperar até que essa região se recupere. Para aplicativos que não precisam da disponibilidade absoluta mais alta, isso pode ser uma troca razoável em relação ao custo e à complexidade.
A localização da instância do Config Controller na mesma região fornece um destino compartilhado: o Config Controller está disponível enquanto a região principal estiver disponível. A localização da instância do Config Controller em uma região diferente também pode ser uma boa escolha. Embora agora você precise pensar em possíveis falhas em duas regiões, você evita a falha correlacionada do plano de controle da configuração com a falha da região principal.
Como alternativa, se você tiver uma configuração redundante multirregional, seu sistema poderá automaticamente se evitar de regiões com falha. Também é possível que você não queira fazer a reconfiguração se uma região falhar. Nesse caso, escolha uma única instância do Config Controller.
Failover manual para uma segunda instância do Config Controller
Se uma região falhar, é uma boa opção fazer uma reconfiguração. Assim, é possível corrigir a falha. Também é possível continuar configurando recursos em outras regiões, mesmo que a instância do Config Controller esteja localizada em uma região com falha. Nesse caso, recomendamos o uso de uma segunda instância do Config Controller em uma segunda região.
Embora não seja recomendado, duas instâncias do controlador de configuração podem ser executadas com configurações idênticas. As duas farão uma corrida para ler o mesmo repositório Git e aplicarão as mesmas alterações ao Google Cloud. No entanto, vários casos de borda tornam isso não confiável. As duas instâncias do Config Controller observam o repositório Git em momentos um pouco diferentes. Elas podem tentar aplicar versões um pouco diferentes da configuração do Google Cloud. Ter vários gravadores ativos no Google Cloud aumenta as chances de você atingir cotas ou limitações de taxas. Um pequeno número de recursos do Config Connector também não é idempotente e precisa de cuidado extra, conforme discutido no restante desta seção. Portanto, é recomendável não ter dois clusters do Config Controller reconciliando ativamente.
Recomendamos que, em caso de falha na região que executa o Config Controller, você execute outro Config Controller em uma segunda região. A nova instância do Config Controller precisa ser configurada de maneira idêntica à primeira, lendo o mesmo repositório Git. A preparação prévia de um script para exibir e configurar a instância do Config Controller pode ser útil neste cenário. Ao criar a nova instância do Config Controller, o Config Sync lê e aplica o estado pretendido do Git para o Kubernetes. O Config Connector sincroniza o estado pretendido com o Google Cloud.
Há duas coisas a serem observadas nessa situação:
Se o primeiro cluster do Config Controller ainda estiver em execução ou começar a ser executado quando a primeira região se recuperar, ele poderá tentar aplicar o estado antigo ao Google Cloud. Se você puder interromper o cluster do Config Controller na primeira região antes de iniciar um segundo cluster, será possível evitar esse possível conflito.
Nem todos os recursos do Config Connector podem ser reaplicados do Git. Para ver a lista de recursos que precisam de cuidado especial, consulte recursos com restrições de aquisição. Especificamente, recomendamos ter cuidado com os recursos
Foldere evitar recursosIAMServiceAccountKey(por exemplo, usando a federação de identidade da carga de trabalho do GKE).
Uma instância do Config Controller por região
Se você quiser evitar que uma instância do Config Controller em uma região afete outra região, considere executar uma instância do Config Controller por região, em que cada instância do Config Controller gerencia recursos nessa região.
Essa configuração funciona, mas não é uma das opções recomendadas pelos seguintes motivos:
Alguns recursos abrangem várias regiões (como o Cloud DNS), o que torna essa estratégia limitada.
Geralmente, ter um cluster do Config Controller na mesma região encontra o problema de falha correlacionada: convém reconfigurar recursos exatamente quando uma falha regional afeta o Config Controller nessa região.
É necessário dividir os recursos do Config Connector por região.
Atualmente, o Config Controller não está disponível em todas as regiões.
Como configurar diretamente recursos do Google Cloud
Em circunstâncias excepcionais, é possível fazer alterações diretamente nos recursos subjacentes do Google Cloud, sem passar pelo Git ou pelo Config Connector. O Config Connector tenta corrigir qualquer "desvio". Portanto, se a instância do Config Controller ainda estiver em execução, o Config Connector considera todas as alterações feitas manualmente como "desvio" e tenta revertê-las.
No entanto, se você interromper a instância do Config Controller ou se a região estiver off-line, essa poderá ser uma medida útil.
Quando a instância do Config Controller é recuperada, o Config Connector provavelmente tentará reverter as alterações manuais. Para evitar isso, é possível fazer alterações correspondentes no Git para quaisquer alterações feitas manualmente.