Acerca das atualizações de aumentos

Este documento oferece uma breve vista geral das atualizações contínuas padrão e, em seguida, aborda detalhadamente as atualizações rápidas, que são um tipo especial de atualização contínua. Em comparação com as atualizações contínuas padrão, as atualizações rápidas permitem-lhe configurar a velocidade da atualização. As atualizações de picos também lhe permitem exercer algum controlo sobre o impacto das atualizações nas suas cargas de trabalho.

Para ver informações sobre como ativar e configurar atualizações rápidas para o GKE no AWS, consulte o artigo Configure atualizações rápidas de conjuntos de nós.

Como funcionam as atualizações contínuas padrão

Algumas atualizações a um node pool, como quando modifica as anotações de um node pool, não requerem o reinício dos nós e, por isso, não provocam uma atualização contínua. Se o GKE no AWS puder aplicar alterações a um conjunto de nós sem ter de reiniciar ou recriar recursos, fá-lo-á para evitar interrupções.

No entanto, a maioria das atualizações de um conjunto de nós no GKE na AWS envolve normalmente terminar nós existentes e iniciar novos nós com as definições atualizadas. O processo de encerramento dos nós existentes pode interromper as cargas de trabalho.

Por predefinição, o GKE na AWS faz atualizações contínuas padrão. Este método atualiza os nós um de cada vez e são substituídos através de uma abordagem de "terminar antes de criar": primeiro, um nó é terminado e, em seguida, é iniciado um novo nó atualizado. Isto minimiza a interrupção porque apenas um nó é terminado e substituído em qualquer momento.

Seguem-se os passos que o GKE na AWS executa durante uma atualização contínua padrão:

1. Seleciona um nó do conjunto de nós e marca o nó como indisponível para garantir que não são iniciados novos pods no mesmo. Esta ação denomina-se isolamento.
2. Muda os pods ativos do nó isolado para outros nós disponíveis no cluster. Se outros nós tiverem capacidade suficiente, estes acomodam os pods desalojados. Caso contrário, o redimensionador automático de clusters, que permanece ativo durante uma atualização contínua padrão, inicia um aumento da escala e aprovisiona nós adicionais para garantir que existe capacidade suficiente para agendar os pods removidos. Para obter informações sobre as medidas tomadas para proteger as cargas de trabalho durante este processo, consulte o artigo Proteção de cargas de trabalho durante a alteração do tamanho.
3. Termina o nó isolado.
4. Substitui o nó isolado por um novo com as definições atualizadas.
5. Realiza uma verificação de funcionamento no nó recentemente operacional. Se o conjunto de nós falhar na verificação de funcionamento, é marcado com o estado DEGRADED. Pode ver este estado executando o comando gcloud container aws node-pools describe. Quando um conjunto de nós está marcado como DEGRADED, pode não ser possível agendar novos pods nos nós desse conjunto.
6. Continua a atualizar, nó a nó, até que todos os nós no conjunto tenham sido atualizados.

Como funcionam as atualizações de picos

No GKE na AWS, o método de implementação gradual padrão atualiza os nós um de cada vez. As atualizações rápidas, que são uma forma de atualização contínua, permitem-lhe atualizar vários nós em simultâneo. Por conseguinte, as atualizações rápidas são mais rápidas do que as atualizações progressivas padrão. No entanto, a atualização de vários nós em simultâneo pode interromper as cargas de trabalho. Para mitigar esta situação, as atualizações de picos oferecem opções para modular o nível de interrupção das suas cargas de trabalho.

Outra forma como as atualizações rápidas podem diferir das atualizações implementadas padrão é a forma como os nós são substituídos. As atualizações contínuas padrão substituem os nós através de uma estratégia "terminar antes de criar". Consoante as definições que escolher, as atualizações de picos podem usar uma estratégia "criar antes de terminar", uma estratégia "terminar antes de criar" ou até mesmo uma combinação de ambas.

O redimensionador automático do cluster desempenha um papel mais importante nas atualizações de picos do que nas atualizações implementadas padrão, motivo pelo qual se destaca na seguinte lista de ações que o GKE no AWS realiza durante uma atualização de picos:

1. Criação de um novo grupo de escalabilidade automática: o GKE on AWS aprovisiona novos nós com as modificações especificadas pelo comando de atualização e atribui estes novos nós a um novo grupo de escalabilidade automática (ASG) da AWS.
2. Comportamento do redimensionador automático de clusters: quando a atualização de picos começa, o redimensionador automático de clusters é ativado para o novo grupo de redimensionamento automático. O redimensionador automático do grupo de escala automática original está desativado. Isto garante que as operações de expansão segmentam apenas o novo grupo.
3. Substituição de nós: consoante os parâmetros de atualização de picos, são usadas diferentes estratégias para a substituição de nós:
   • "create before terminate": esta estratégia é ativada quando o parâmetro max-surge-update é definido como um valor superior a zero. Gera novos nós no novo ASG antes de terminar os antigos no ASG original, com o objetivo de minimizar as interrupções do serviço.
   • "terminate before create": este método é acionado quando o parâmetro max-surge-update está definido como zero e o parâmetro max-unavailable-update tem um valor superior a zero. Os nós do ASG original são terminados primeiro, seguidos da criação de novos nós no novo ASG.
4. Ajustes do tamanho do node pool: durante a atualização, o tamanho do node pool (ou seja, a soma dos nós no ASG antigo e no novo) pode flutuar acima ou abaixo da contagem original de nós presentes no node pool antes do início da atualização. Especificamente, o GKE on AWS tem como objetivo manter a quantidade total de nós no intervalo de (original_count - max-unavailable-update) a (original_count + max-surge-update). Eventualmente, os nós no ASG antigo (original_count) são substituídos por nós atualizados no novo ASG. O escalador automático de clusters pode iniciar mais nós no novo ASG se detetar que não é possível agendar pods, mas permanece dentro dos limites definidos por min-nodes e max-nodes.

