Práticas recomendadas para atualizar clusters

Esta página fornece diretrizes para manter o cluster do Google Kubernetes Engine (GKE) atualizado de forma integrada, bem como recomendações para criar uma estratégia de atualização que se adapte às suas necessidades e aumente a disponibilidade e a fiabilidade dos seus ambientes. Pode usar estas informações para manter os seus clusters atualizados para garantir a estabilidade e a segurança com o mínimo de interrupções nas suas cargas de trabalho.

Em alternativa, para gerir atualizações automáticas de clusters em ambientes de produção organizados com frotas, consulte o artigo Acerca das atualizações de clusters com sequenciação de implementação.

Configure vários ambientes

Como parte do fluxo de trabalho para a publicação de atualizações de software, recomendamos que use vários ambientes. Os vários ambientes ajudam a minimizar o risco e a inatividade indesejada testando as atualizações de software e infraestrutura separadamente do seu ambiente de produção. No mínimo, deve ter 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 fornecer tráfego em tempo real aos utilizadores finais para aplicações empresariais de missão crítica.
A testar Usado para garantir que todas as novas alterações implementadas a partir de ambientes anteriores estão a funcionar conforme previsto antes de as alterações serem implementadas na produção.
Testes Usado para comparar o desempenho, testar e controlar a qualidade das cargas de trabalho com base na versão do GKE que vai usar em produção. Neste ambiente, pode testar a atualização do plano de controlo e dos nós antes de o fazer em produção.
Programação Usado para o desenvolvimento ativo que depende da mesma versão em execução na produção. Neste ambiente, cria correções e alterações incrementais a implementar na produção.
Teste Usado como um ambiente de desenvolvimento secundário para testar versões mais recentes do Kubernetes, funcionalidades e APIs do GKE para obter um melhor tempo de comercialização assim que estas versões forem promovidas e se tornarem alvos de atualização automática.

Inscreva clusters em canais de lançamento

O Kubernetes lança frequentemente atualizações para disponibilizar atualizações de segurança, corrigir problemas conhecidos e introduzir novas funcionalidades. Os canais de lançamento do GKE oferecem-lhe a capacidade de equilibrar a estabilidade e o conjunto de funcionalidades da versão implementada no cluster. Quando inscreve um novo cluster num canal de lançamento, a Google gere automaticamente a versão e a cadência de atualização do cluster e dos respetivos node pools.

Para manter os clusters atualizados com as atualizações mais recentes do GKE e do Kubernetes, seguem-se alguns ambientes recomendados e os respetivos canais de lançamento nos quais os clusters devem estar inscritos:

Ambiente Canal de lançamento Descrição
Produção Estável ou regular Para estabilidade e maturidade da versão, use o canal estável ou normal para cargas de trabalho de produção.
A testar Igual à produção Para garantir que os seus testes são indicativos da versão para a qual a produção vai ser atualizada, use o mesmo canal de lançamento que a produção.
Testes
Programação
Teste Inovação Para testar os lançamentos mais recentes do Kubernetes e antecipar-se testando novas funcionalidades ou APIs do GKE, use o canal Rápido. Pode melhorar o tempo de lançamento no mercado quando a versão no canal Rápido é promovida para o canal que está a usar para produção.
N/A Vista expandida Para manter o cluster numa versão secundária durante mais tempo e continuar a receber patches de segurança após a data de fim do apoio técnico padrão, use o canal alargado. Para saber mais, consulte o artigo Use o canal Extended quando precisar de apoio técnico a longo prazo.

Os painéis de controlo do cluster são sempre atualizados regularmente, independentemente de o cluster estar ou não inscrito num canal de lançamento.

Crie uma estratégia de atualização contínua

Depois de inscrever o cluster num canal de lançamento, este é atualizado regularmente para a versão que cumpre os requisitos de qualidade e estabilidade do canal. Estas atualizações incluem correções de segurança e erros, aplicadas com um escrutínio cada vez maior em cada canal:

  • Os patches são implementados gradualmente no painel de controlo e nos nós em todos os canais, acumulando tempo de teste nos canais Rápido e Regular antes de serem implementados no canal Estável.
  • O painel de controlo é atualizado primeiro, seguido dos nós, para agir em conformidade com a política de OSS do Kubernetes que indica que o kubelet não pode ser mais recente do que o kube-apiserver.
  • O GKE implementa automaticamente patches nos canais com base na respetiva criticidade e importância.
  • O canal estável recebe apenas patches críticos.

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

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

