Janelas e exclusões de manutenção

Nesta página, você lerá sobre janelas de manutenção e exclusões de manutenção. Com elas, é possível controlar o momento em que a manutenção do cluster, como os upgrades automáticos, pode ou não ocorrer 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.

Visão geral

As janelas e exclusões de manutenção permitem o controle detalhado sobre o momento em que a manutenção automática pode ocorrer nos clusters.

Uma janela de manutenção é aquela 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 é proibida.

As janelas e exclusões de manutenção podem ser configuradas de forma separada e independente. É possível configurar várias exclusões de manutenção.

Exemplos de manutenção automática

O Google realiza tarefas de manutenção nos clusters conforme necessário ou quando você faz uma alteração de configuração que recria nós ou redes no cluster. Por exemplo:

Clusters zonais não podem ser modificados durante alterações de configuração do plano de controle e manutenção de clusters. Isso inclui a implantação de cargas de trabalho.

Cada um dos outros tipos de alterações listadas acima pode causar interrupções temporárias enquanto as cargas de trabalho são migradas para os nós atualizados.

Advertências

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. Antes de ativar janelas e exclusões de manutenção, entenda as advertências a seguir.

Outras manutenções do Google Cloud

Clusters e cargas de trabalho do GKE também podem ser afetados pela manutenção automática em outros serviços dependentes, como o Compute Engine. As janelas e exclusões de manutenção do GKE não impedem a manutenção automática de outros serviços do Google ou serviços que instalam aplicativos no cluster, como o Google Cloud Deploy.

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. O reparo de planos de controle não pode ser desativado.

Os nós também têm a funcionalidade de reparo automático, mas pode ser desativada.

Janelas de manutenção e recriação de nós

Ao ativar ou modificar recursos ou opções, como os que afetam a rede entre os planos de controle e os nós, os nós são recriados para aplicar a nova configuração. Veja a seguir alguns exemplos de atributos que fazem com que nós sejam recriados:

Se você usar janelas de manutenção ou exclusões e ativar ou modificar um recurso ou uma opção que exija a recriação de nós, a nova configuração será aplicada aos nós somente quando a manutenção do nó for permitida. Se você preferir não esperar, aplique manualmente as alterações aos nós chamando o comando gcloud container clusters upgrade e transmitindo a sinalização --cluster-version com a mesma versão do GKE que o pool de nós já está em execução. Use a ferramenta de linha de comando gcloud para essa alternativa.

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.

Restrições

As janelas de manutenção têm as seguintes restrições:

Uma janela de manutenção por cluster

Só é possível configurar uma única janela de manutenção por cluster. A configuração de uma nova janela de manutenção substitui a anterior.

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

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 ferramenta 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. Os horários são sempre armazenados em UTC.

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 ferramenta 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. Para eventos conhecidos de alto impacto, recomenda-se corresponder todas as restrições de alteração internas com uma exclusão de manutenção que comece uma semana antes do evento e com a duração do evento.

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:

  • Evite manutenção: evite qualquer alteração no seu cluster temporariamente durante um período específico.
  • Manter 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.
  • Evitar a interrupção do pool de nós: você quer evitar temporariamente a remoção e a reprogramação das cargas de trabalho.

A tabela a seguir lista o escopo das atualizações automáticas que podem ser restritas em uma exclusão de manutenção. A tabela também indica o tipo de upgrade que ocorre (secundário e/ou patch). Quando ocorrem upgrades, as VMs do plano de controle e/ou do pool de nós são reiniciadas. Para planos de controle, as reinicializações da VM podem reduzir temporariamente a disponibilidade do servidor da API Kubernetes, especialmente na topologia de cluster zonal com um único plano de controle. Para os nós, as reinicializações da VM acionam a reprogramação do pod, o que pode interromper temporariamente as cargas de trabalho.

Escopo Plano de controle Pools de nós
Upgrade secundário Upgrade de patch Interrupção da VM
devido à manutenção do
GKE
Upgrade secundário Upgrade de patch Interrupção da VM
devido à manutenção do
GKE
Nenhum upgrade (padrão) Não Não Não Não Não Não
Nenhuma atualização secundária Não Sim Sim Não Sim Sim
Nenhum upgrade secundário ou de nós Não Sim Sim Não Não Não

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.

Como um exemplo de exclusões sobrepostas, um cluster tem as seguintes exclusões especificadas:

  • Sem upgrades: 1º. de janeiro a 7 de janeiro
  • Não há upgrades secundários: de 1º. de janeiro a 7 de janeiro
  • Não há upgrades secundários ou de nó: de 1º. de janeiro a 7 de janeiro

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

  • Upgrade de patch no plano de controle em 1º. de janeiro (rejeitado pela exclusão "Sem upgrades")
  • Upgrade secundário no plano de controle em 1º. de janeiro (rejeitado por todas as exclusões)
  • Upgrade de patch para o pool de nós em 1º. de janeiro (rejeitado por "Sem upgrades" e exclusões "Sem upgrades secundários ou de nó")
  • Upgrade secundário no pool de nós em 1º. de janeiro (rejeitado por todas as exclusões)

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

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

  • É possível restringir o escopo de upgrades automáticos em uma exclusão de manutenção somente para clusters inscritos em um canal de lançamento.
  • É possível adicionar no máximo três exclusões de manutenção que excluem todos os upgrades. Ou seja, um escopo de "sem upgrades".
  • É possível ter até 20 exclusões de manutenção no total.
  • Se você não especificar um escopo na sua exclusão, o escopo padrão será "sem upgrades".
  • A duração de uma exclusão de manutenção tem restrições com base no escopo de exclusão especificado:

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.

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