Janelas de manutenção e exclusões

Nesta página, descrevemos janelas de manutenção e exclusões de manutenção, que são políticas que fornecem controle sobre quando alguma manutenção de cluster, como upgrades automáticos, pode e pode não ocorram nos clusters do Google Kubernetes Engine (GKE). Por exemplo, uma empresa de varejo pode limitar a manutenção para ocorrer apenas à noite durante a semana e impedir a manutenção automatizada durante um importante evento de vendas do setor.

Sobre as políticas de manutenção do GKE

As políticas de manutenção do GKE, que incluem janelas de manutenção e exclusões, permitem controlar quando determinadas manutenção automática podem ocorrer nos clusters, incluindo upgrades de cluster e outras alterações na configuração do nó ou a topologia de rede do cluster.

Uma janela de manutenção é uma janela de tempo repetitiva em que a manutenção automática é permitida.

Uma exclusão de manutenção é uma janela de tempo não recorrente em que a manutenção automática do GKE é proibida.

O GKE faz alterações automáticas que respeitam as políticas de manutenção do cluster quando há uma janela de manutenção aberta e nenhuma exclusão de manutenção ativa. Para cada cluster, é possível configurar uma janela 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 reparo do plano de controle e manutenção de serviços de que o GKE depende, como o Compute Engine. Para saber mais, consulte Manutenção automática que não respeita as políticas de manutenção.

Quais mudanças fazem ou não respeitam as políticas de manutenção do GKE

Antes de configurar as políticas de manutenção do GKE (janelas e exclusões de manutenção), consulte as seções a seguir para entender como o GKE e os serviços relacionados fazem ou não as respeitam.

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

Com as políticas de manutenção do GKE, é possível controlar o tempo dos seguintes tipos de eventos, que causam interrupções temporárias no cluster:

Outros tipos de manutenção automática não dependem de políticas de manutenção. Para saber mais, consulte 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 e exclusões de manutenção 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, entenda que tipos de alteração não respeitam as janelas e exclusões de manutenção.

Outras manutenções do Google Cloud

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

Por exemplo, os nós do GKE são VMs do Compute Engine que o GKE gerencia para o cluster. Às vezes, as VMs do Compute Engine sofrem eventos de host, que podem incluir eventos de manutenção ou erros. A maneira como as VMs se comportam durante esses eventos é determinada pela política de manutenção do host da VM, que, por padrão, significa migrar em tempo real. Geralmente, isso significa pouco ou nenhum tempo de inatividade para os nós e, para a maioria das cargas de trabalho, as políticas padrão são suficientes. Para algumas famílias de máquinas de VM, é possível monitorar e planejar um evento de manutenção do host e acionar um evento desse tipo para cronometrar o evento. 101}suas políticas de manutenção do GKE.

Algumas VMs, incluindo aquelas com GPUs e TPUs, não podem executar a migração em tempo real. Se você estiver usando esses aceleradores, saiba como lidar com interrupções devido à manutenção de nós para GPUs ou TPUs. ,

Recomendamos que você analise as informações sobrehospedar eventos .políticas de manutenção do host e confirme se as cargas de trabalho estão preparadas para interrupções, especialmente se estiverem em execução em nós que não podem realizar uma migração em tempo real.

Reparos e redimensionamentos automatizados

O GKE executa reparos automáticos nos planos de controle. Isso inclui processos como o aumento do plano de controle para um tamanho apropriado ou a reinicialização do plano de controle para resolver problemas. A maioria dos reparos ignora as janelas e exclusões de manutenção porque a não realização dos reparos pode resultar em clusters inoperantes.

Não é possível desativar os reparos do plano de controle. No entanto, a maioria dos tipos de clusters, incluindo os clusters do Autopilot e os clusters regionais padrão, têm várias réplicas dos planos de controle. , o que permite alta disponibilidade do servidor da API Kubernetes, mesmo durante eventos de manutenção. Os clusters zonais padrão, que têm apenas um plano de controle, não podem ser modificados durante as mudanças na configuração do plano de controle e na manutenção do cluster. Isso inclui a implantação de cargas de trabalho.

Os nós também têm a funcionalidade de reparo automático, que pode ser desativada para clusters padrão.

