Práticas recomendadas para fazer upgrade de clusters

Veja nesta página diretrizes para manter o cluster do Google Kubernetes Engine (GKE) atualizado continuamente e recomendações para criar uma estratégia de upgrade que atenda às suas necessidades e aumente a disponibilidade e confiabilidade do ambiente. 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 alternativa, para gerenciar upgrades automáticos de clusters em ambientes de produção organizados com frotas, consulte Sobre upgrades de cluster com sequenciamento de lançamento.

Configure vários ambientes

Como parte do fluxo de trabalho para fornecer atualizações de software, recomendamos usar vários ambientes. Vários ambientes ajudam a minimizar riscos e inatividade indesejada ao testar atualizações de software e infraestrutura separadamente do ambiente de produção. É preciso ter, no mínimo, um ambiente de produção e um ambiente de pré-produção ou de teste.

Considere os seguintes ambientes recomendados:

Ambiente Descrição
Production Usado para exibir tráfego em tempo real aos usuários finais em aplicativos corporativos de missão crítica.
Preparo Usada para garantir que todas as novas alterações implantadas de ambientes anteriores estejam funcionando conforme o esperado antes de serem implementadas na produção.
Teste Usado para comparar as cargas de trabalho de desempenho, teste e controle de qualidade em relação à versão do GKE que você usará na produção. Nesse ambiente, é possível testar o upgrade do plano de controle e dos nós antes de fazer isso na produção.
Development Usado para desenvolvimento ativo que depende da mesma versão em execução na produção. Nesse ambiente, você cria correções e alterações incrementais a serem implantadas na produção.
Canary Usado como um ambiente de desenvolvimento secundário para testar versões mais recentes do Kubernetes, os recursos e as APIs do GKE conquistaram um melhor tempo de lançamento depois que essas versões foram promovidas e se tornaram o padrão.

Inscreva clusters nos canais de lançamento

O Kubernetes lança atualizações com frequência para fornecer atualizações de segurança, corrigir problemas conhecidos e introduzir novos recursos. Os canais de lançamento do GKE oferecem a capacidade de equilibrar estabilidade e conjunto de recursos da versão implantada no cluster. Quando você inscreve um novo cluster em um canal de lançamento, o Google gerencia automaticamente a versão e a cadência do upgrade para o cluster e os respectivos pools de nós.

Para manter os clusters atualizados com as versões mais recentes do GKE e do Kubernetes, veja alguns ambientes recomendados e os respectivos canais de lançamento em que os clusters precisam ser inscritos:

Ambiente Canal de lançamento Descrição
Production Estável ou comum Para estabilidade e maturidade da versão, use o canal estável ou normal para cargas de trabalho de produção.
Preparo Igual à produção Para garantir que seus testes indiquem a versão de upgrade da produção, use o mesmo canal de lançamento.
Teste
Development
Canary Rápido Para testar as versões mais recentes do Kubernetes e se antecipar ao testar novos recursos ou APIs do GKE, use o canal rápido. É possível melhorar o tempo de lançamento quando a versão do canal rápido é promovida para o canal que você está usando para produção.

Os planos de controle de cluster sempre são atualizados regularmente, independentemente de o cluster estar inscrito em um canal de lançamento ou não.

Crie uma estratégia de upgrade contínuo

Depois de inscrever seu cluster em um canal de lançamento, esse cluster recebe upgrades regularmente para a versão que atende aos níveis de qualidade e estabilidade do canal. Essas atualizações incluem correções de segurança e bugs, aplicadas com um controle crescente em cada canal:

  • Os patches são enviados para o plano de controle e os nós em todos os canais gradualmente, acumulando o tempo de permanência em canais rápidos e normais antes de chegarem ao canal estável.
  • O plano de controle recebe o upgrade primeiro, seguido por nós para obedecer à política do Kubernetes OSS (isto é, kubelet não pode ser mais recente que kube-apiserver).
  • O GKE implementará os patches automaticamente nos canais com base na importância e urgência deles.
  • O canal estável só recebe patches importantes.

Receba atualizações sobre novas versões do GKE

As informações sobre novas versões são publicadas na página principal de Notas de lançamento do GKE, bem como em um feed RSS. Cada canal de lançamento tem uma página de notas de versão simplificada e dedicada (por exemplo: Notas de lançamento para canal estável) com informações sobre a versão recomendada do GKE para esse canal.

Para receber atualizações sobre upgrades do GKE antes deles ocorrerem, use o Pub/Sub e assine as notificações de upgrade.

Quando uma nova versão fica disponível, é necessário planejar um upgrade antes que ela se torne o padrão na frota. Essa abordagem proporciona mais controle e previsibilidade quando necessário, porque o GKE pula o upgrade automático para clusters já atualizados com antecedência.

