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.

Informações gerais

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 substituir políticas de manutenção para 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 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 ou exclusões de manutenção e ativar ou modificar um recurso ou uma opção que exija a recriação dos nós, como a rotação de credenciais do cluster, a nova configuração será aplicada. aos nós somente quando a manutenção do nó é 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 Google Cloud CLI para essa solução 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 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. 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 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ó: evita a interrupção do pool de nós: você quer evitar temporariamente qualquer remoção e reprogramação das cargas de trabalho devido a upgrades de nó.

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. É possível definir a tolerância à interrupção da carga de trabalho usando o orçamento de interrupção do pod (PDB, na sigla em inglês).

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.

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

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 Standad não inscritos 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 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:
    • Sem upgrades: não pode exceder 30 dias.
    • Sem upgrades menores: não pode terminar mais de 180 dias após a data de criação da exclusão.
    • Nenhum upgrade secundário ou de nó: não pode terminar mais de 180 dias após a data de criação de exclusão.
  • Não é possível configurar uma exclusão de manutenção para incluir ou exceder a data de fim da vida útil da versão secundária. Por exemplo, se um cluster estiver executando uma versão secundária, em que a programação de lançamento do GKE declara que a data de fim da vida útil é 5 de junho de 2023, você precisa definir o horário de término da manutenção. exclusão para 2023-06-05T00:00:00Z ou anterior.

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