Para receber proativamente atualizações sobre as atualizações do GKE antes de ocorrerem, use o Pub/Sub e subscreva as notificações de atualizações.

Assim que uma nova versão ficar disponível, deve planear uma atualização antes de a versão se tornar o alvo de atualização automática para o cluster. Esta abordagem oferece mais controlo e previsibilidade quando necessário, porque o GKE não atualiza automaticamente um cluster se o destino da atualização automática disponível for anterior ou igual à versão para a qual já atualizou manualmente o cluster. Para obter alvos de atualização automática para um cluster específico, consulte o artigo Obtenha informações sobre as atualizações de um cluster.

Teste e valide novas versões de patch e secundárias

Todas as versões passam nos testes internos, independentemente do canal em que são lançadas. No entanto, com as atualizações e as correções frequentes do Kubernetes upstream e do GKE, recomendamos vivamente que teste os novos lançamentos em ambientes de teste e/ou de preparação antes de os implementar no seu ambiente de produção, especialmente as atualizações da versão secundária do Kubernetes.

Cada canal de lançamento oferece várias versões disponíveis, incluindo uma versão predefinida para a criação de clusters e alvos de atualização automática:

  • Os novos lançamentos de patches estão disponíveis uma semana antes de se tornarem alvos de atualização automática.
  • As novas versões secundárias do Kubernetes estão disponíveis quatro semanas antes de se tornarem alvos de atualização automática.

O GKE atualiza automaticamente os clusters para versões mais recentes. Se precisar de mais controlo sobre o processo de atualização, recomendamos que atualize antecipadamente para uma versão disponível. O GKE não atualiza automaticamente os clusters atualizados manualmente para o mesmo destino de atualização automática.

Uma abordagem recomendada para automatizar e simplificar as atualizações envolve:

  • Um ambiente de pré-produção que usa a versão disponível.
  • Atualize as notificações configuradas no cluster para informar a sua equipa sobre as novas versões disponíveis para teste e certificação.
  • Um ambiente de produção subscrito num canal de lançamento com uma versão que já testou no seu ambiente de pré-produção.
  • Implementação gradual de novas versões disponíveis em clusters de produção. Por exemplo, se existirem vários clusters de produção, um plano de atualização gradual começaria por atualizar uma parte destes clusters para a versão disponível, mantendo os outros na versão existente, seguido de atualizações de pequenas partes adicionais até que 100% esteja atualizado.

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

Evento Ação recomendada
A nova versão X é disponibilizada num canal. Atualize manualmente o cluster de testes, qualifique e teste a nova versão.
A versão X torna-se um destino de atualização automática para a versão secundária do cluster. O GKE inicia a atualização automática para o destino de atualização automática. Pondere atualizar a produção antes da frota.
O GKE começa a atualizar automaticamente os clusters. Permitir que os clusters sejam atualizados automaticamente ou adiar a atualização através de janelas de exclusão de manutenção.

Estratégia de atualização para lançamentos de patches

Segue-se uma estratégia de atualização recomendada para lançamentos de patches, usando um cenário em que:

  • Todos os clusters estão subscritos no canal estável.
  • As novas versões disponíveis são implementadas primeiro no cluster de preparação.
  • O cluster de produção é atualizado automaticamente para o novo destino de atualização automática.
  • Monitorizar regularmente novas versões disponíveis para o GKE.
Hora Evento O que devo fazer?
T - 1 semana Quando fica disponível uma nova versão de patch. Atualize o ambiente de preparação.
B A versão de patch torna-se o destino da atualização automática. Considere atualizar o plano de controlo de produção antecipadamente para uma melhor previsibilidade.
B O GKE começa a atualizar os painéis de controlo para o destino de atualização automática. Considere atualizar os conjuntos de nós de produção antecipadamente para uma melhor previsibilidade.
T + 1 semana O GKE começa a atualizar os node pools do cluster para o destino da atualização automática. O GKE atualiza automaticamente os clusters, ignorando os clusters atualizados manualmente.

Estratégia de atualização para novos lançamentos secundários

Segue-se uma estratégia de atualização recomendada para novos lançamentos secundários:

