Períodos de manutenção e exclusões

Esta página descreve as janelas de manutenção e as exclusões de manutenção, que são políticas que oferecem controlo sobre quando é possível e não é possível realizar alguma manutenção de clusters, como atualizações automáticas, nos seus clusters do Google Kubernetes Engine (GKE). Por exemplo, uma empresa de retalho pode limitar a manutenção para que ocorra apenas nas noites dos dias úteis e pode impedir a manutenção automática durante um evento de vendas importante da indústria.

Acerca das políticas de manutenção do GKE

As políticas de manutenção do GKE, que incluem períodos de manutenção e exclusões, dão-lhe controlo sobre quando pode ocorrer determinada manutenção automática nos seus clusters, incluindo atualizações de clusters e outras alterações à configuração dos nós ou à topologia de rede do cluster.

Um período de manutenção é um período de tempo repetido durante o qual a manutenção automática do GKE é permitida.

Uma exclusão de manutenção é um intervalo de tempo não repetitivo durante o qual a manutenção automática do GKE é proibida.

O GKE faz alterações automáticas que respeitam as políticas de manutenção do seu cluster quando existe uma janela de manutenção aberta e nenhuma exclusão de manutenção ativa. Para cada cluster, pode configurar um período de manutenção recorrente e várias exclusões de manutenção.

Outros tipos de manutenção não dependem das políticas de manutenção do GKE, incluindo operações de reparação do plano de controlo e manutenção de serviços dos quais o GKE depende, como o Compute Engine. Para saber mais, consulte o artigo Manutenção automática que não respeita as políticas de manutenção.

Que alterações respeitam e não respeitam as políticas de manutenção do GKE

Antes de configurar as políticas de manutenção do GKE, as janelas de manutenção e as exclusões, reveja as secções seguintes para compreender como o GKE e os serviços relacionados as respeitam ou não.

Manutenção automática que respeita as políticas de manutenção do GKE

Com as políticas de manutenção do GKE, pode controlar a sincronização dos seguintes tipos de eventos, que causam uma interrupção temporária no seu cluster:

Outros tipos de manutenção automática não dependem de políticas de manutenção. Para saber mais, consulte o artigo Manutenção automática que não respeita as políticas de manutenção.

Manutenção automática que não respeita as políticas de manutenção do GKE

As janelas de manutenção e as exclusões do GKE não bloqueiam todos os tipos de manutenção automática. Antes de configurar as políticas de manutenção do cluster do GKE, certifique-se de que compreende que tipos de alterações não respeitam as janelas de manutenção e as exclusões.

Outra Google Cloud manutenção

As janelas de manutenção e as exclusões do GKE não impedem a manutenção automática dos serviços subjacentes, principalmente do Compute Engine, nem dos serviços que instalam aplicações no cluster, como o Cloud Deploy. Google Cloud

Por exemplo, os nós do GKE são VMs do Compute Engine que o GKE gere para o seu cluster. Por vezes, as VMs do Compute Engine têm eventos do anfitrião, que podem incluir eventos de manutenção ou erros do anfitrião. O comportamento das VMs durante estes eventos é determinado pela política de manutenção do anfitrião da VM, que, por predefinição para a maioria das VMs, significa migrar em direto. Normalmente, isto significa um tempo de inatividade mínimo ou inexistente para os nós e, para a maioria das cargas de trabalho, as políticas predefinidas são suficientes. Para algumas famílias de máquinas virtuais, pode monitorizar e planear um evento de manutenção do anfitrião e acionar um evento de manutenção do anfitrião para sincronizá-lo com as suas políticas de manutenção do GKE.

Algumas VMs, incluindo as que têm GPUs e TPUs, não podem realizar a migração em direto. Se estiver a usar estes aceleradores, saiba como lidar com a interrupção devido à manutenção de nós para GPUs ou TPUs.

Recomendamos que reveja as informações sobre os eventos do anfitrião, as políticas de manutenção do anfitrião e confirme que as suas cargas de trabalho estão preparadas para interrupções, especialmente se estiverem a ser executadas em nós que não podem realizar uma migração em direto.

Reparações e redimensionamento automáticos

