Esta documentação é referente à versão atual do GKE na AWS, lançada em novembro de 2021. Consulte as Notas de lançamento para mais informações.

Esta página foi traduzida pela API Cloud Translation.

Sobre as atualizações súbitas

Neste documento, apresentamos uma breve visão geral das atualizações graduais padrão e abordamos os detalhes sobre as atualizações do Surge, que são um tipo especial de atualização contínua. Em comparação com as atualizações graduais padrão, as atualizações do Surge permitem configurar a velocidade da atualização. As atualizações do Surge também permitem que você tenha algum controle sobre o quanto as atualizações disruptivas podem ser aplicadas às cargas de trabalho.

Para informações sobre como ativar e configurar atualizações do Surge para o GKE na AWS, consulte Configurar atualizações do Surge de pools de nós.

Como funcionam as atualizações graduais padrão

Algumas atualizações em um pool de nós, como quando você modifica as anotações de um pool de nós, não exigem a reinicialização dos nós e, portanto, não geram uma atualização gradual. Se o GKE na AWS puder aplicar alterações a um pool de nós sem precisar reiniciar ou recriar recursos, isso será feito para evitar interrupções.

No entanto, a maioria das atualizações em um pool de nós no GKE na AWS geralmente envolve o encerramento de nós atuais e a inicialização de novos nós com as configurações atualizadas. O processo de encerramento dos nós atuais pode interromper as cargas de trabalho.

Por padrão, o GKE na AWS realiza atualizações graduais padrão. Esse método atualiza um nó de cada vez, e eles são substituídos usando uma abordagem "encerrar antes de criar": um nó é encerrado primeiro e, em seguida, um novo nó atualizado é iniciado. Isso minimiza a interrupção, já que apenas um nó é encerrado e substituído a qualquer momento.

Confira as etapas que o GKE na AWS segue durante uma atualização gradual padrão:

Seleciona um nó do pool de nós e o marca como indisponível para garantir que nenhum pod novo seja iniciado nele. Essa ação é chamada de restrição.
Realoca os pods ativos do nó restrito para outros nós disponíveis dentro do cluster. Se outros nós tiverem capacidade suficiente, eles acomodam os pods removidos. Caso contrário, o escalonador automático de cluster, que permanece ativo durante uma atualização gradual padrão, inicia um escalonamento vertical e provisiona nós adicionais para garantir que haja capacidade suficiente para programar os pods removidos. Para mais informações sobre as medidas tomadas para proteger cargas de trabalho durante esse processo, consulte Proteção da carga de trabalho durante o redimensionamento.
Encerra o nó restrito.
Substitui o nó restrito por um novo com as configurações atualizadas.
Conduz uma verificação de integridade no nó operacional recém-operado. Se o pool de nós falhar na verificação de integridade, ele será marcado com um status DEGRADED. Para verificar esse status, execute o comando gcloud container aws node-pools describe. Quando um pool de nós é marcado como DEGRADED, é possível que novos pods não sejam programados nos nós dentro dele.
Continua atualizando, nó por nó, até que todos os nós no pool sejam atualizados.

Como funcionam as atualizações do Surge

No GKE na AWS, o método gradual padrão atualiza um nó de cada vez. As atualizações do Surge, que são uma forma de atualização gradual, permitem atualizar vários nós ao mesmo tempo. Portanto, as atualizações do Surge são mais rápidas do que as atualizações graduais padrão. No entanto, a atualização de vários nós ao mesmo tempo pode interromper as cargas de trabalho. Para atenuar isso, as atualizações do Surge oferecem opções para modular o nível de interrupção das cargas de trabalho.

Outra maneira em que as atualizações do Surge podem ser diferentes das atualizações graduais padrão é a maneira como os nós são substituídos. As atualizações graduais padrão substituem os nós usando uma estratégia "encerrar antes de criar". Dependendo das configurações escolhidas, as atualizações do Surge podem usar uma estratégia "criar antes de encerrar", uma estratégia "encerrar antes de criar" ou até mesmo uma combinação das duas.