Hora Evento O que devo fazer?
T - 3 semanas Quando fica disponível uma nova versão secundária Atualize o plano de controlo de testes
T - 2 semanas
  1. Se a atualização do painel de controlo for bem-sucedida, considere atualizar o painel de controlo de produção antecipadamente.
  2. Atualize os node pools de teste.
T - 1 semana Se a atualização for bem-sucedida, considere atualizar os conjuntos de nós de produção com antecedência.
B A versão secundária torna-se o destino da atualização automática.
B O GKE vai começar a atualizar os painéis de controlo do cluster para o destino de atualização automática. Crie uma janela de exclusão se forem necessários mais testes ou mitigação antes da implementação em produção.
T + 1 semana O GKE começa a atualizar os node pools do cluster para o destino da atualização automática. O GKE atualiza automaticamente os clusters, ignorando os clusters atualizados manualmente.

Reduza a interrupção das cargas de trabalho existentes durante uma atualização

Manter os seus clusters atualizados com patches de segurança e correções de erros é fundamental para garantir a vitalidade dos seus clusters e a continuidade da empresa. As atualizações regulares protegem as suas cargas de trabalho contra vulnerabilidades e falhas.

Agende janelas de manutenção e exclusões

Para aumentar a previsibilidade das atualizações e alinhá-las com o horário de funcionamento fora de ponta, pode controlar as atualizações automáticas do plano de controlo e dos nós criando uma janela de manutenção. O GKE respeita os períodos de manutenção. Ou seja, se o processo de atualização for executado para além do período de manutenção definido, o GKE tenta pausar a operação e retoma a operação durante o período de manutenção seguinte.

O GKE segue um cronograma de implementação de vários dias para disponibilizar novas versões, bem como para atualizar automaticamente os planos de controlo do cluster e os nós em diferentes regiões. Geralmente, a implementação abrange quatro ou mais dias e inclui um período de tempo para observar e monitorizar problemas. Num ambiente com vários clusters, pode usar uma janela de manutenção separada para cada cluster para sequenciar a implementação nos seus clusters. Por exemplo, pode querer controlar quando os clusters em diferentes regiões recebem manutenção definindo períodos de manutenção diferentes para cada cluster.

Outra ferramenta para reduzir as interrupções, especialmente durante os períodos de grande procura, são as exclusões de manutenção. Use exclusões de manutenção para impedir que a manutenção automática ocorra durante estes períodos. As exclusões de manutenção podem ser definidas em clusters novos ou existentes. Também pode usar exclusões em conjunto com a sua estratégia de atualização. Por exemplo, pode querer adiar uma atualização para um cluster de produção se um ambiente de teste ou de preparação falhar devido a uma atualização.

Defina a sua tolerância a interrupções

Pode conhecer o conceito de réplicas no Kubernetes. As réplicas garantem a redundância das suas cargas de trabalho para um melhor desempenho e capacidade de resposta. Quando definido, as réplicas regem o número de réplicas de pods em execução em qualquer altura. 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 suas cargas de trabalho têm um número suficiente de réplicas para as suas aplicações, mesmo durante a manutenção, use um orçamento de interrupção de pods (PDB).

Num orçamento de interrupção de pods, pode definir um número (ou uma percentagem) de pods que podem ser terminados, mesmo que a terminação dos pods faça com que a contagem de réplicas atual fique abaixo do valor pretendido. Este processo pode acelerar a drenagem de nós removendo a necessidade de aguardar que os pods migrados fiquem totalmente operacionais. Em alternativa, a drenagem expulsa os pods de um nó de acordo com a configuração do PDB, o que permite a implementação de pods em falta noutros nós disponíveis. Assim que o PDB estiver definido, o GKE não encerra os pods na sua aplicação se o número de pods for igual ou inferior a um limite configurado. O GKE segue um PDB durante até 60 minutos.

Controle as atualizações de node pools

Com o GKE, pode escolher uma estratégia de atualização de nós para determinar como os nós nos seus conjuntos de nós são atualizados. Por predefinição, os pools de nós usam atualizações rápidas. Com as atualizações de picos, o processo de atualização dos pools de nós do GKE envolve a recriação de todas as VMs no pool de nós. É criada uma nova VM com a nova versão (imagem atualizada) de forma gradual. Por sua vez, isso requer o encerramento de todos os pods em execução no nó antigo e a mudança dos pods para o novo nó. As suas cargas de trabalho podem ser executadas com redundância suficiente (réplicas) e pode confiar no Kubernetes para mover e reiniciar pods conforme necessário. No entanto, um número de réplicas temporariamente reduzido pode continuar a ser prejudicial para a sua empresa e pode abrandar o desempenho da carga de trabalho até que o Kubernetes consiga novamente atingir o estado desejado (ou seja, atingir o número mínimo de réplicas necessárias). Pode evitar esta interrupção usando atualizações de picos.

