Upgrades de cluster de Autopilot


Nesta página, você verá como os upgrades automáticos funcionam nos clusters de Autopilot do Google Kubernetes Engine (GKE), incluindo links para mais informações sobre tarefas e configurações relacionadas. Use essas informações para manter seus clusters atualizados e ter estabilidade e segurança com interrupções mínimas nas cargas de trabalho.

Como funcionam os upgrades de pools de nós e de cluster

Nesta seção, você verá o que acontece no cluster durante upgrades automáticos. O Google inicia upgrades automáticos, observa upgrades automáticos em todos os clusters do GKE e intervém se identificar problemas.

Um cluster é atualizado antes de seus nós.

Upgrades de cluster

Nesta seção, você verá o que esperar quando o Google fizer o upgrade automático do cluster. Os clusters criados no modo Autopilot são clusters regionais. Clusters regionais têm várias réplicas do plano de controle e apenas uma é atualizada por vez, em uma ordem indefinida. Durante o upgrade, o cluster permanece altamente disponível, e cada réplica do plano de controle fica indisponível apenas durante o upgrade.

Se você configurar uma janela ou exclusão de manutenção, ela será respeitada, se possível.

Upgrades de pool de nós

O cluster do Autopilot e os respectivos pools de nós executam a mesma versão do GKE. Nesta seção, você verá o que esperar quando o Google fizer o upgrade automático do pool de nós.

Os pools de nós são atualizados um de cada vez. Em um pool de nós, os nós são atualizados individualmente, em uma ordem indefinida.

Esse processo pode levar várias horas, dependendo do número de nós e das configurações da carga de trabalho. As configurações que podem diminuir a taxa de upgrades de nós são estas:

Se você configurar uma janela ou exclusão de manutenção, ela será respeitada, se possível.

Ao fazer upgrade em um nó, ocorrem os seguintes itens:

  1. Como os upgrades súbitos são ativados por padrão, o GKE cria um novo nó súbito com a versão atualizada e espera que o nó seja registrado no plano de controle.
  2. O GKE seleciona um nó existente (que chamamos de "nó de destino") para fazer o upgrade. Ele estabelece um limite e começa a drenar o nó de destino. Neste ponto, o GKE não pode programar novos pods no nó de destino.
  3. Os pods no nó de destino são reprogramados para outros nós. Se não for possível reprogramar um pod, ele permanecerá PENDING até ser reprogramado.
  4. O nó de destino é excluído.
  5. Se um número significativo de upgrades automáticos de nó para uma determinada versão resultar em nós não íntegros na frota do GKE, esses upgrades serão interrompidos enquanto o problema é investigado.

Upgrades automáticos

Quando você cria um cluster de Autopilot, o upgrade automático é ativado nele e nos pools de nós por padrão. O Google faz upgrade dos clusters quando uma nova versão do GKE é selecionada para upgrade automático.

Para ter mais controle sobre o momento em que um upgrade automático poderá, ou não, ocorrer, configure janelas e exclusões de manutenção.

Como o cluster de Autopilot é inscrito automaticamente em um canal de lançamento, os nós sempre executam a mesma versão do GKE, exceto durante um breve período entre a conclusão do upgrade do plano de controle e o início de um determinado pool de nós.

Como as versões são selecionadas para o upgrade automático

Novas versões do GKE são lançadas regularmente, mas uma versão não é selecionada para upgrade automático imediatamente. Quando uma versão do GKE acumular uso de cluster suficiente para comprovar a estabilidade, o Google a selecionará como um objetivo de upgrade automático para clusters que executam um subconjunto de versões mais antigas.

Novos destinos de upgrade automático são anunciados nAs notas de lançamento. Às vezes uma versão é selecionada para upgrade automático de cluster e de nó durante semanas diferentes.

Logo depois que uma nova versão secundária for disponibilizada, a versão secundária mais antiga disponível não será mais compatível. Os clusters executando versões secundárias que se tornam incompatíveis são automaticamente atualizados para a próxima versão secundária.

Em uma versão secundária (como v1.14.x), os clusters podem ser atualizados automaticamente para uma nova versão de patch.

Como configurar o momento em que os upgrades automáticos podem ocorrer

Por padrão, os upgrades automáticos podem ocorrer a qualquer momento. Eles são minimamente disruptivos especialmente para clusters regionais. Porém, algumas cargas de trabalho podem exigir um controle mais preciso. É possível configurar janelas e exclusões de manutenção para gerenciar o momento em que os upgrades automáticos podem, ou não, ocorrer.

Upgrades de sobretensão

Os upgrades súbitos controlam o número de nós que o GKE pode atualizar por vez e a quantidade de interrupções que os upgrades causam nas suas cargas de trabalho. Os clusters de Autopilot são configurados automaticamente para usar upgrades súbitos e não podem ser modificados.

Os upgrades de sobretensão são determinados por duas configurações:

max-surge-upgrade
O número de nós que podem ser adicionados ao pool de nós durante um upgrade. O padrão é 1.
max-unavailable-upgrade

O número de nós que podem estar indisponíveis simultaneamente durante um upgrade. O padrão é 0.

O número de nós atualizados simultaneamente é a soma de max-surge-upgrade e max-unavailable-upgrade.

O upgrade súbito padrão é definido como maxSurge=1 maxUnavailable=0.. Isso significa que apenas um nó súbito pode ser adicionado ao pool de nós durante um upgrade para que apenas um nó seja atualizado por vez.

Relação com a cota

Ainda que a recriação de nós não exija recursos extras do Compute Engine, o upgrade de nós exige. A alocação de recursos está sujeita à cota do Compute Engine. Dependendo da configuração, essa cota pode limitar o número de upgrades paralelos ou causar falha no upgrade.

Para mais informações sobre cotas, consulte Upgrades de nós e cotas.

Como receber notificações de upgrade

O GKE publica notificações de upgrade no Pub/Sub, fornecendo um canal para receber informações do GKE sobre seus clusters.

Para mais informações, consulte Como receber notificações de upgrade de cluster.

A seguir