Esta página mostra-lhe a melhor forma de usar o Config Controller quando opera serviços de alta disponibilidade ou gere recursos em várias regiões. Google Cloud
Esta página destina-se a administradores, arquitetos e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente e planeiam a capacidade e as necessidades de infraestrutura. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.
O Config Controller é executado numa única região, pelo que pode tolerar a falha de uma zona de disponibilidade. No entanto, se falhar uma região inteira, o Config Controller perde a disponibilidade. Existem duas estratégias diferentes para lidar com falhas regionais, e a sua escolha depende do que faria se uma região falhasse:
Se fizer alterações à configuração em resposta a uma falha regional, crie uma segunda instância do Config Controller.
Se não quiser fazer alterações de configuração, use uma única instância do Config Controller.
Compreenda os cenários de falha
O Config Controller usa um cluster do GKE regional. Embora o cluster regional possa tolerar a falha de uma única zona numa região, o cluster fica indisponível se falharem várias zonas na região.
Se a sua instância do Config Controller falhar, os recursos Google Cloud existentes permanecem no estado atual. No entanto, mesmo que as suas aplicações continuem a ser executadas, não pode alterar a respetiva configuração quando o Config Controller não está disponível. Isto aplica-se a recursos na mesma região e a recursos noutras regiões que está a gerir a partir do Config Controller na região indisponível.
Uma vez que não pode reconfigurar recursos na mesma região, se uma falha regional afetar os recursos existentes na região do Config Controller, não pode reparar esses recursos. Google Cloud
Uma vez que também não pode reconfigurar recursos noutras regiões, uma falha numa região afetou agora a sua capacidade de fazer alterações noutra região.
Também são possíveis outros cenários de falha. Por exemplo, se configurar o Config Sync para extrair dados de um fornecedor Git externo, deve considerar os modos de falha desse fornecedor Git. Pode não conseguir fazer alterações de configuração porque não consegue enviar alterações para esse fornecedor do Git. Em alternativa, se o Config Sync não conseguir ler a partir do Git, as alterações do Git não são aplicadas ao cluster e, por isso, o Config Connector não as aplica. No entanto, a falha regional é, muitas vezes, o cenário de falha mais importante, porque outros cenários de falha não estão normalmente correlacionados com a falha do controlador de configuração.
Use um único cluster para a disponibilidade regional
Em muitos cenários, não tem de fazer nenhuma reconfiguração se uma região falhar. Nesse caso, pode optar por aceitar que uma falha regional faça com que o plano de controlo da configuração fique indisponível.
Por exemplo, se operar apenas numa única região, pode não haver nenhuma reconfiguração útil que possa fazer se essa região falhar. Da mesma forma, se tiver uma base de dados de ponto único de falha numa única região, pode não conseguir recuperar até essa região recuperar. Para aplicações que não precisam da disponibilidade absoluta mais elevada, esta situação pode ser uma troca razoável em função do custo e da complexidade.
A localização da instância do Config Controller na mesma região dá-lhe um destino partilhado: o Config Controller está disponível enquanto a sua região principal estiver disponível. Localizar a instância do Config Controller numa região diferente também pode ser uma boa escolha. Embora tenha de pensar em potenciais falhas em duas regiões, evita a falha correlacionada do seu plano de controlo de configuração com a falha da sua região principal.
Em alternativa, se tiver uma configuração redundante multirregional, o seu sistema pode desviar-se automaticamente das regiões com falhas. Também aqui, pode não querer fazer a reconfiguração se uma região falhar. Neste caso, pode optar por uma única instância do controlador de configuração.
Efetue a comutação por falha manual para uma segunda instância do controlador de configuração
Pode querer fazer alguma reconfiguração se uma região falhar para poder corrigir a falha. Também pode querer continuar a configurar recursos noutras regiões, mesmo que a sua instância do Config Controller esteja localizada numa região com falhas. Neste caso, recomendamos que use uma segunda instância do Config Controller numa segunda região.
Embora não seja recomendado, podem ser executadas duas instâncias do Config Controller com configurações idênticas. Ambas as instâncias competem para ler a partir do mesmo repositório Git e aplicar as mesmas alterações ao Google Cloud. No entanto, existem vários casos extremos que tornam esta configuração não fiável. As duas instâncias do Config Controller observam o repositório Git em momentos ligeiramente diferentes. Podem tentar aplicar versões ligeiramente diferentes da sua configuração Google Cloud . Vários autores ativos para Google Cloud aumentar a probabilidade de encontrar quotas ou limites de taxa. Um pequeno número de recursos do Config Connector também não é idempotente e requer cuidados adicionais, conforme abordado no resto desta secção. Por isso, recomendamos que não tenha dois clusters do Config Controller a fazer a reconciliação ativamente.
Em alternativa, recomendamos que, se a região que executa o Config Controller falhar, execute outro Config Controller numa segunda região. A nova instância do Config Controller deve ser configurada de forma idêntica à primeira, lendo a partir do mesmo repositório Git. A preparação prévia de um script para apresentar e configurar a instância do Config Controller pode ser útil neste cenário. Quando cria a nova instância do Config Controller, o Config Sync lê e aplica o estado pretendido do Git ao Kubernetes; o Config Connector sincroniza o estado pretendido com o Google Cloud.
Nesta situação, existem dois aspetos aos quais deve prestar atenção:
Se o primeiro cluster do Config Controller ainda estiver em execução ou começar a ser executado quando a primeira região for recuperada, pode tentar aplicar o estado antigo a Google Cloud. Se puder parar o cluster do controlador de configuração na primeira região antes de iniciar um segundo cluster do controlador de configuração, pode evitar este potencial conflito.
Nem todos os recursos do Config Connector podem ser reaplicados facilmente a partir do Git. Para ver a lista de recursos que requerem cuidados especiais, consulte os recursos com restrições relativas à aquisição. Em particular, recomendamos que tenha cuidado com os recursos
Foldere evite os recursosIAMServiceAccountKey(por exemplo, use a Workload Identity Federation para GKE em vez disso).
Uma instância do Config Controller por região
Se quiser evitar que uma instância do Config Controller numa região afete outra região, também pode considerar executar uma instância do Config Controller por região, em que cada instância do Config Controller gere recursos nessa região.
Esta configuração é viável, mas não é uma das nossas opções recomendadas pelos seguintes motivos:
Alguns recursos abrangem várias regiões (como o Cloud DNS), o que torna esta estratégia limitada.
Geralmente, ter um cluster do Config Controller na mesma região encontra o problema de falha correlacionada: quer reconfigurar os recursos exatamente quando uma falha regional afeta o Config Controller nessa região.
Tem de dividir os recursos do Config Connector por região.
Atualmente, o Config Controller não está disponível em todas as regiões.
Configurar diretamente Google Cloud recursos
Em circunstâncias excecionais, pode fazer alterações diretamente aos recursos subjacentes, sem usar o Git nem o Config Connector. Google Cloud O Config Connector tenta corrigir qualquer "desvio", pelo que, se a instância do Config Controller ainda estiver em execução, o Config Connector considera quaisquer alterações que fizer manualmente como "desvio" e tenta revertê-las.
No entanto, se parar a instância do Config Controller ou se a região estiver offline, esta pode ser uma medida provisória útil.
Quando a instância do Config Controller for recuperada, o Config Connector vai provavelmente tentar reverter as alterações manuais. Para evitar esta situação, pode fazer as alterações correspondentes no Git para quaisquer alterações que faça manualmente.