Este documento oferece práticas recomendadas para administradores de plataforma gerenciarem upgrades de cluster do Google Kubernetes Engine (GKE). Por padrão, o GKE faz upgrade automático da versão do plano de controle e dos nós do cluster para fornecer novos recursos, correções de bugs e patches de segurança para manter o ambiente com bom desempenho e seguro.
Para garantir que esses upgrades automáticos estejam alinhados às suas necessidades operacionais e minimizar a interrupção da carga de trabalho, o GKE oferece ferramentas para que você possa ter o máximo de controle. Este guia explica como usar essas ferramentas de maneira eficaz para manter alta performance e disponibilidade. Para entender os conceitos básicos, consulte Sobre os upgrades de cluster do GKE.
Além dos upgrades de cluster, que são apenas atualizações da versão do GKE do plano de controle e dos nós, o GKE realiza periodicamente outras atualizações no cluster. Implementar as práticas recomendadas neste documento pode ajudar a se preparar para alguns desses tipos de mudanças. Para mais informações, consulte Gerenciar mudanças no ciclo de vida do cluster para minimizar interrupções.
Para uma visão geral consolidada de todas as práticas recomendadas do GKE, consulte Práticas recomendadas para o GKE.Lista de verificação
A tabela a seguir resume as tarefas explicadas em detalhes nas seções a seguir. Recomendamos que você faça essas tarefas ao preparar o ambiente para upgrades de cluster.
| Prática recomendada | Tarefas |
|---|---|
| Escolha o equilíbrio entre a velocidade dos recursos e a estabilidade do upgrade com os canais de lançamento | |
| Escolher o momento dos upgrades com políticas de manutenção |
|
| Controlar o lançamento de upgrades em clusters | |
| Controlar como os upgrades são acionados | |
| Monitorar upgrades de cluster | |
| Minimizar a interrupção das cargas de trabalho atuais durante upgrades de nós |
Escolha o equilíbrio entre velocidade de recursos e estabilidade de upgrade com canais de lançamento
Com os canais de lançamento, você escolhe um equilíbrio entre a velocidade dos recursos e a estabilidade do upgrade. Por padrão, os clusters do GKE são inscritos no canal de lançamento normal. Quando o GKE faz upgrade do plano de controle e dos nós do cluster para fornecer patches de segurança, corrigir problemas conhecidos e introduzir novos recursos, o canal de lançamento determina quais versões do GKE o cluster executa. Por exemplo, se você quiser novos recursos mais rapidamente, escolha o canal rápido. Se quiser versões com mais estabilidade demonstrada, escolha o canal estável. Para mais informações sobre como escolher entre canais específicos, consulte Quais canais estão disponíveis.
Se você quiser fazer upgrade manual dos clusters, ainda poderá se beneficiar da escolha do canal de lançamento analisando as versões disponíveis e as metas de upgrade automático para o canal antes de selecionar uma nova versão.
Além disso, se você quiser receber versões de patch em um canal de lançamento assim que possível, por exemplo, para receber patches de segurança críticos, consulte Sobre como receber versões de patch antes.
Escolha o nível de suporte necessário para uma versão secundária
O GKE oferece um total de até 24 meses de suporte para uma versão secundária após ela ser disponibilizada no canal normal. Esse suporte inclui 14 meses de suporte padrão e aproximadamente 10 meses de suporte estendido disponível no canal Estendido. Para mais informações sobre como o GKE oferece suporte a uma versão secundária, consulte Suporte a versões secundárias.
Se você precisar manter seu cluster em uma versão secundária por mais tempo e receber patches de segurança após o fim da data do suporte padrão, ou se quiser evitar o fim da aplicação do suporte padrão, use o canal estendido. Para mais informações, consulte a seção Usar o Canal estendido quando precisar de suporte de longo prazo.
Quando a versão secundária chega ao fim do suporte, dependendo do canal de lançamento em que o cluster está inscrito, o GKE faz upgrade automático do cluster para garantir que ele permaneça com bom desempenho e seguro. Para mais informações, consulte Upgrades automáticos de cluster para segurança e compatibilidade. Se você estiver usando as ferramentas descritas neste documento para impedir ou atrasar os upgrades automáticos de cluster, recomendamos que você faça o upgrade manual dos clusters antes que a versão secundária em execução chegue ao fim do suporte. Caso contrário, o GKE vai fazer upgrade do cluster automaticamente.
Escolher o momento dos upgrades com políticas de manutenção
Para controlar quando os upgrades podem ou não acontecer, use o seguinte:
- Janelas de manutenção: escolha uma janela de tempo recorrente em que o GKE pode fazer upgrade do cluster, como fora do horário de funcionamento de pico. Se o processo de upgrade for executado além da janela de manutenção, o GKE tentará pausar a operação e retomá-la durante a próxima janela de manutenção.
- Exclusões de
manutenção:
escolha um período específico em que o GKE não pode fazer upgrade do
cluster, como durante uma grande ação promocional para uma empresa de varejo. Também é possível
usar exclusões de manutenção para adiar temporariamente os upgrades automáticos
de um cluster quando, por exemplo, você notar um problema com outros clusters
sendo atualizados para uma nova versão.
- Para casos de uso avançados, talvez seja necessário realizar manualmente determinados tipos de upgrades em vez de deixar o GKE fazer isso. É possível usar exclusões de manutenção para desativar esses tipos de upgrade automático. Por exemplo, é possível usar o escopo "Sem upgrades secundários ou de nós" para desativar todos os upgrades secundários e de nós. É necessário realizar esses upgrades manualmente ou o GKE fará o upgrade dos clusters ao final do suporte para a versão secundária.
- Frequência de manutenção: para casos de uso avançados, controle o intervalo mínimo entre dois upgrades automáticos consecutivos com o orçamento de interrupção do cluster.
Ao configurar políticas de manutenção, você aumenta a previsibilidade dos upgrades e garante que eles aconteçam quando for mais conveniente para suas cargas de trabalho.
Controlar o lançamento de upgrades em clusters
Recomendamos que você use vários ambientes para minimizar os riscos e o tempo de inatividade indesejado, testando as mudanças de software e infraestrutura separadamente do ambiente de produção. Recomendamos que você tenha pelo menos um ambiente de produção e outro de pré-produção ou teste.
Considere os seguintes ambientes recomendados:
| Ambiente | Descrição |
|---|---|
| Produção | Disponibilizar tráfego em tempo real para usuários finais de aplicativos de negócios essenciais. |
| Canário | Teste uma pequena fração do ambiente de produção antes de fazer upgrade de todos os clusters. |
| Preparo | Verifique se todas as novas mudanças implantadas de ambientes anteriores estão funcionando como esperado antes de serem implantadas na produção. |
| Teste | Faça comparativos de mercado, testes e controle de qualidade (QA) para cargas de trabalho com a versão do GKE que você vai usar na produção. |
| Desenvolvimento | Use a mesma versão em execução na produção para desenvolvimento ativo. Nesse ambiente, você cria correções e mudanças incrementais para serem implantadas na produção. |
O GKE oferece recursos como o sequenciamento de lançamento para ajudar você a controlar como os upgrades são implantados nesses diferentes ambientes, conforme detalhado na seção a seguir.
Usar o sequenciamento de lançamento para fazer lançamentos em vários ambientes
Para lançar progressivamente novas versões do GKE dentro e entre esses ambientes, recomendamos o uso do sequenciamento de lançamento. Com o sequenciamento de lançamento, todos os clusters usam o mesmo canal de lançamento e a mesma versão secundária em todas as etapas da implantação. O GKE lança progressivamente novas versões na sequência que você configura. Quando o GKE lançar a nova versão nos ambientes, verifique se o ambiente do cluster e as cargas de trabalho estão sendo executados conforme o esperado com a nova versão.
Se você estiver configurando um novo ambiente, use o sequenciamento de implantação com etapas personalizadas. Essa versão mais recente da sequência de lançamento permite dividir o lançamento de uma nova versão para uma frota em várias etapas. Com essa abordagem, o GKE pode, por exemplo, fazer upgrade de um ambiente canário na produção antes de fazer upgrade do restante da produção.
Embora não seja recomendado para novos ambientes, também é possível usar uma versão anterior do recurso, o sequenciamento de lançamento baseado em frota. Essa versão do recurso é a única com suporte no console do Cloud de Confiance , mas tem funcionalidade mais limitada.
Como testar upgrades de patch e secundários do GKE
O GKE faz upgrade automático dos clusters para um novo patch toda semana. No entanto, os upgrades de versão secundária ocorrem apenas cerca de três vezes por ano. As novas versões secundárias do Kubernetes introduzem um volume maior de mudanças em comparação com os patches da mesma versão secundária. Recomendamos que você analise com mais cuidado o lançamento de upgrades de versões secundárias nos ambientes para garantir que a nova versão secundária funcione conforme o esperado com os clusters e as cargas de trabalho.
Fazer verificações antes de fazer upgrade do cluster
Antes de realizar upgrades automáticos de cluster, o GKE qualifica novas versões por um período que depende do canal de lançamento e analisa a prontidão do cluster.
Antes de fazer upgrade de clusters, recomendamos que você faça o seguinte:
- Para todos os upgrades, incluindo patches e upgrades menores:
- Confira as notas da versão do GKE para encontrar problemas e o registro de alterações de novas versões secundárias e de patch.
- Verifique os problemas conhecidos do GKE para ver se há problemas relevantes para o ambiente do cluster e a nova versão.
- Para upgrades secundários, consulte também o seguinte:
- Verifique as descontinuações de APIs. Para mais informações, consulte a nota de lançamento do GKE para a nova versão, o registro de alterações do Kubernetes e as descontinuações de recursos e APIs.
- Verifique se há suporte para a distorção de versão entre o plano de controle e os nós. O GKE é compatível com a execução de nós até duas versões secundárias anteriores ao plano de controle. Para mais informações, consulte a política de desvio de versão do GKE.
- Para upgrades de nós:
- Verifique se você tem recursos suficientes para a estratégia de upgrade de nós usada pelos seus nós. Para mais informações, consulte Garantir recursos para upgrades de nós.
Controlar como os upgrades são acionados
Por padrão, o GKE faz upgrade automático dos clusters para novas versões regularmente. No entanto, também é possível usar upgrades manuais para atualizar o cluster exatamente quando quiser e controlar a versão que ele executa.
Faça o seguinte:
- Faça upgrade manual do cluster.
Realizar ações para upgrades de nós automáticos ou manuais em andamento, incluindo o seguinte:
- Cancele um upgrade.
- Retomar um upgrade.
- Reverter um upgrade.
- Conclua um upgrade em andamento.
Se você quiser ter mais controle sobre o processo de upgrade, recomendamos que configure exclusões de manutenção e faça upgrades manuais conforme necessário. Para mais informações sobre upgrades manuais e outras ações que podem ser realizadas em upgrades em andamento, consulte Como fazer upgrade manual de um cluster ou pool de nós.
Monitorar upgrades de cluster
Para garantir que os upgrades do GKE sejam realizados conforme o esperado e que o ambiente de cluster permaneça eficiente e disponível, use as seguintes ferramentas para monitorar os upgrades de cluster. Para ficar por dentro do status dos seus clusters, use ferramentas como notificações, insights e recomendações e registros. Recomendamos prestar atenção às notificações de fim do suporte, de início do upgrade e de ativação do upgrade programado para versões secundárias. Configure políticas de alertas para garantir que você receba essas notificações.
Use os recursos a seguir para saber mais sobre os upgrades atuais:
- Para informações sobre upgrades de clusters específicos, incluindo destinos de upgrade automático atuais, consulte Ter visibilidade dos upgrades de cluster.
- Para recuperar metas gerais de upgrade automático, consulte a tabela Versões atuais. Para um mapeamento específico para uma versão secundária de um cluster, consulte as notas da versão de Atualizações de versão.
- Confira a programação de lançamento do GKE para uma estimativa do melhor caso de quando as versões secundárias estarão disponíveis para upgrades e chegarão ao fim do suporte.
- Use as notificações de cluster para se manter informado sobre eventos de upgrade, como upgrades de cluster programados (pré-lançamento), para seus clusters usando o Cloud Logging ou o Pub/Sub.
Use insights e recomendações para receber as seguintes recomendações específicas do cluster:
Minimizar a interrupção das cargas de trabalho atuais durante upgrades de nós
Além das práticas recomendadas gerais descritas nas seções anteriores, recomendamos que você considere uma configuração avançada adicional para personalizar ainda mais o processo de upgrade e adequá-lo ao ambiente de cluster e às necessidades das suas cargas de trabalho.
Outras considerações para perfis de carga de trabalho específicos
Alguns tipos de cargas de trabalho e ambientes de cluster exigem uma preparação adicional para upgrades de cluster. Se a carga de trabalho se encaixar em uma ou mais das categorias a seguir, considere estas outras informações:
- Cargas de trabalho executadas em máquinas que não fazem migração em tempo real: os nós do GKE, que são instâncias do Compute Engine criadas pelo GKE em seu nome, exigem manutenção periódica na infraestrutura subjacente. A maioria das instâncias do Compute Engine pode fazer migração em tempo real, o que significa que as cargas de trabalho em execução não sofrem interrupções quando essa manutenção ocorre. No entanto, alguns tipos de máquina não podem ser migrados em tempo real, o que significa que as cargas de trabalho em execução nos nós do GKE podem ser interrompidas. É importante ressaltar que os aceleradores, como GPUs e TPUs para cargas de trabalho de IA/ML, não podem ser migrados em tempo real. Para mais informações, consulte Entenda como fazer a manutenção do host no GKE.
- Cargas de trabalho com restrição de capacidade: se as cargas de trabalho usarem tipos de máquina com restrição de capacidade, será necessário considerar mais fatores ao fazer upgrade de clusters. Para mais informações, consulte Garantir recursos para upgrades de nós.
- Cargas de trabalho com estado: se as cargas de trabalho tiverem estado e requisitos específicos para serem encerradas e reiniciadas de maneira saudável, será necessário considerar mais fatores ao fazer upgrades de cluster. Para mais informações, consulte Garantir que as cargas de trabalho estejam prontas para interrupções.
Consulte as seções a seguir para entender como usar as ferramentas disponíveis para fazer upgrade desses tipos de cargas de trabalho.
Escolher uma estratégia de upgrade de nós
No modo GKE Standard, o GKE oferece diferentes estratégias de upgrade de nós que determinam como os nós individuais no pool de nós são atualizados. Ao escolher uma estratégia de upgrade para o pool de nós do Standard, é possível escolher o processo com o equilíbrio certo entre velocidade, interrupção da carga de trabalho, redução de riscos, capacidade de recursos e otimização de custos. Também é possível configurar os parâmetros da estratégia para atender melhor às suas necessidades. Para mais informações, consulte Sobre as estratégias de upgrade de nós e Fazer upgrade em um ambiente restrito de recursos.
No modo Autopilot do GKE, o GKE gerencia os upgrades de nós, e você não precisa escolher a estratégia específica usada. Para mais informações, consulte Upgrades súbitos para clusters do Autopilot.
Defina a tolerância para interrupção
Use orçamentos de interrupção de pod (PDBs) para garantir que, quando o GKE recriar os nós durante os upgrades, o que pode reduzir temporariamente o número de réplicas de uma carga de trabalho, suas cargas de trabalho mantenham redundância suficiente.
Se um PDB for definido, o GKE não vai encerrar os pods no aplicativo se o número de pods for igual ou menor que um limite configurado. Os upgrades do GKE respeitam um PDB por até 60 minutos. Além disso, o GKE notifica você se uma drenagem de nó estiver sendo bloqueada por um PDB ou se o tempo limite do PDB for atingido e os pods forem excluídos à força, apesar da violação do PDB. Para mais informações, consulte Eventos de interrupção durante um upgrade de pool de nós.
Usar o encerramento otimizado para encerrar um aplicativo
É possível configurar o encerramento normal para garantir que as cargas de trabalho tenham tempo suficiente para se preparar para o desligamento. Durante os upgrades de nós, o GKE respeita as configurações de encerramento normal por até 60 minutos com os upgrades súbitos padrão e até 24 horas com os upgrades azul-verde e upgrades azul-verde com escalonamento automático (Visualização).
Para mais informações sobre como definir as configurações de encerramento normal, consulte Configurar o GKE para encerrar as cargas de trabalho normalmente.
Use o Canal estendido quando precisar de suporte de longo prazo
Se você quiser manter seu cluster em uma menor versão por mais tempo, siga as prática recomendada de inscrever seu cluster no canal estendido. Com este o GKE aceita uma versão secundária por aproximadamente 24 horas meses. Com o canal estendido, você controla os upgrades de versões secundárias, e o GKE só realiza upgrades automáticos no fim do suporte se você não iniciar o upgrade por conta própria. Para mais informações, consulte Receber suporte de longo prazo com o canal estendido.
Se você não precisar ficar em uma versão secundária por mais tempo do que o período de suporte padrão, mas ainda quiser controlar os upgrades de versão secundária, use exclusões de manutenção com o escopo "Sem upgrades secundários".
Para aproveitar o canal ao máximo, recomendamos que você siga as e siga as práticas recomendadas. Algumas dessas práticas recomendadas exigem ação manual, incluindo o upgrade manual de um cluster e alterando o lançamento canal de um cluster. Confira os seguintes cenários compatíveis e Quando não usar o Canal estendido.
Permanecer temporariamente em uma versão secundária por mais tempo
Se você precisar manter temporariamente um cluster em uma versão secundária por mais tempo período de suporte padrão de 14 meses, por exemplo, para reduzir o uso de clientes descontinuados APIs removidas na próxima versão secundária, use o processo a seguir. Você pode mover temporariamente o cluster de outro canal de lançamento para a para continuar recebendo patches de segurança enquanto se prepara para o upgrade para a próxima versão secundária. Quando estiver tudo pronto para fazer upgrade para a próxima versão secundária, você faz upgrade manual do cluster e o move de volta ao original canal de lançamento.
Upgrades de versões secundárias uma ou duas vezes por ano
Se você quiser o mínimo de interrupção para seu cluster e ainda receber recursos quando o cluster estiver pronto para ser atualizado para uma nova versão secundária, o seguinte:
- Registre um cluster no canal Extended.
- Faça dois upgrades sucessivos de versão secundária uma ou duas vezes por ano. Por exemplo, faça upgrade de 1.33 para 1.34 para 1.35.
Esse processo ajuda a garantir que o cluster permaneça em uma versão secundária disponível, receba recursos de novas versões secundárias, mas receba apenas upgrades de versão secundária quando você decidir que o cluster está pronto.
Quando não usar o canal estendido
Usar o canal estendido para a finalidade pretendida requer ação manual. A cenário a seguir ilustra as consequências de usar o Canal estendido sem o gerenciamento ativo da versão secundária do cluster.
Não fazer nada e receber upgrades menores com a mesma frequência
Para manter seu cluster com uma versão secundária para sempre, registre cluster no canal estendido e não tomar mais nenhuma ação. Todas as versões secundárias acabam se tornando incompatíveis, e o GKE faz upgrade automático dos clusters de versões secundárias sem suporte. Então, O GKE faz upgrade deste cluster de uma versão secundária incompatível para uma versões secundárias não suportadas, que representam a média de aproximadamente a cada quatro meses. Essa abordagem significa que o cluster recebe upgrades de versão secundária com a mesma frequência em outros canais de lançamento, mas recebe novos recursos depois.
A seguir
- Para mais informações sobre os diferentes modos do GKE, consulte Comparar recursos nos clusters Autopilot e Standard.