Patch de vulnerabilidades de segurança crítica

Janelas e exclusões de manutenção podem causar atrasos nos patches de segurança. O GKE se reserva o direito de ignorar as políticas de manutenção por vulnerabilidades críticas de segurança.

Mudanças manuais que respeitam as políticas de manutenção do GKE

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

Essas 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 espera nenhuma exclusão de manutenção ativa que impeça a manutenção do nó. Para aplicar manualmente as alterações aos nós, use a CLI do Google Cloud para chamar o comando gcloud container clusters upgrade e transmita a sinalização --cluster-version com a mesma versão do GKE que o o pool de nós já está em execução.

Janelas de manutenção

Com as janelas de manutenção, é possível controlar o momento em que as atualizações automáticas de planos de controle e nós podem ocorrer para reduzir as possíveis interrupções temporárias nas cargas de trabalho. As janelas de manutenção são úteis para os seguintes tipos de cenários, entre outros:

  • Fora dos horários de pico: minimize a chance de inatividade programando os upgrades automáticos fora dos horários de pico, quando o tráfego é reduzido.
  • Em serviço: garanta que os upgrades aconteçam durante as horas de trabalho para que alguém possa monitorá-los e gerenciar problemas imprevistos.
  • Upgrades de vários clusters: implemente upgrades em vários clusters em diferentes regiões, uma de cada vez, em intervalos especificados.

Além dos upgrades automáticos, é possível que o Google precise realizar outras tarefas de manutenção de vez em quando. Se possível, ele respeita a janela de manutenção de um cluster.

Se as tarefas forem executadas fora da janela de manutenção, o GKE tentará pausá-las e retomá-las durante a próxima janela de manutenção.

O GKE se reserva o direito de lançar upgrades de emergência não planejados fora das janelas de manutenção. Além disso, os upgrades obrigatórios de softwares obsoletos ou desatualizados podem ocorrer automaticamente fora das janelas de manutenção.

Para saber como configurar uma janela de manutenção para um cluster novo ou atual, consulte Configurar uma janela de manutenção.

Fusos horários para janelas de manutenção

Ao configurar e visualizar janelas de manutenção, os horários são mostrados de maneira diferente, dependendo da ferramenta usada:

Ao configurar janelas de manutenção

Os horários são sempre armazenados em UTC. No entanto, ao configurar a janela de manutenção, use UTC ou seu fuso horário local.

Quando você configura janelas de manutenção usando a sinalização --maintenance-window mais genérica, não pode especificar um fuso horário. O UTC é usado com a CLI gcloud ou com a API, e o console do Google Cloud exibe os horários de acordo com o fuso horário local.

Ao usar sinalizações mais granulares, como --maintenance-window-start, é possível especificar o fuso horário como parte do valor. Se você omitir o fuso horário, o fuso horário local será usado.

Ao visualizar janelas de manutenção

Ao visualizar informações sobre o cluster, os carimbos de data/hora das janelas de manutenção podem ser exibidos em UTC ou no fuso horário local, dependendo de como você estiver visualizando as informações:

  • Ao usar o console do Google Cloud para ver informações sobre o cluster, os horários são sempre exibidos no fuso horário local.
  • Ao usar a CLI gcloud para visualizar informações sobre o cluster, os horários são sempre exibidos em UTC.

Em ambos os casos, o RRULE está sempre em UTC. Isso significa que se forem especificados, por exemplo, dias da semana, esses dias estarão em UTC.

Exclusões de manutenção

Com as exclusões de manutenção, é possível impedir a manutenção automática durante um período específico. Por exemplo, muitas empresas de varejo têm diretrizes comerciais que proíbem alterações de infraestrutura durante as festas de final de ano. Outro exemplo: se uma empresa usa uma API programada para suspensão de uso, ela pode usar exclusões de manutenção para pausar upgrades menores e, assim, ter tempo de migrar os aplicativos.

Para eventos conhecidos de alto impacto, recomendamos que você corresponda quaisquer restrições de alteração interna a uma exclusão de manutenção que comece uma semana antes do evento e dure enquanto o evento durar.

As exclusões não têm recorrência. Em vez disso, 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 atual, consulte Configurar uma exclusão de manutenção.