Testar e verificar novas versões secundárias e de patch

Todas as versões passam em testes internos, independentemente do canal em que foram lançadas. No entanto, com as atualizações e patches frequentes do Kubernetes upstream e do GKE, é altamente recomendável testar novas versões nos ambientes de teste e/ou preparo antes que elas sejam implantadas no ambiente de produção, especialmente upgrades do Kubernetes de versões secundárias.

Cada canal de lançamento oferece duas versões: padrão e disponível.

  • As novas versões de patch estão disponíveis uma semana antes de se tornarem padrão.
  • Novas versões secundárias do Kubernetes estarão disponíveis quatro semanas antes de se tornarem padrão.

O GKE automaticamente faz upgrade gradual de clusters para a versão padrão. Se for necessário mais controle sobre o processo de upgrade, recomendamos fazer upgrade antecipadamente para uma versão disponível. O upgrade automático do GKE pula os clusters atualizados manualmente.

Uma abordagem recomendada para automatizar e otimizar upgrades envolve:

  • Um ambiente de pré-produção que usa a versão disponível.
  • Faça upgrade das notificações configuradas no cluster para informar sua equipe sobre as novas versões disponíveis para teste e certificação.
  • Um ambiente de produção inscrito em um canal de lançamento usando a versão padrão no canal.
  • Lançamento gradual das novas versões disponíveis nos clusters de produção. Por exemplo, se houver vários clusters de produção, um plano de upgrade gradual começará com o upgrade de uma parte desses clusters para a versão disponível, mantendo os outros na versão padrão, seguido por upgrades adicionais de partes pequenas até que seja feito o upgrade de 100%.

A tabela a seguir resume os eventos de lançamento e as ações recomendadas:

Evento Ação recomendada
A nova versão X está disponível em um canal. Faça upgrade do cluster de teste manualmente, qualifique-o e teste a nova versão.
A versão X se torna a versão padrão. O GKE inicia o upgrade automático para a versão padrão. Pense em fazer o upgrade da produção antes da frota.
O GKE inicia o upgrade automático de clusters. Permita que os clusters recebam upgrade automático ou adie o upgrade usando as janelas de exclusão de manutenção.

Estratégia de upgrade para versões de patch

Veja uma estratégia de upgrade recomendada para versões de patch com um cenário em que:

  • Todos os clusters estão inscritos no canal estável.
  • Novas versões disponíveis são lançadas primeiro no cluster de preparo.
  • O cluster de produção recebe upgrades automaticamente com novas versões padrão.
  • Monitore regularmente novas versões disponíveis do GKE.
Momento Evento O que fazer?
T - 1 semana Uma nova versão de patch fica disponível. Fazer upgrade do ambiente de preparação.
T A versão do patch se torna o padrão. Considere fazer upgrade do plano de controle de produção antecipadamente para melhorar a previsibilidade.
T O GKE começará o upgrade de planos de controle para a versão padrão. Considere fazer upgrade dos pools de nós de produção antecipadamente para melhorar a previsibilidade.
T + 1 semana O GKE começará a fazer upgrade dos pools de nós do cluster para a versão padrão. O GKE fará o upgrade automático dos clusters, ignorando os clusters atualizados manualmente.

Estratégia de upgrade para novas versões secundárias

Veja uma estratégia de upgrade recomendada para novas versões secundárias:

Momento Evento O que fazer?
T - 3 semanas Uma nova versão secundária fica disponível Fazer upgrade do plano de controle de teste
T - 2 semanas
  1. Após um upgrade bem-sucedido do plano de controle, considere fazer upgrade antecipadamente do plano de controle de produção.
  2. Faça upgrade dos pools de nós de teste.
T - 1 semana Após um upgrade bem-sucedido, considere fazer upgrade dos pools de nós de produção com antecedência.
T Uma versão secundária se torna padrão.
T O GKE começará a fazer upgrade dos planos de controle do cluster para a versão padrão. Crie uma janela de exclusão se mais testes ou reduções forem necessários antes do lançamento da produção.
T + 1 semana O GKE começará a fazer upgrade dos pools de nós para a versão padrão. O GKE fará o upgrade automático dos clusters, ignorando os clusters atualizados manualmente.

Reduza a interrupção das cargas de trabalho atuais durante um upgrade

Manter os clusters atualizados com patches de segurança e correções de bugs é essencial para garantir a vitalidade dos seus clusters e a continuidade dos negócios. As atualizações regulares protegem as cargas de trabalho de vulnerabilidades e falhas.

Programe janelas e exclusões de manutenção