O GKE faz reparações automáticas nos planos de controlo. Isto inclui processos como aumentar a escala do plano de controlo para um tamanho adequado ou reiniciar o plano de controlo para resolver problemas. A maioria das reparações ignora as janelas de manutenção e as exclusões porque a não realização das reparações pode resultar em clusters não funcionais.

Não é possível desativar as reparações do plano de controlo. No entanto, a maioria dos tipos de clusters, incluindo os clusters do Autopilot e os clusters regionais padrão, tem várias réplicas dos planos de controlo, o que permite uma elevada disponibilidade do servidor da API Kubernetes, mesmo durante eventos de manutenção. Não é possível modificar os clusters zonais padrão, que só têm um único painel de controlo, durante as alterações de configuração do painel de controlo e a manutenção do cluster. Isto inclui a implementação de cargas de trabalho.

Os nós também têm uma funcionalidade de reparação automática, que pode desativar para clusters padrão.

Aplicação de patches de vulnerabilidades de segurança críticas

As janelas de manutenção e as exclusões podem atrasar os patches de segurança. No entanto, o GKE reserva-se o direito de substituir as políticas de manutenção para vulnerabilidades de segurança críticas.

Manutenção da base de dados de estado do cluster baseada no Spanner

Alguns clusters do GKE usam uma base de dados de chave-valor do Spanner para armazenar o estado dos recursos da API Kubernetes. As operações de manutenção nesta base de dados ignoram quaisquer períodos de manutenção e exclusões ativos. No entanto, a base de dados de estado do cluster baseada no Spanner é replicada e permanece disponível durante os eventos de manutenção.

Alterações manuais que respeitam as políticas de manutenção do GKE

Algumas alterações aos nós ou à configuração de rede requerem que os nós sejam recriados para aplicar a nova configuração, incluindo algumas das seguintes alterações:

Estas alterações respeitam as políticas de manutenção do GKE, o que significa que o GKE aguarda uma janela de manutenção aberta e aguarda que não haja nenhuma exclusão de manutenção ativa que impeça a manutenção dos nós. Para aplicar manualmente as alterações aos nós, use a CLI do Google Cloud para chamar o comando gcloud container clusters upgrade e transmitir a flag --cluster-version com a mesma versão do GKE que o conjunto de nós já está a executar.

Alterações manuais que não respeitam as políticas de manutenção do GKE

Algumas alterações manuais recriam os nós através de uma estratégia de atualização de nós imediatamente sem respeitar as políticas de manutenção. Para mais detalhes, consulte o artigo Alterações manuais que recriam os nós através de uma estratégia de atualização de nós sem respeitar as políticas de manutenção.

Períodos de manutenção

As janelas de manutenção permitem-lhe controlar quando podem ocorrer atualizações automáticas dos planos de controlo e dos nós, para mitigar potenciais interrupções transitórias nas suas cargas de trabalho. Os períodos de manutenção são úteis para os seguintes tipos de cenários, entre outros:

  • Horas fora de ponta: quer minimizar a probabilidade de tempo de inatividade agendando atualizações automáticas durante as horas fora de ponta, quando o tráfego é reduzido.
  • De serviço: quer garantir que as atualizações ocorrem durante o horário de expediente para que alguém possa monitorizá-las e gerir quaisquer problemas inesperados.
  • Atualizações de vários clusters: quer implementar atualizações em vários clusters em diferentes regiões, um de cada vez, em intervalos especificados.

Além das atualizações automáticas, a Google pode ter de efetuar outras tarefas de manutenção ocasionalmente e respeita o período de manutenção de um cluster se possível.

Se as tarefas forem executadas para além do período de manutenção, o GKE tenta pausá-las e tenta retomá-las durante o período de manutenção seguinte.

O GKE reserva-se o direito de implementar atualizações de emergência não planeadas fora das janelas de manutenção. Além disso, as atualizações obrigatórias de software descontinuado ou desatualizado podem ocorrer automaticamente fora dos períodos de manutenção.

Para saber como configurar um período de manutenção para um cluster novo ou existente, consulte o artigo Configure um período de manutenção.

Fusos horários para períodos de manutenção

Quando configura e vê os períodos de manutenção, as horas são apresentadas de forma diferente consoante a ferramenta que está a usar:

Ao configurar janelas de manutenção