Escopo de manutenção a ser excluído

É possível não apenas especificar quando evitar a manutenção automática no cluster, mas também é possível restringir o escopo das atualizações automáticas que podem ocorrer. Os escopos de exclusão de manutenção são úteis para os seguintes tipos de cenários, entre outros:

  • Nenhum upgrade: evita a manutenção: você quer evitar qualquer alteração no seu cluster temporariamente durante um período específico. Esse é o escopo padrão.
  • Nenhum upgrade secundário: mantém a versão secundária atual do Kubernetes: você quer manter temporariamente a versão secundária de um cluster para evitar mudanças na API ou validar a próxima versão secundária.
  • Nenhum upgrade secundário ou de nó: impede a interrupção de nós: você quer evitar temporariamente qualquer remoção e reprogramação das cargas de trabalho devido a upgrades de nós.

A tabela a seguir lista como cada um desses escopos restringe upgrades secundários ou de patch para planos de controle ou nós do cluster.

Quando o GKE faz upgrade de um cluster, as VMs do plano de controle e do nó são reiniciadas. Para planos de controle, os clusters Standard regionais e Autopilot mantêm a disponibilidade do servidor da API Kubernetes. Em clusters zonais, que têm um único nó de plano de controle, as reiniciações de VM tornam o plano de controle temporariamente indisponível. Para os nós, as reiniciações de VM acionam a reprogramação do pod, o que pode interromper temporariamente as cargas de trabalho existentes. É possível definir a tolerância à interrupção da carga de trabalho usando o orçamento de interrupção de pods (PDB, na sigla em inglês).

Escopo Plano de controle Nós
Upgrade secundário automático Upgrade automático de patch Upgrade secundário automático Upgrade automático de patch
Nenhum upgrade (padrão) Não permitido Não permitido Não permitido Não permitido
Nenhuma atualização secundária Não permitido Permitido Não permitido Permitido
Nenhum upgrade secundário ou de nós Não permitido Permitido Não permitido Não permitido

Para definições sobre versões secundárias e de patch, consulte Esquema de controle de versão.

Várias exclusões

É possível definir várias exclusões em um cluster. Essas exclusões podem ter escopos diferentes e intervalos de tempo sobrepostos. O caso de uso de fim de ano é um exemplo de exclusões sobrepostas, em que os escopos "Sem upgrades" e "Sem upgrades secundários" estão em uso.

Quando houver sobreposição de exclusões, se alguma exclusão ativa (ou seja, o horário atual estiver dentro do período de exclusão) bloquear um upgrade, ele será adiado.

Usando o caso de uso de férias fim de ano, um cluster tem as seguintes exclusões especificadas:

  • Sem upgrades secundários: de 30 de setembro a 15 de janeiro
  • Sem upgrades: de 19 de novembro a 4 de dezembro
  • Sem upgrades: de 15 de dezembro a 5 de janeiro

Como resultado dessas exclusões sobrepostas, os seguintes upgrades serão bloqueados no cluster:

  • Upgrade de patch no pool de nós em 25 de novembro (rejeitado pela exclusão "Sem upgrades")
  • Upgrade secundário no plano de controle em 20 de dezembro (rejeitado pela exclusão "Sem upgrades secundários" e "Sem upgrades")
  • Upgrade do patch no plano de controle em 25 de dezembro (rejeitado pela exclusão "Sem upgrades")
  • Upgrade secundário no pool de nós em 1º de janeiro (rejeitado pela exclusão "Sem upgrades secundário" e "Sem upgrades")

A manutenção a seguir seria permitida no cluster:

  • Upgrade de patch no plano de controle em 10 de novembro (permitido pela exclusão "Sem upgrades secundários")
  • Interrupção da VM devido à manutenção do GKE em 10 de dezembro (permitida pela exclusão "Sem upgrades secundários")

Expiração da exclusão

Quando uma exclusão expira, ou seja, a hora atual ultrapassou o horário de término especificado para a exclusão, essa exclusão não impedirá mais atualizações do GKE. Outras exclusões que ainda são válidas (não expiradas) continuarão impedindo as atualizações do GKE.

Quando não houver exclusões que impeçam os upgrades do cluster, ele será atualizado gradualmente para a versão padrão atual no canal de lançamento do cluster (ou o padrão estático para clusters sem canal de lançamento).