Um exemplo para ilustrar o processo

Para compreender melhor como funcionam as atualizações de picos, considere o seguinte exemplo. Suponhamos que tem um conjunto de nós com 5 nós e executa 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 está a fornecer uma nova versão do conjunto de nós (ou seja, está a alterar a versão do GKE que está a ser executada nos nós no conjunto de nós).

A execução deste comando aciona uma atualização de pico e o GKE no AWS executa as seguintes ações:

1. Cria 2 nós adicionais porque o valor de max-surge-update é igual a 2.
2. Atribui estes 2 nós adicionais a um novo grupo de escalamento automático da AWS.
3. Remove nós do grupo de escalamento automático original assim que estes novos nós estiverem operacionais. O GKE na AWS desativa até 3 nós (o valor combinado de max-surge-update e max-unavailable-update), mas garante que, em qualquer altura, fica indisponível, no máximo, apenas um nó (devido ao valor de max-unavailable-update de 1).
4. Repita estes passos até todos os nós no conjunto de nós terem sido atualizados para a nova versão do GKE.

Durante esta atualização, o node pool contém entre 4 e 7 nós operacionais.

Aspetos a considerar antes de executar atualizações de picos

Antes de executar uma atualização de pico, tenha em atenção o seguinte:

• As instâncias adicionais criadas como parte deste passo de pico podem exceder o limite da quota de instâncias da AWS. Se não tiver quota suficiente e não for possível aprovisionar estas instâncias adicionais, a atualização pode falhar.
• Se max-unavailable-update estiver definido como 0, as interrupções nas cargas de trabalho podem continuar a ocorrer à medida que os pods são removidos e reagendados nos nós mais recentes.
• O número máximo de nós que podem ser atualizados em simultâneo é igual à soma de max-surge-update e max-unavailable-update, e está limitado a 20.

Escolha as definições de aumento de preços adequadas às suas necessidades

Embora as atualizações contínuas padrão usem frequentemente uma abordagem "terminar antes de criar", as atualizações rápidas introduzem mais flexibilidade. Consoante a configuração, as atualizações de picos podem seguir uma estratégia de "criar antes de terminar", uma estratégia de "terminar antes de criar" ou uma combinação de ambas. Esta secção descreve diferentes configurações para ajudar a selecionar a melhor abordagem para as suas cargas de trabalho.

A tabela seguinte mostra três exemplos de definições e realça o respetivo impacto na velocidade da atualização e na potencial interrupção das suas cargas de trabalho:

Nome	Descrição	Configuração
Definição equilibrada (predefinição)	Equilibrado, mais lento, mas menos disruptivo.	maxSurge=1, maxUnavailable=0
Atualizações rápidas sem recursos adicionais	Rápido, sem recursos de picos, mais disruptivo.	maxSurge=0, maxUnavailable=20
Atualizações rápidas e menos disruptivas	Rápido, usa a maioria dos recursos de picos e é menos disruptivo.	maxSurge=20, maxUnavailable=0

Cada uma das definições na tabela é descrita nas secções seguintes.

Definição equilibrada (predefinição)

A forma mais simples de usar as atualizações de picos é com a configuração predefinida de max-surge-update=1 e max-unavailable-update=0. Esta configuração adiciona apenas 1 nó de pico ao node pool durante a atualização e apenas 1 nó é atualizado de cada vez, seguindo uma abordagem de "criar antes de terminar". Em comparação com a atualização contínua padrão sem picos, que é equivalente a (max-surge-update=0, max-unavailable-update=1), este método é menos disruptivo, acelera os reinícios dos pods durante as atualizações e é mais conservador na sua progressão.

É importante ter em atenção que a adoção da definição equilibrada pode gerar custos adicionais devido ao nó de pico temporário adicionado durante a atualização. Este nó adicional incorre em custos enquanto estiver ativo, o que aumenta ligeiramente a despesa geral em comparação com os métodos sem nós de pico.

Atualizações rápidas sem recursos adicionais

Para cargas de trabalho que podem tolerar 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 permite alcançar este objetivo. Com esta configuração, é possível atualizar 20 nós em simultâneo sem adicionar nós de pico. Este método de atualização segue uma abordagem de "terminar antes de criar". Como não são introduzidos nós de pico adicionais durante o processo, este método também é o mais rentável, evitando despesas adicionais associadas a nós temporários.

Atualizações rápidas e menos disruptivas

Se as suas cargas de trabalho forem sensíveis a interrupções, pode aumentar a velocidade da atualização com as seguintes definições: max-surge-update=20 e max-unavailable-update=0. Esta configuração atualiza 20 nós em paralelo de forma "criar antes de terminar".

No entanto, a velocidade geral da atualização pode ser restrita se tiver configurado um PodDisruptionBudgets (PDB) para as suas cargas de trabalho. Isto acontece porque o PDB restringe o número de pods que podem ser esvaziados em qualquer momento. Embora as configurações dos PDBs possam variar, se criar um PDB com maxUnavailable igual a 1 para uma ou mais cargas de trabalho em execução no conjunto de nós, apenas um pod dessas cargas de trabalho pode ser removido de cada vez, o que limita o paralelismo de toda a atualização.

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

O que se segue?

Para ver informações sobre como ativar e configurar atualizações rápidas para o GKE no AWS, consulte o artigo Configure atualizações rápidas de conjuntos de nós.