As horas são sempre armazenadas em UTC. No entanto, quando configura o período de manutenção, usa o fuso horário UTC ou o seu fuso horário local.

Quando configura janelas de manutenção com a flag --maintenance-window mais genérica, não pode especificar um fuso horário. A Hora Universal Coordenada (UTC) é usada quando usa a CLI gcloud ou a API, e a Google Cloud consola apresenta horas com o fuso horário local.

Quando usar flags mais detalhadas, como --maintenance-window-start, pode especificar o fuso horário como parte do valor. Se omitir o fuso horário, é usado o seu fuso horário local.

Quando vê períodos de manutenção

Quando vê informações sobre o seu cluster, as indicações de tempo das janelas de manutenção podem ser apresentadas em UTC ou no seu fuso horário local, consoante a forma como está a ver as informações:

  • Quando usa a Google Cloud consola para ver informações sobre o seu cluster, as horas são sempre apresentadas no fuso horário local.
  • Quando usa a CLI gcloud para ver informações sobre o seu cluster, as horas são sempre apresentadas em UTC.

Em ambos os casos, o RRULE está sempre em UTC. Isto significa que, se especificar, por exemplo, os dias da semana, esses dias estão em UTC.

Exclusões de manutenção

Com as exclusões de manutenção, pode impedir que a manutenção automática ocorra durante um período específico. Por exemplo, muitas empresas de retalho têm diretrizes empresariais que proíbem alterações à infraestrutura durante a época festiva de final do ano. Como outro exemplo, se uma empresa estiver a usar uma API agendada para descontinuação, pode usar exclusões de manutenção para pausar atualizações secundárias, o que lhe dá tempo para migrar aplicações.

Para eventos conhecidos de alto impacto, recomendamos que faça corresponder quaisquer restrições de alterações internas a uma exclusão de manutenção que comece uma semana antes do evento e dure durante o evento.

As exclusões não têm recorrência. Em alternativa, crie cada instância de uma exclusão periódica separadamente.

Quando as exclusões e as janelas de manutenção se sobrepõem, as exclusões têm precedência.

Para saber como configurar exclusões de manutenção para um cluster novo ou existente, consulte o artigo Configure uma exclusão de manutenção.

Âmbito da manutenção a excluir

Não só pode especificar quando impedir a manutenção automática no seu cluster, como também pode restringir o âmbito das atualizações automáticas que possam ocorrer. Os âmbitos de exclusão de manutenção são úteis para os seguintes tipos de cenários, entre outros:

  • Sem atualizações: evite qualquer manutenção: quer evitar temporariamente qualquer alteração ao cluster durante um período específico. Este é o âmbito predefinido.
  • Sem atualizações secundárias: manter a versão secundária atual do Kubernetes: quer manter temporariamente a versão secundária de um cluster para evitar alterações à API ou validar a próxima versão secundária.
  • Sem atualizações menores ou de nós: evite a interrupção de nós: quer evitar temporariamente qualquer despejo e reagendamento das suas cargas de trabalho devido a atualizações de nós.

A tabela seguinte indica como cada um destes âmbitos restringe as atualizações secundárias ou de patches para os painéis de controlo ou os nós do cluster.

Quando o GKE atualiza um cluster, as VMs do painel de controlo e do nó são reiniciadas. Para os painéis de controlo, os clusters do Autopilot e Standard regionais mantêm a disponibilidade do servidor da API Kubernetes. Nos clusters zonais, que têm um único nó do plano de controlo, os reinícios da VM tornam o plano de controlo temporariamente indisponível. Para os nós, os reinícios de VMs acionam o reagendamento de pods, o que pode interromper temporariamente as cargas de trabalho existentes. Pode definir a sua tolerância para a interrupção da carga de trabalho usando um orçamento de interrupção de pods (PDB).

Âmbito Plano de controlo Nós
Atualização secundária automática Atualização automática de patches Atualização secundária automática Atualização automática de patches
Sem atualizações (predefinição) Não permitido Não permitido Não permitido Não permitido
Sem atualizações secundárias Não permitido Permitido Não permitido Permitido
Sem atualizações menores ou de nós Não permitido Permitido Não permitido Não permitido

Para ver as definições das versões secundárias e de patch, consulte o artigo Esquema de controlo de versões.