O escalonador automático de cluster desempenha um papel mais importante nas atualizações do Surge do que nas atualizações graduais padrão. É por isso que ele aparece em destaque na seguinte lista de ações que o GKE na AWS realiza durante uma atualização do Surge:

Criação de um novo grupo de escalonamento automático: o GKE na AWS provisiona novos nós com as modificações especificadas pelo comando de atualização e atribui esses novos nós a um novo grupo de escalonamento automático da AWS (ASG).
Comportamento do escalonador automático de cluster: quando a atualização do Surge começa, o escalonador automático de cluster é ativado para o novo grupo de escalonamento automático. O escalonador automático de cluster do grupo de escalonamento automático original é desativado. Isso garante que qualquer operação de escalonamento seja destinada apenas ao novo grupo.
Substituição de nós: dependendo dos parâmetros de atualização do Surge, diferentes estratégias para a substituição de nós são usadas:
- "criar antes de encerrar": essa estratégia é ativada quando o parâmetro max-surge-update é definido como um valor maior que zero. Ele gera novos nós no novo ASG antes de encerrar os antigos no ASG original, com o objetivo de minimizar as interrupções do serviço.
- "terminate antes de criar": esse método é acionado quando o parâmetro max-surge-update é definido como zero e o parâmetro max-unavailable-update tem um valor maior que zero. Os nós do ASG original são encerrados primeiro, seguidos pela criação de novos no novo ASG.
Ajustes de tamanho do pool de nós: durante a atualização, o tamanho do pool de nós (ou seja, a soma de nós no ASG antigo e no novo) pode flutuar acima ou abaixo da contagem original de nós presentes no pool de nós antes do início da atualização. Especificamente, o objetivo do GKE na AWS é manter a contagem total de nós no intervalo de (original_count - max-unavailable-update) a (original_count + max-surge-update). Com o tempo, os nós no ASG antigo (original_count) são substituídos por nós atualizados no novo ASG. O escalonador automático de clusters pode iniciar mais nós no novo ASG se detectar que os pods não podem ser programados, mas permanecem dentro dos limites definidos por min-nodes e max-nodes.

Um exemplo que ilustra o processo

Para entender melhor como as atualizações do Surge funcionam, considere o exemplo a seguir. Suponha que você tenha um pool de nós com cinco nós e execute o seguinte comando:

  gcloud container aws node-pools update production-node-pool
      --cluster my-cluster \
      --location us-west1 \
      --max-surge-update 2 \
      --max-unavailable-update 1 \
      --node-version 1.27.6-gke.700

Neste exemplo, max-surge-update está definido como 2, max-unavailable-update está definido como 1 e você apresenta uma nova versão do pool de nós, ou seja, você está alterando a versão do GKE que está em execução nos nós do pool de nós.

A execução desse comando aciona uma atualização do Surge, e o GKE na AWS realiza as seguintes ações:

Criam dois nós adicionais porque o valor de max-surge-update é igual a 2.
Atribuem esses dois nós extras a um novo grupo de escalonamento automático da AWS.
Removem os nós do grupo original de escalonamento automático quando esses novos nós estão em operação. O GKE na AWS reduz até três nós (o valor combinado de max-surge-update e max-unavailable-update), mas garante que, no máximo, apenas um nó fique indisponível a qualquer momento (devido ao valor max-unavailable-update de 1).
Repita essas etapas até que todos os nós no pool tenham sido atualizados para a nova versão do GKE.

Durante essa atualização, o pool de nós contém de 4 a 7 nós operacionais.

O que considerar antes de executar atualizações do Surge

Antes de executar uma atualização súbita, considere o seguinte:

