Sobre atualizações de surtos

Este documento fornece uma breve visão geral das atualizações contínuas padrão e, em seguida, detalha as atualizações de pico, que são um tipo especial de atualização contínua. Comparadas às atualizações contínuas padrão, as atualizações de pico permitem configurar a velocidade da atualização. As atualizações de pico também permitem que você exerça algum controle sobre o quão disruptivas as atualizações podem ser para suas cargas de trabalho.

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

Como funcionam as atualizações contínuas 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 contínua. Se o GKE na AWS puder aplicar alterações a um pool de nós sem precisar reiniciar ou recriar recursos, ele o fará para evitar interrupções.

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

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

Veja a seguir as etapas que o GKE na AWS executa durante uma atualização contínua padrão:

  1. Seleciona um nó do pool de nós e marca o nó como indisponível para garantir que nenhum novo Pod seja iniciado nele. Essa ação é chamada de cordão .
  2. Realoca os Pods ativos do nó isolado 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 dimensionador automático do cluster, que permanece ativo durante uma atualização contínua padrão, inicia um escalonamento vertical e provisiona nós adicionais para garantir que haja capacidade suficiente para agendar os Pods removidos. Para obter informações sobre as medidas tomadas para proteger as cargas de trabalho durante esse processo, consulte Proteção de carga de trabalho durante o redimensionamento .
  3. Encerra o nó isolado.
  4. Substitui o nó isolado por um novo com as configurações atualizadas.
  5. Realiza uma verificação de integridade no nó recém-operacional. Se o pool de nós falhar na verificação de integridade, ele será marcado com o status DEGRADED . Esse status pode ser visualizado executando o comando gcloud container aws node-pools describe . Quando um pool de nós é marcado como DEGRADED , novos pods podem não ser agendados nos nós dentro desse pool.
  6. Continua atualizando, nó por nó, até que todos os nós no pool tenham sido atualizados.

Como funcionam as atualizações de surtos

No GKE na AWS, o método contínuo padrão atualiza os nós um por vez. As atualizações de surto, que são uma forma de atualização contínua, permitem atualizar vários nós simultaneamente. Portanto, as atualizações de surto são mais rápidas do que as atualizações contínuas padrão. No entanto, atualizar vários nós simultaneamente pode interromper as cargas de trabalho. Para atenuar isso, as atualizações de surto oferecem opções para modular o nível de interrupção das suas cargas de trabalho.

Outra diferença entre as atualizações de surto e as atualizações contínuas padrão é a forma como os nós são substituídos. As atualizações contínuas padrão substituem os nós usando a estratégia "encerrar antes de criar". Dependendo das configurações escolhidas, as atualizações de surto podem usar a estratégia "criar antes de encerrar", a estratégia "encerrar antes de criar" ou até mesmo uma combinação de ambas.

O dimensionador automático de cluster desempenha um papel mais importante em atualizações de pico do que em atualizações contínuas padrão, e é por isso que ele aparece com destaque na seguinte lista de ações que o GKE na AWS realiza durante uma atualização de pico:

  1. Criação de novo grupo de dimensionamento automático : o GKE na AWS provisiona novos nós com as modificações especificadas pelo comando update e atribui esses novos nós a um novo grupo de dimensionamento automático (ASG) da AWS.
  2. Comportamento do escalonador automático de cluster : Assim que a atualização de pico começa, o escalonador automático de cluster é ativado para o novo grupo de escalonamento automático. O escalonador automático de cluster para o grupo de escalonamento automático original é desativado. Isso garante que todas as operações de escalonamento sejam direcionadas apenas ao novo grupo.
  3. Substituição de nós : Dependendo dos parâmetros de atualização de pico, diferentes estratégias para substituição de nós são usadas:
    • "criar antes de encerrar": esta estratégia é ativada quando o parâmetro max-surge-update é definido como um valor maior que zero. Ela gera novos nós no novo ASG antes de encerrar os antigos no ASG original, com o objetivo de minimizar interrupções no serviço.
    • "terminate before create": este 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 nós no novo ASG.
  4. Ajustes de tamanho do pool de nós : durante a atualização, o tamanho do pool de nós (ou seja, a soma dos nós no ASG antigo e no novo) pode oscilar acima ou abaixo da contagem original de nós presentes no pool de nós antes do início da atualização. Especificamente, o GKE na AWS visa manter a contagem total de nós dentro do 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 dimensionador automático de cluster pode iniciar mais nós no novo ASG se detectar que os pods não podem ser agendados, mas permanece dentro dos limites definidos por min-nodes e max-nodes .