Várias exclusões

Pode definir várias exclusões num cluster. Estas exclusões podem ter âmbitos diferentes e podem ter intervalos de tempo sobrepostos. O exemplo de utilização da época festiva de final do ano é um exemplo de exclusões sobrepostas, em que os âmbitos "Sem atualizações" e "Sem atualizações menores" estão em utilização.

Quando as exclusões se sobrepõem, se alguma exclusão ativa (ou seja, a hora atual está dentro do período de exclusão) bloquear uma atualização, a atualização é adiada.

Usando o exemplo de utilização da época festiva de final do ano, um cluster tem as seguintes exclusões especificadas:

  • Sem atualizações menores: 30 de setembro a 15 de janeiro
  • Sem upgrades: 19 de novembro a 4 de dezembro
  • Sem upgrades: 15 de dezembro a 5 de janeiro

Como resultado destas exclusões sobrepostas, as seguintes atualizações vão ser bloqueadas no cluster:

  • Atualização de patch para o node pool a 25 de novembro (rejeitada pela exclusão "Sem atualizações")
  • Atualização secundária do painel de controlo a 20 de dezembro (rejeitada pela exclusão "Sem atualizações secundárias" e "Sem atualizações")
  • Atualização de patch para o painel de controlo a 25 de dezembro (rejeitada pela exclusão "Sem atualizações")
  • Atualização secundária do node pool a 1 de janeiro (rejeitada pela exclusão "Sem atualizações secundárias" e "Sem atualizações")

A seguinte manutenção seria permitida no cluster:

  • Atualização de patch para o plano de controlo a 10 de novembro (permitida pela exclusão "Sem atualizações secundárias")
  • Interrupção da VM devido à manutenção do GKE a 10 de dezembro (permitida pela exclusão "Sem atualizações menores")

Expiração da exclusão

Quando uma exclusão expira (ou seja, a hora atual ultrapassou a hora de fim especificada para a exclusão), essa exclusão deixa de impedir as atualizações do GKE. Outras exclusões que ainda são válidas (não expiradas) continuam a impedir as atualizações do GKE.

Quando não existem exclusões nem outros fatores que impeçam as atualizações dos clusters, o GKE atualiza gradualmente o cluster para destinos de atualização automática elegíveis.

Se o seu cluster perdeu várias atualizações de versões secundárias devido à exclusão, o GKE agenda aproximadamente uma atualização de versão secundária por mês, atualizando o painel de controlo e os nós do cluster para garantir que o cluster executa uma versão suportada. Pode sempre executar atualizações manuais para atualizar o cluster para uma versão secundária específica mais cedo.

Limitações na configuração de exclusões de manutenção

As exclusões de manutenção têm as seguintes limitações:

  • Só pode restringir o âmbito das atualizações automáticas numa exclusão de manutenção para clusters inscritos num canal de lançamento. Para clusters não inscritos num canal de lançamento, só pode criar uma exclusão de manutenção com o âmbito "Sem atualizações" predefinido.
  • Pode adicionar um máximo de três exclusões de manutenção que excluem todas as atualizações (ou seja, um âmbito de "sem atualizações"). Estas exclusões têm de ser configuradas para permitir, pelo menos, 48 horas de disponibilidade de manutenção num período contínuo de 32 dias.
  • Pode ter um máximo de 20 exclusões de manutenção para cada cluster.
  • Se não especificar um âmbito na exclusão, o âmbito predefinido é "no upgrades" (sem atualizações).
  • Pode definir exclusões de manutenção com durações diferentes, consoante o âmbito. Reveja a linha Duração da exclusão de manutenção na secção Configure uma exclusão de manutenção para ver mais detalhes.
  • Não pode configurar uma exclusão de manutenção para incluir ou exceder a data de fim do suporte da versão secundária correspondente à inscrição do canal de lançamento do cluster. Veja os seguintes exemplos:
    • Um cluster está a executar uma versão secundária no canal estável, onde o calendário de lançamentos do GKE indica que a data de fim do suporte padrão é 5 de junho de 2025. Tem de definir a hora de fim da exclusão de manutenção para 2025-06-05T00:00:00Z ou anterior.
    • Um cluster está a executar uma versão secundária no canal alargado em que o cronograma de lançamentos do GKE indica que a data de fim do apoio técnico alargado é 5 de abril de 2026. Tem de definir a hora de fim da exclusão de manutenção para 2026-04-0500:00:00Z ou antes. Se quiser alterar o canal de lançamento do cluster para outro canal, tem de alterar a hora de fim da exclusão de manutenção se exceder o fim do apoio técnico padrão. Para saber mais, consulte o artigo Altere o cluster a partir do canal expandido.