Durante uma atualização com a atualização rápida ativada, o GKE primeiro protege os recursos (máquinas) necessários para a atualização, depois cria um novo nó atualizado e só então esgota o nó antigo e, finalmente, desliga-o. Deste modo, a capacidade esperada permanece intacta durante todo o processo de atualização.

Para clusters grandes em que o processo de atualização pode demorar mais tempo, pode acelerar o tempo de conclusão da atualização atualizando vários nós em simultâneo. Use a atualização rápida com maxSurge=20, maxUnavailable=0 para dar instruções ao GKE para atualizar 20 nós de cada vez, sem usar capacidade existente.

Use o canal alargado quando precisar de apoio técnico a longo prazo

Se quiser manter o cluster numa versão secundária durante mais tempo, siga a prática recomendada de inscrever o cluster no canal Extended. Com este canal, o GKE suporta uma versão secundária durante aproximadamente 24 meses. Para saber mais, consulte o artigo Obtenha apoio técnico a longo prazo com o canal alargado.

Para tirar o máximo partido do canal, recomendamos que siga as seguintes práticas recomendadas. Algumas destas práticas recomendadas requerem a realização de ações manuais, incluindo a atualização manual de um cluster e a alteração do canal de lançamento de um cluster. Reveja os seguintes cenários suportados, bem como quando não usar o canal expandido.

Permanecer temporariamente numa versão secundária durante mais tempo

Se precisar de manter temporariamente um cluster numa versão secundária durante mais tempo do que o período de apoio técnico padrão de 14 meses, por exemplo, para mitigar a utilização de APIs descontinuadas removidas na versão secundária seguinte, use o seguinte processo. Pode mover temporariamente o cluster de outro canal de lançamento para o canal Extended para continuar a receber patches de segurança enquanto se prepara para atualizar para a próxima versão secundária. Quando quiser atualizar para a versão secundária seguinte, atualize o cluster manualmente e, em seguida, mova-o novamente para o canal de lançamento original.

Atualizações de versões secundárias 1 a 2 vezes por ano

Se quiser uma interrupção mínima para o seu cluster, mas continuar a receber algumas novas funcionalidades quando o cluster estiver pronto para ser atualizado para uma nova versão secundária, faça o seguinte:

  • Inscreva um cluster no canal expandido.
  • Realizar duas atualizações sucessivas de versões secundárias 1 a 2 vezes por ano. Por exemplo, atualize de 1.30 para 1.31 e, em seguida, para 1.32.

Este processo garante que o cluster permanece numa versão secundária disponível, recebe funcionalidades de novas versões secundárias, mas só recebe atualizações da versão secundária quando decide que o cluster está pronto.

Quando não usar o canal alargado

Para usar o canal expandido para o fim a que se destina, é necessária uma ação manual. O seguinte cenário ilustra as consequências da utilização do canal Extended sem a gestão ativa da versão secundária do cluster.

Não fazer nada e receber atualizações menores com a mesma frequência

Se quiser manter o cluster numa versão secundária para sempre, inscreva o cluster no canal Extended e não tome mais nenhuma medida. Todas as versões secundárias acabam por ficar sem suporte técnico e o GKE atualiza automaticamente os clusters de versões secundárias sem suporte técnico. Assim, o GKE atualiza este cluster de uma versão secundária não suportada para uma versão secundária que vai deixar de ser suportada em breve, o que dá uma média de aproximadamente a cada 4 meses. Isto significa que o cluster recebe atualizações de versões secundárias com a mesma frequência que noutros canais de lançamento, mas recebe novas funcionalidades mais tarde.

Resumo da lista de verificação

A tabela seguinte resume as tarefas recomendadas para uma estratégia de atualização para manter os seus clusters do GKE atualizados de forma integrada:

Prática recomendada Tasks
Configure vários ambientes
Inscreva clusters em canais de lançamento
Crie uma estratégia de atualização contínua
Reduza a interrupção das cargas de trabalho existentes

O que se segue?