Se o cluster estiver com várias versões secundárias atrás da versão padrão atual após a expiração da exclusão, o GKE programará um pequeno upgrade por mês (upgrade do plano de controle do cluster e dos nós) até que o cluster alcance a versão padrão para o canal de lançamento. Se você quiser retornar o cluster para a versão padrão antes, execute upgrades manuais.

Limitações ao configurar exclusões de manutenção

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

  • Só é possível restringir o escopo de upgrades automáticos em uma exclusão de manutenção para clusters inscritos em um canal de lançamento. Para clusters não registrados em um canal de lançamento, só é possível criar uma exclusão de manutenção com o escopo padrão "Sem upgrades".
  • É possível adicionar no máximo três exclusões de manutenção que excluem todos os upgrades, ou seja, um escopo "sem upgrades". Essas exclusões precisam ser configuradas para permitir pelo menos 48 horas de disponibilidade de manutenção em um período de 32 dias.
  • É possível ter no máximo 20 exclusões de manutenção para cada cluster.
  • Se você não especificar um escopo na exclusão, o padrão será "nenhum upgrade".
  • É possível definir exclusões de manutenção para diferentes períodos, dependendo do escopo. Consulte a linha Comprimento da exclusão de manutenção na seção Configurar uma exclusão de manutenção para mais detalhes.
  • Não é possível configurar uma exclusão de manutenção para incluir ou exceder a data de fim de suporte da versão secundária correspondente ao registro no canal de lançamento do cluster. Veja os exemplos a seguir:
    • Um cluster está executando uma versão secundária no Canal estável, em que a programação de lançamentos do GKE declara que a data de fim do suporte padrão é 5 de junho de 2025. Defina o horário de término da exclusão de manutenção para 2025-06-05T00:00:00Z ou anterior.
    • Um cluster está executando uma versão secundária no Canal estendido, em que a programação de lançamentos do GKE declara que a data de fim do suporte estendido é 5 de abril de 2026. Defina o horário de término da exclusão de manutenção para 2026-04-0500:00:00Z ou anterior. Se você quiser mudar o canal de lançamento do cluster para outro, mude o horário de término da exclusão de manutenção se ele exceder o fim do suporte padrão. Para saber mais, consulte Mudar o cluster no Canal estendido.

Exemplos de uso

Veja alguns exemplos de casos de uso para restringir o escopo das atualizações que podem ocorrer.

Exemplo: varejista se preparando para o período de festas de fim de ano

Neste exemplo, o negócio de varejo não quer interrupções durante os períodos de maior volume de vendas, que é o período de quatro dias que abrange desde a Black Friday até a Cyber Monday e o mês de dezembro até o início do ano novo. Como preparação para a temporada de compras, o administrador do cluster configura as seguintes exclusões:

  • Sem atualizações secundárias: permitir somente atualizações de patch no plano de controle e nos nós entre 30 de setembro e 15 de janeiro.
  • Sem upgrades: congele todos os upgrades entre 19 de novembro e 4 de dezembro.
  • Sem upgrades: congele todos os upgrades entre 15 de dezembro e 5 de janeiro.

Se nenhuma outra janela de exclusão se aplicar quando a exclusão de manutenção expirar, o cluster receberá um upgrade para uma nova versão secundária do GKE, se houver uma disponível entre 30 de setembro e 6 de janeiro.

Exemplo: empresa usando uma API Beta no Kubernetes que está sendo removida

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

  • Sem upgrades secundários: congele upgrades s ecundáriospor três meses ao migrar aplicativos do cliente de apiextensions.k8s.io/v1beta1 para apiextensions.k8s.io/v1.

Exemplo: banco de dados legado da empresa não resiliente a upgrades de pool de nós

Neste exemplo, uma empresa está executando um banco de dados que não responde bem a remoções e reprogramação do pod que ocorrem durante um upgrade do pool de nós. O administrador do cluster configura a seguinte exclusão:

  • Sem upgrades secundários ou de nós: congele upgrades de nó por três meses. Quando a empresa estiver pronta para aceitar a inatividade no banco de dados, será acionada uma atualização de nó manual.

A seguir