Neste documento, apresentamos as 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 seu 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 exercer 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 atualizações adicionais 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 seu ambiente para upgrades de cluster.
| Prática recomendada | Tarefas |
|---|---|
| Escolha o equilíbrio entre velocidade de recursos e estabilidade de upgrade com canais de lançamento | |
| Escolher o tempo 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 Regular. Quando o GKE faz upgrade do plano de controle e dos nós do cluster para oferecer 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 cedo, escolha o canal rápido. Se preferir versões com mais estabilidade comprovada, 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. Para isso, revise as versões disponíveis e os destinos de upgrade automático do 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.
Escolher 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 depois que ela é disponibilizada no Canal normal. Esse suporte inclui 14 meses de suporte padrão e aproximadamente 10 meses de suporte estendido disponível no canal Extended. 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 quiser evitar a aplicação do fim do suporte padrão, também é possível usar o canal Extended. 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 atinge o 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 upgrades automáticos de cluster, recomendamos que faça upgrade manual dos clusters antes que a versão secundária em que eles são executados chegue ao fim do suporte. Caso contrário, o GKE vai fazer upgrade automático do cluster.
Escolher o tempo dos upgrades com políticas de manutenção
Para controlar quando os upgrades podem e não podem 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. Se o processo de upgrade for executado fora 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 um grande evento de vendas para uma empresa de varejo. Você também pode usar exclusões de manutenção para adiar temporariamente os upgrades automáticos de um cluster quando, por exemplo, 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 upgrades automáticos. 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 fazer esses upgrades manualmente ou o GKE faz upgrade dos clusters ao fim 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 riscos e inatividade indesejada ao testar atualizações de software e infraestrutura separadamente do ambiente de produção. Recomendamos que você tenha, 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 |
|---|---|
| Produção | Exibir tráfego em tempo real aos usuários finais em aplicativos corporativos de missão crítica. |
| 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 conforme o esperado antes de serem implementadas 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 a 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çamentos para fazer o lançamento em vários ambientes
Para lançar progressivamente novas versões do GKE nesses ambientes, recomendamos usar o 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 seus ambientes, verifique se o ambiente de 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 lançamento com etapas personalizadas (prévia). Essa versão mais recente 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 em produção antes de fazer upgrade do restante da produção. Ou, para uma versão disponível ao público do recurso que usa um modelo mais linear sem etapas personalizadas, consulte Sobre upgrades de cluster com sequenciamento de implantação.
Como testar upgrades secundários e de patch do GKE
O GKE faz upgrade automático dos clusters para um novo patch semanalmente. No entanto, os upgrades de versão secundária ocorrem apenas 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ê aplique mais atenção durante o lançamento de upgrades de versão secundária nos ambientes para garantir que a nova versão secundária funcione conforme o esperado com seus clusters e cargas de trabalho.
Faça 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 upgrades de cluster, recomendamos que você faça o seguinte:
- Para todos os upgrades, incluindo patches e upgrades secundários:
- Confira as notas da versão do GKE para problemas e para encontrar o changelog de novas versões secundárias e de patch.
- Confira 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, confira também o seguinte:
- Verifique as descontinuações de APIs. Para mais informações, consulte a nota da versão do GKE para a nova versão, o changelog do Kubernetes e Suspensão de uso de recursos e APIs.
- Verifique se a distorção de versão entre o plano de controle e os nós é compatível. 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 em que ele é executado.
Faça o seguinte:
- Faça upgrade manual do cluster.
Realize ações para upgrades de nós automáticos ou manuais em andamento, incluindo:
- Cancele um upgrade.
- Retomar um upgrade.
- Reverta um upgrade.
- Concluir um upgrade em andamento.
Se quiser ter mais controle sobre o processo de upgrade, recomendamos que você 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 para 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 upgrades de versão secundária. Configure políticas de alertas para garantir que você receba essas notificações.
Use os seguintes recursos para saber detalhes sobre os upgrades atuais:
- Para informações sobre upgrades de clusters específicos, incluindo destinos atuais de upgrade automático, consulte Ter visibilidade dos upgrades de cluster.
- Para recuperar destinos 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 cenário de quando as versões secundárias estarão disponíveis para upgrades e atingirão o fim do suporte.
- Use as notificações de cluster para ficar informado sobre eventos de upgrade, como upgrades programados de cluster (prévia), 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 atender às necessidades do ambiente de cluster e das 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 mais preparação para upgrades. Se a carga de trabalho se encaixar em uma ou mais das categorias a seguir, considere estas informações adicionais:
- Cargas de trabalho executadas em máquinas que não fazem migração dinâmica: 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áquinas não podem ser migrados em tempo real, o que significa que as cargas de trabalho executadas nos nós do GKE podem ser interrompidas. É importante lembrar 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 Gerenciar interrupções em nós do GKE que não são migrados dinamicamente.
- 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 outros fatores ao fazer upgrades do cluster. Para mais informações, consulte Garantir recursos para upgrades de nós.
- Cargas de trabalho com estado: se as cargas de trabalho forem com estado e tiverem requisitos específicos para desligamento e reinicialização adequados, será necessário considerar outros fatores ao fazer upgrades do 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 e otimização de custos. Também é possível configurar os parâmetros da estratégia para atender melhor às suas necessidades. No modo Autopilot do GKE, o GKE gerencia os upgrades de nós e não é necessário escolher a estratégia específica usada. Para mais informações, consulte Sobre as estratégias de upgrade de nós.
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 destrutivos durante um upgrade do pool de nós.
Usar o encerramento completo para desligar 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 configurar o encerramento automático, consulte Configure 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ão secundária. 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 só receba 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 acaba se tornando incompatível, e o GKE faz upgrade automático dos clusters de objetos menores sem suporte padrão. 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.