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 |
|---|---|
| Produção | 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. |
| Desenvolvimento | 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 |
|---|---|---|
| Produção | 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 | ||
| Desenvolvimento | ||
| 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. |
| N/A | Estendido | Para 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, use o Canal estendido. Para saber mais, consulte Usar o Canal estendido quando precisar de suporte de longo prazo. |
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 é,
kubeletnão pode ser mais recente quekube-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.
| Hora | 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:
| Hora | 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 |
| |
| 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.
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. Para saber mais, consulte Receber suporte de longo prazo com a .
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 para 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. Para exemplo, faça upgrade de 1.30 para 1.31 para 1.32.
Esse processo garante que o cluster permaneça em uma versão secundária disponível. recebe recursos de novas versões secundárias, mas recebe apenas a versão secundária upgrades 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 4 meses. Isso 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 posteriormente.
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
- Assista ao vídeo do Google Cloud Next 2020 sobre Como garantir a continuidade dos negócios em momentos de incerteza e empresas 100% digitais com o GKE.
- Veja as práticas recomendadas para o upgrade do GKE.
- Saiba mais sobre os canais de lançamento.
- Saiba mais sobre controle de versão e upgrades automáticos no GKE.