Um exemplo para ilustrar o processo

Para entender melhor como funcionam as atualizações de pico, considere o seguinte exemplo. Suponha que você tenha um pool de nós com 5 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 é definido como 2, max-unavailable-update é definido como 1 e você está fornecendo 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 deste comando aciona uma atualização de pico e o GKE na AWS executa as seguintes ações:

  1. Cria 2 nós adicionais porque o valor de max-surge-update é igual a 2.
  2. Atribui esses 2 nós adicionais a um novo grupo de dimensionamento automático da AWS.
  3. Remove nós do grupo de dimensionamento automático original assim que esses 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, no máximo, apenas um nó fique indisponível por vez (devido ao valor 1 de max-unavailable-update ).
  4. Repita essas etapas até que todos os nós no pool de nós tenham sido atualizados para a nova versão do GKE.

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

Coisas a considerar antes de executar atualizações de pico

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

  • Instâncias adicionais criadas como parte desta etapa de aumento podem exceder o limite de cota de instâncias da AWS. Se você não tiver cota suficiente e essas instâncias adicionais não puderem ser provisionadas, a atualização poderá falhar.
  • Se max-unavailable-update for definido como 0, interrupções nas cargas de trabalho ainda poderão ocorrer, pois os pods serão removidos e reprogramados para os nós mais novos.
  • O número máximo de nós que podem ser atualizados simultaneamente é igual à soma de max-surge-update e max-unavailable-update e é limitado a 20.

Escolha as configurações de pico corretas para suas necessidades

Embora as atualizações contínuas padrão geralmente utilizem a abordagem "encerrar antes de criar", as atualizações de pico oferecem mais flexibilidade. Dependendo da configuração, as atualizações de pico podem seguir uma estratégia de "criar antes de encerrar", uma estratégia de "encerrar antes de criar" ou uma combinação de ambas. Esta seção descreve diferentes configurações para ajudar você a selecionar a melhor abordagem para suas cargas de trabalho.

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

Nome Descrição Configuração
Configuração balanceada (padrão) Equilibrado, mais lento, mas menos perturbador. maxSurge=1, maxUnavailable=0
Atualizações rápidas sem recursos extras Rápido, sem picos de recursos, muito disruptivo. maxSurge=0, maxUnavailable=20
Atualizações rápidas e menos perturbadoras Rápido, com a maioria dos recursos disponíveis e menos disruptivo. maxSurge=20, maxUnavailable=0

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

Configuração balanceada (padrão)

A maneira mais direta de usar atualizações de surto é com a configuração padrão max-surge-update=1 e max-unavailable-update=0 . Essa configuração adiciona apenas 1 nó de surto ao pool de nós durante a atualização, e apenas 1 nó é atualizado por vez, seguindo uma abordagem de "criar antes de encerrar". Comparado à atualização contínua padrão sem surto, que é equivalente a ( max-surge-update=0 , max-unavailable-update=1 ), esse método é menos disruptivo, acelera as reinicializações do Pod durante as atualizações e é mais conservador em sua progressão.

É importante observar que adotar a configuração balanceada pode gerar custos extras devido ao nó de pico temporário adicionado durante a atualização. Esse nó adicional incorre em cobranças enquanto estiver ativo, aumentando ligeiramente o custo geral em comparação com métodos sem nós de pico.

Atualizações rápidas sem recursos extras

Para cargas de trabalho que toleram interrupções, uma abordagem de atualização mais rápida pode ser adequada. Configurar max-surge-update=0 e max-unavailable-update=20 permite isso. Com essa configuração, 20 nós podem ser atualizados simultaneamente sem adicionar nenhum nó de surto. Esse método de atualização segue a abordagem "terminar antes de criar". Como nenhum nó de surto adicional é 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 e menos perturbadoras

Se suas cargas de trabalho forem sensíveis a interrupções, você pode aumentar 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 no modo "criar antes de encerrar".

No entanto, a velocidade geral da atualização pode ser limitada se você tiver configurado PodDisruptionBudgets (PDB) para suas cargas de trabalho. Isso ocorre porque o PDB restringe o número de Pods que podem ser esvaziados a qualquer momento. Embora 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, apenas um Pod dessas cargas de trabalho poderá ser esvaziado por vez, limitando o paralelismo de toda a atualização.

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

O que vem a seguir

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