As exclusões de manutenção não afetam as atualizações manuais nem as versões dos novos nós

As exclusões de manutenção impedem que os nós e os planos de controlo existentes sejam atualizados automaticamente, consoante o âmbito da exclusão de manutenção. No entanto, as exclusões de manutenção não impedem as seguintes alterações:

  • Atualizar manualmente o painel de controlo ou os nós do cluster.
  • Criar um novo node pool padrão com uma versão posterior à dos node pools padrão existentes, em que uma exclusão de manutenção está a impedir as atualizações automáticas.
  • O aprovisionamento automático dos nós cria os seguintes recursos com uma versão posterior à dos nós existentes, em que uma exclusão de manutenção está a impedir as atualizações automáticas:
    • Novos node pools padrão.
    • Novos nós num cluster do Autopilot.

Suponhamos que criou uma exclusão de manutenção para o seu cluster com um âmbito em que o GKE atualiza automaticamente o plano de controlo, mas não os nós, para versões de patch posteriores. Neste cenário, o GKE pode criar novos conjuntos de nós ou nós criados através do aprovisionamento automático que executam a versão de patch mais recente do plano de controlo.

Os nós do cluster só podem executar versões do GKE iguais ou anteriores à do plano de controlo. As exclusões de manutenção impedem as atualizações automáticas dos nós existentes. Se o plano de controlo tiver uma versão mais recente do que os nós existentes, os nós criados recentemente ou atualizados manualmente podem executar uma versão mais recente do GKE do que os nós que estão restritos de atualizações automáticas por exclusões de manutenção.

Exemplos de utilização

Seguem-se alguns exemplos de utilização para restringir o âmbito das atualizações que podem ocorrer.

Exemplo: retalhista a preparar-se para a época festiva de final do ano

Neste exemplo, a empresa de retalho não quer interrupções durante os períodos de vendas com maior volume, que são os quatro dias que abrangem a Black Friday até à Cyber Monday e o mês de dezembro até ao início do novo ano. Em preparação para a temporada de compras, o administrador do cluster configura as seguintes exclusões:

  • Sem atualizações secundárias: permita apenas atualizações de patches no plano de controlo e nos nós entre 30 de setembro e 15 de janeiro.
  • Sem atualizações: congele todas as atualizações entre 19 de novembro e 4 de dezembro.
  • Sem atualizações: congele todas as atualizações entre 15 de dezembro e 5 de janeiro.

Se não se aplicar nenhuma outra janela de exclusão quando a exclusão de manutenção expirar, o cluster é atualizado para uma nova versão secundária do GKE se tiver sido disponibilizada entre 30 de setembro e 6 de janeiro.

Exemplo: empresa que usa uma API beta no Kubernetes que está a ser removida

Neste exemplo, uma empresa está a usar a API CustomResourceDefinition apiextensions.k8s.io/v1beta1, que vai ser removida na versão 1.22. Enquanto a empresa estiver a executar versões anteriores à 1.22, o administrador do cluster configura a seguinte exclusão:

  • Sem atualizações secundárias: congele as atualizações secundárias durante três meses enquanto migra as aplicações do cliente de apiextensions.k8s.io/v1beta1 para apiextensions.k8s.io/v1.

Exemplo: a base de dados antiga da empresa não é resiliente a atualizações do conjunto de nós

Neste exemplo, uma empresa está a executar uma base de dados que não responde bem a despejos de pods e reagendamentos que ocorrem durante uma atualização do conjunto de nós. O administrador do cluster configura a seguinte exclusão:

  • Sem atualizações secundárias ou de nós: congele as atualizações de nós durante três meses. Quando a empresa estiver pronta para aceitar o tempo de inatividade da base de dados, aciona uma atualização manual do nó.

O que se segue?