Para aumentar a previsibilidade dos upgrades e alinhá-los ao horário de funcionamento fora do pico, controle os upgrades automáticos do plano de controle e dos nós criando uma janela de manutenção. O GKE respeita as janelas de manutenção. Ou seja, se o processo de upgrade for executado fora da janela de manutenção definida, o GKE tentará pausar a operação e retomá-la durante a próxima janela de manutenção.

O GKE segue uma programação de lançamento em vários dias para disponibilizar novas versões e fazer upgrade automático de planos de controle de clusters e de nós em diferentes regiões. O lançamento geralmente abrange quatro dias ou mais e inclui um período para observar e monitorar problemas. Em um ambiente com vários clusters, é possível usar uma janela de manutenção separada para cada um deles para sequenciar o lançamento entre os clusters. Por exemplo, talvez você queira controlar quando os clusters em diferentes regiões recebem manutenção, definindo janelas de manutenção diferentes para cada cluster.

Outra ferramenta para reduzir interrupções, especialmente durante períodos de alta demanda dos negócios, são as exclusões de manutenção. Use a exclusão de manutenção para evitar a manutenção automática durante esses períodos. Elas podem ser definidas em clusters novos ou atuais. Você também pode usar as exclusões junto com sua estratégia de upgrade. Por exemplo, convém adiar um upgrade de um cluster de produção se um ambiente de teste ou preparação falhar devido a um upgrade.

Defina a tolerância para interrupção

Talvez você conheça o conceito de réplicas no Kubernetes. As réplicas garantem a redundância das cargas de trabalho para melhor desempenho e capacidade de resposta. Quando definidas, as réplicas controlam o número de réplicas de pods em execução em um dado momento. No entanto, durante a manutenção, o Kubernetes remove as VMs de nós subjacentes, o que pode reduzir o número de réplicas. Para garantir que as cargas de trabalho tenham um número suficiente de réplicas para os aplicativos, mesmo durante a manutenção, use um orçamento de interrupção do pod (PDB).

Em um orçamento de interrupção de pod, é possível definir um número (ou porcentagem) de pods que pode ser encerrado, mesmo que o encerramento dos pods disponibilize a contagem de réplicas atual abaixo do valor desejado. Esse processo pode acelerar o consumo de nós ao eliminar a necessidade de esperar que os pods migrados se tornem totalmente operacionais. Em vez disso, drene pods removidos de um nó após a configuração do PDB, permitindo que a implantação implante pods ausentes em outros nós disponíveis. Depois que o PDB for definido, o GKE não encerrará os pods no aplicativo se o número de pods for igual ou menor que o limite configurado. O GKE segue um PDB por até 60 minutos.

Controle upgrades do pool de nós

Com o GKE, é possível escolher uma estratégia de upgrade de nós para determinar como é feito o upgrade dos nós nos pools. Por padrão, os pools de nós usam upgrades dinâmicos. Com upgrades súbitos, o processo de upgrade para pools de nós do GKE envolve a recriação de todas as VMs no pool de nós. Uma nova VM é criada com a nova versão (imagem com upgrade) em um modelo de atualização gradual. Isso, por sua vez, exige que todos os pods em execução no nó antigo sejam encerrados e movidos para o novo nó. As cargas de trabalho podem ser executadas com redundância suficiente (réplicas), e é possível confiar no Kubernetes para mover e reiniciar os pods conforme necessário. No entanto, um número temporariamente reduzido de réplicas ainda pode atrapalhar os negócios e diminuir o desempenho da carga de trabalho até que o Kubernetes consiga atingir o estado desejado novamente (ou seja, atingir o número mínimo de réplicas necessárias). Para evitar essa interrupção, use os upgrades súbitos.

Durante um upgrade súbito, o GKE primeiro protege os recursos (máquinas) necessários para o upgrade e cria um novo nó atualizado. Em seguida, ele apenas drena o nó antigo e o encerra. Dessa forma, a capacidade esperada permanece intacta durante todo o processo de upgrade.

Para clusters grandes em que o processo de upgrade pode demorar mais, é possível acelerar o tempo de conclusão do upgrade atualizando simultaneamente vários nós de uma só vez. Use o upgrade súbito com maxSurge=20, maxUnavailable=0 para instruir o GKE a fazer o upgrade de 20 nós por vez, sem usar a capacidade atual.

Lista de verificação resumida

A tabela a seguir resume as tarefas recomendadas para uma estratégia de upgrade para manter seus clusters do GKE sempre atualizados:

Prática recomendada Tarefas
Configure vários ambientes
Inscreva clusters nos canais de lançamento
Crie uma estratégia de upgrade contínuo
Reduza a interrupção das cargas de trabalho atuais

A seguir