As instâncias extras criadas como parte dessa etapa do Surge podem exceder o limite de cota da instância da AWS. Se você não tiver cota suficiente e essas outras instâncias não puderem ser provisionadas, a atualização poderá falhar.
Se max-unavailable-update for definido como 0, ainda poderão ocorrer interrupções nas cargas de trabalho conforme os pods forem removidos e reprogramados nos nós mais recentes.
O número máximo de nós que podem ser atualizados ao mesmo tempo é igual à soma de max-surge-update e max-unavailable-update e está limitado a 20.

Escolha as configurações certas do Surge para suas necessidades

Embora as atualizações graduais padrão costumem usar uma abordagem de "encerrar antes de criar", as atualizações do Surge apresentam mais flexibilidade. Dependendo da configuração, as atualizações do Surge podem seguir uma estratégia "criar antes de encerrar", uma estratégia "encerrar antes de criar" ou uma combinação das duas. Nesta seção, descrevemos diferentes configurações para você escolher a melhor abordagem para suas cargas de trabalho.

A tabela a seguir mostra três exemplos de configurações e destaca o impacto delas na velocidade da atualização e a possível interrupção nas cargas de trabalho:

Nome	Descrição	Configuração
Configuração equilibrada (padrão)	Balanceado, mais lento, mas menos disruptivo.	maxSurge=1, maxUnavailable=0
Atualizações rápidas sem recursos extras	Rápido, sem recursos do Surge, mais disruptivo.	maxSurge=0, maxUnavailable=20
Atualizações rápidas que são menos disruptivas	Rápido, a maioria dos recursos é do Surge e é menos disruptivo.	maxSurge=20, maxUnavailable=0

Cada uma das configurações na tabela é descrita nas seções a seguir.

Configuração equilibrada (padrão)

A maneira mais direta de usar atualizações do Surge é com a configuração padrão de max-surge-update=1 e max-unavailable-update=0. Essa configuração adiciona apenas um nó do Surge ao pool de nós durante a atualização, e apenas um nó é atualizado por vez, seguindo uma abordagem de "criar antes de encerrar". Em comparação com a atualização gradual padrão não Surge, que é equivalente a (max-surge-update=0, max-unavailable-update=1), esse método é menos disruptivo, acelera a reinicialização do pod durante as atualizações e é mais conservador na progressão.

É importante observar que adotar a configuração equilibrada pode gerar custos extras por causa do nó do Surge temporário adicionado durante a atualização. Esse nó adicional gera cobranças enquanto está ativo, aumentando um pouco a despesa geral em comparação com métodos sem nós do Surge.

Atualizações rápidas sem recursos extras

Para cargas de trabalho que tolerem interrupções, uma abordagem de atualização mais rápida pode ser adequada. A configuração de max-surge-update=0 e max-unavailable-update=20 resulta nisso. Com essa configuração, 20 nós podem ser atualizados ao mesmo tempo sem a adição de nós do Surge. Esse método de atualização segue uma abordagem de "encerrar antes de criar". Como nenhum nó adicional do Surge é introduzido durante o processo, esse método também é o mais econômico, evitando despesas extras associadas a nós temporários.

Atualizações rápidas que são menos disruptivas

Se suas cargas de trabalho forem sensíveis à interrupção, aumente a velocidade da atualização com as seguintes configurações: max-surge-update=20 e max-unavailable-update=0. Essa configuração atualiza 20 nós em paralelo de modo "criar antes de encerrar".

No entanto, a velocidade geral da atualização poderá ficar restrita se você tiver configurado PodDisruptionBudgets (PDB) para as cargas de trabalho. Isso ocorre porque o PDB restringe o número de pods que podem ser drenados a qualquer momento. Ainda que as configurações dos PDBs possam variar, se você criar um PDB com maxUnavailable igual a 1 para uma ou mais cargas de trabalho em execução no pool de nós, somente um pod dessas cargas de trabalho poderá ser removido por vez, limitando o paralelismo de toda a atualização.

Lembre-se de que iniciar vários nós do Surge no início do processo de atualização pode levar a um aumento temporário nos custos, especialmente em comparação com configurações que não adicionam nós extras ou que adicionam menos nós durante as atualizações.

A seguir