Gerenciar mudanças no ciclo de vida do cluster para minimizar interrupções


Nesta página, explicamos como você e o Google Kubernetes Engine (GKE) gerenciam mudanças durante o ciclo de vida de um cluster para maximizar a performance e a disponibilidade, minimizando a interrupção da carga de trabalho.

Esta página é destinada a administradores de plataformas que querem planejar e otimizar o ambiente do cluster para minimizar a interrupção das cargas de trabalho. Leia esta página antes ou depois de aprender a realizar as tarefas básicas de gerenciamento de clusters descritas em Gerenciamento de clusters e Visão geral da administração de clusters.

Uma plataforma gerenciada e responsabilidade compartilhada

O GKE é uma implementação gerenciada pelo Google da plataforma de orquestração de contêineres de código aberto Kubernetes. Conforme mencionado em Como o GKE funciona, um cluster do GKE consiste em um plano de controle, que inclui nós de gerenciamento que executam componentes do sistema, e nós de trabalho, em que você implanta cargas de trabalho.

Criar um ambiente de cluster ideal para a execução de cargas de trabalho, com o máximo de desempenho, disponibilidade e interrupção mínima, é uma responsabilidade compartilhada:

  • A responsabilidade do GKE é manter um ambiente de cluster confiável, disponível, seguro e com bom desempenho. Para fazer isso, o GKE gerencia o plano de controle, os componentes do sistema e, no modo Autopilot, os nós de trabalho.
  • Sua responsabilidade como administrador da plataforma é configurar o cluster e gerenciar as cargas de trabalho, incluindo a preparação para lidar com interrupções. No modo padrão, você também cria e gerencia os nós de trabalho, que são agrupados em pools de nós.

Para saber mais, consulte Responsabilidade compartilhada do GKE.

Como o GKE gerencia mudanças durante o ciclo de vida de um cluster

Como uma implementação do Kubernetes, um cluster do GKE é uma rede de processos e sistemas que atuam juntos para manter o ambiente ideal para executar as cargas de trabalho. Para gerenciar o cluster, o GKE executa tarefas de manutenção, faz alterações, inicia operações, atualiza componentes e faz upgrade da versão do plano de controle e dos nós.

A maior parte da execução diária do aplicativo ocorre silenciosamente em segundo plano, mantendo as cargas de trabalho em execução sem interrupções. No entanto, algumas mudanças críticas precisam ser concluídas de maneiras que possam interromper temporariamente suas cargas de trabalho, conforme descrito na próxima seção.

Algumas mudanças no cluster podem interromper as cargas de trabalho

Embora o GKE se esforce para manter as cargas de trabalho em execução sem problemas, alguns tipos essenciais de mudanças podem exigir interrupções temporárias nas cargas de trabalho, principalmente mudanças que reiniciam os nós que executam as cargas de trabalho. Usando os recursos do GKE e do Kubernetes, você pode especificar quando e como quer que a interrupção ocorra. Assim, quando ela acontecer, suas cargas de trabalho poderão processar as mudanças com facilidade.

As seções a seguir explicam os tipos de mudanças que o GKE faz nos clusters, o tipo de interrupção que elas causam e como se preparar.

Upgrades e atualizações com o gerenciamento do ciclo de vida do cluster do GKE

No GKE, os upgrades e as atualizações de cluster têm significados relacionados.

No GKE, o termo upgrades de cluster, ou apenas upgrades, se refere à atualização da versão do Kubernetes do plano de controle (upgrades do plano de controle) ou dos nós (upgrades de nó), ou a ambos. Ao usar clusters padrão, os upgrades de nó também podem ser chamados de upgrades de pool de nós, porque o GKE usa uma única operação para atualizar um pool de nós.

O termo atualizações de cluster, ou apenas atualizações, é um termo mais geral que se refere a qualquer tipo de mudança de plano de controle ou de nó, incluindo a atualização das versões. O GKE gerencia ativamente seu ambiente de cluster fazendo upgrades, outros tipos de atualizações e operações de manutenção necessárias. Essas ações garantem que o cluster continue velocidade, segurança e atualizado com os recursos e correções de bugs mais recentes. O GKE usa ferramentas como estratégias de upgrade de nós e políticas de manutenção para minimizar a interrupção durante esses processos.

Planejar interrupções na atualização de nós

Alguns tipos de mudanças no cluster, principalmente alterações em nós, podem causar interrupções.

O GKE usa estratégias de upgrade de nós para atualizar nós, tanto do Autopilot quanto de pools de nós de cluster padrão, de uma maneira otimizada para as necessidades da carga de trabalho. Essas estratégias se aplicam a upgrades de versão e também a alguns outros tipos de mudanças de nó. As estratégias permitem que o GKE minimize a interrupção ao executar atualizações de nó, que são importantes para manter os clusters funcionais e com bom desempenho.

Prática recomendada:

Use janelas de manutenção e exclusões para escolher quando algumas manutenções de cluster vão ocorrer e quando não vão ocorrer. Para clusters padrão, escolha uma estratégia de upgrade de nó que melhor se adapte ao seu perfil de carga de trabalho e às restrições de recurso.

Para mudanças manuais e iniciadas automaticamente nos nós, o GKE faz alterações com as seguintes características gerais:

  • As mudanças geralmente respeitam as políticas de manutenção: quando o GKE faz mudanças nos nós, essas mudanças geralmente respeitam as políticas de manutenção do GKE. Considere o seguinte se você iniciar mudanças manuais que exigem a recriação de todos os nós em um pool de nós:
    • Para algumas mudanças, o GKE respeita as políticas de manutenção e não aplica a mudança enviada até que haja disponibilidade de manutenção. Se o GKE estiver aguardando a disponibilidade de manutenção e a mudança for urgente, você poderá aplicar manualmente as mudanças para aplicar a nova configuração imediatamente.
    • Para outras mudanças manuais, incluindo upgrades manuais, o GKE não respeita as políticas de manutenção. Para essas mudanças manuais, verifique se as cargas de trabalho estão preparadas para a interrupção imediata.
  • As mudanças geralmente usam estratégias de upgrade de nós: quando o GKE aplica a maioria das mudanças automáticas ou iniciadas manualmente aos nós, incluindo atualizações de nós diferentes de upgrades de versão, o GKE escolhe uma estratégia de upgrade de nós: upgrades súbitos ou upgrades azuis/verdes. O Autopilot sempre usa upgrades súbitos. As mudanças nos pools de nós de cluster padrão geralmente usam upgrades súbitos, exceto quando você configurou upgrades azuis/verdes e faz determinados tipos de mudanças.
  • As mudanças exigem recursos suficientes: quando o GKE aplica uma mudança usando uma estratégia de upgrade de nó, essa mudança exige uma certa quantidade de recursos, dependendo da estratégia e da configuração. O projeto do cluster precisa ter cota de recursos, disponibilidade de recursos e capacidade de reserva suficientes (para pools de nós com afinidade de reserva específica). Para saber mais, consulte Garantir recursos para upgrades de nó.

Para conferir uma lista detalhada de mudanças específicas e as características delas, consulte Tipos de mudanças em um cluster do GKE nesta página.

Maximizar a disponibilidade da carga de trabalho se preparando para mudanças disruptivas

Para maximizar a disponibilidade dos seus workloads em um cluster do GKE, recomendamos que você realize as ações descritas nas seções a seguir:

Escolher a disponibilidade do cluster

Se a disponibilidade do plano de controle for uma prioridade, escolha um cluster do Autopilot ou um cluster padrão regional em vez de um cluster padrão zonal. Para saber mais, consulte Sobre as opções de configuração de clusters.

Controlar upgrades usando as ferramentas do GKE

Use as ferramentas a seguir para controlar quando e como o GKE faz upgrade do cluster, o que permite implementar as melhores práticas:

Gerenciar e monitorar o cluster

Para gerenciar possíveis interrupções nos clusters, execute continuamente as seguintes tarefas:

Preparar suas cargas de trabalho

Gerencie interrupções tornando as cargas de trabalho o mais resilientes possível:

Para uma discussão geral sobre esses tópicos, consulte a seção Gerenciar a interrupção da postagem do blog Práticas recomendadas do GKE: operações do Day 2 para a continuidade dos negócios.

Tipos de mudanças em um cluster do GKE

As tabelas a seguir mostram os tipos mais comuns de mudanças importantes em um cluster, incluindo características dessas mudanças, como frequência e nível de interrupção.

Tipos de upgrade

Consulte a tabela a seguir para entender como os upgrades podem interromper um ambiente de cluster.

Alterar Iniciada automaticamente ou manualmente Respeita as políticas de manutenção Frequência Tipo de interrupção Nível de interrupção
Upgrade do plano de controle Automático ou manual

Os upgrades automáticos respeitam as políticas de manutenção até o fim do suporte, exceto em casos de correção de emergência extremamente raros, conforme necessário.

Os upgrades manuais não são bloqueados pelas políticas de manutenção.

Atualizações de patch, a cada semana, dependendo do canal de lançamento.

Atualizações menores aproximadamente a cada quatro meses.

Para clusters do canal estendido, os upgrades secundários só são feitos quando a versão secundária se aproxima do fim do suporte.

Plano de controle

Para clusters padrão regionais e do Autopilot, o plano de controle continua disponível.

Para clusters padrão por zona, vários minutos em que não é possível se comunicar com o plano de controle, ou seja, não é possível configurar o cluster, os nós e as cargas de trabalho durante esse período.

Upgrade de nó Automático ou manual

Os upgrades automáticos respeitam as políticas de manutenção até o fim do suporte, exceto em casos de correção de emergência extremamente raros, conforme necessário.

Os upgrades manuais não são bloqueados pelas políticas de manutenção.

Normalmente, o mesmo que os upgrades do plano de controle.

Se o cluster não estiver inscrito em um canal de lançamento e você desativar os upgrades automáticos de nós, será sua responsabilidade fazer o upgrade manual dos pools de nós do cluster.

Todos os nós dos clusters do Autopilot ou um ou mais pools de nós de cluster padrão.

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos no Autopilot ou a estratégia de upgrade de nó configurada (súbito ou azul-verde) nos clusters padrão.

Mudanças manuais que recriam os nós usando uma estratégia de upgrade e respeitando as políticas de manutenção

Consulte a tabela a seguir para entender como essas mudanças manuais podem interromper um ambiente de cluster. Essa lista inclui, entre outras, mudanças manuais que respeitam as políticas de manutenção do GKE.

Alterar Iniciada automaticamente ou manualmente Respeita as políticas de manutenção Frequência Tipo de interrupção Nível de interrupção
Como fazer a rotação das credenciais do cluster Automático se as credenciais do cluster estiverem expirando em 30 dias, mas também pode ser iniciado manualmente. Respeita as políticas de manutenção, mas o GKE pode substituir as políticas de manutenção em até 30 dias após a expiração da credencial. Além disso, se você acionar manualmente operações específicas após a primeira etapa, essa operação não vai respeitar as políticas de manutenção. Uma vez por mudança manual desse tipo ou depende da duração da credencial do cluster para a ativação automática. É possível invocar manualmente operações para etapas específicas no processo de rotação. Para algumas etapas, o plano de controle. Para outras etapas, todos os nós dos clusters do Autopilot e todos os nós em cada pool de nós de cluster padrão.

Quando você inicia e conclui a rotação, o nível de interrupção é o seguinte:

  • Para clusters padrão regionais e do Autopilot, o plano de controle continua disponível.
  • Para clusters padrão zonais, as duas operações causam um breve tempo de inatividade, ou seja, vários minutos em que você não pode se comunicar com o plano de controle para realizar operações como configurar o cluster, os nós e as cargas de trabalho.

Quando os nós são recriados, o nível de interrupção é o seguinte:

  • Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.
  • O GKE usa upgrades súbitos para recriar os nós.
Como fazer a rotação do endereço IP do plano de controle Iniciada manualmente Respeita as políticas de manutenção. No entanto, se você acionar manualmente operações específicas após a primeira etapa, essa operação não vai respeitar as políticas de manutenção. Uma vez por mudança manual desse tipo. É possível invocar manualmente operações para etapas específicas no processo de rotação. Para algumas etapas, o plano de controle. Para outras etapas, todos os nós dos clusters do Autopilot e todos os nós em cada pool de nós de cluster padrão.

Quando você inicia e conclui a rotação, o nível de interrupção é o seguinte:

  • Para clusters padrão regionais e do Autopilot, o plano de controle continua disponível.
  • Para clusters padrão zonais, as duas operações causam um breve tempo de inatividade, ou seja, vários minutos em que você não pode se comunicar com o plano de controle para realizar operações como configurar o cluster, os nós e as cargas de trabalho.

Quando os nós são recriados, o nível de interrupção é o seguinte:

  • Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.
  • O GKE usa upgrades súbitos para recriar os nós.
Como configurar nós protegidos Iniciada manualmente

A recriação do plano de controle não respeita as políticas de manutenção, mas faz as mudanças imediatamente.

A recriação dos nós respeita as políticas de manutenção.

Uma vez por mudança desse tipo

O plano de controle é atualizado.

Depois que o plano de controle for atualizado, todos os nós em cada pool de nós do cluster padrão precisarão ser recriados.

Quando o plano de controle é recriado, o nível de interrupção é o seguinte:

  • Para clusters padrão regionais e do Autopilot, o plano de controle continua disponível.
  • Para clusters padrão zonais, as duas operações causam um breve período de inatividade, ou seja, vários minutos em que você não pode se comunicar com o plano de controle para realizar operações como configurar o cluster, os nós e as cargas de trabalho.

Quando os nós são recriados, o nível de interrupção é o seguinte:

  • Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.
  • O GKE usa upgrades súbitos para recriar os nós.
Como configurar políticas de rede Iniciada manualmente Respeita as políticas de manutenção Uma vez por mudança desse tipo Todos os nós dos clusters do Autopilot e todos os nós em cada pool de nós de cluster padrão.

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos para recriar os nós.

Como configurar a visibilidade intranós Iniciada manualmente Respeita as políticas de manutenção Uma vez por mudança desse tipo Todos os nós dos clusters do Autopilot e todos os nós em cada pool de nós de cluster padrão.

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos para recriar os nós.

Como configurar o NodeLocal DNSCache Iniciada manualmente Respeita as políticas de manutenção Uma vez por mudança desse tipo Todos os nós no pool de nós do cluster padrão que estão sendo atualizados precisam ser atualizados.

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos para recriar os nós.

Como ativar o streaming de imagens Iniciada manualmente

Ao atualizar no nível do cluster, respeita as políticas de manutenção.

Ao atualizar pools de nós individuais, não respeita as políticas de manutenção.

Uma vez por mudança desse tipo

Se alternado no nível do pool de nós, todos os nós no pool de nós do cluster padrão.

Se alternado no nível do cluster, os nós de qualquer pool de nós de cluster padrão em que você não ativou ou desativou individualmente a configuração do pool de nós.

O GKE usa upgrades súbitos para recriar os nós de um pool de nós.

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

Consulte a tabela a seguir para entender como a manutenção automática que não respeita as políticas de manutenção pode interromper um ambiente de cluster.

Alterar Iniciada automaticamente ou manualmente Respeita as políticas de manutenção Frequência Tipo de interrupção Nível de interrupção
Reparo ou redimensionamento do plano de controle Automático Não respeita as políticas de manutenção

A frequência de reparo do plano de controle é aleatória, mas não tem impacto nos clusters regionais do Autopilot e do Standard.

O redimensionamento do plano de controle é raro, mas aumenta de frequência com eventos de escalonamento de cluster e também não tem impacto nos clusters regionais do Autopilot e do Standard.

Plano de controle

Para clusters padrão regionais e do Autopilot, o plano de controle continua disponível.

Para clusters padrão por zona, vários minutos em que não é possível se comunicar com o plano de controle, ou seja, não é possível configurar o cluster, os nós e as cargas de trabalho durante esse período.

Evento de manutenção do host Automático Não respeita as políticas de manutenção Consulte Eventos de manutenção para conferir a frequência aproximada. Um nó

Para a maioria dos tipos de nós, o efeito é mínimo.

Alguns nós, incluindo aqueles com GPUs ou TPUs, podem sofrer uma interrupção maior. Para saber mais, consulte Outras manutenções do Google Cloud .

Reparo automático de nós Automático Não respeita as políticas de manutenção

A frequência do reparo automático de nós é aleatória.

Um nó O nó é reiniciado, então todos os pods em execução no nó são interrompidos.
Recuperar VMs spot e VMs preemptivas Automático Não respeita as políticas de manutenção

Para VMs preemptivas, pelo menos uma vez a cada 24 horas.

Para VMs do Spot, quando o Compute Engine precisa dos recursos em outro lugar.

Um nó Confira detalhes sobre o encerramento e o encerramento otimizado das VMs do Spot e o encerramento e o encerramento otimizado das VMs preemptivas.

Mudanças manuais que recriam os nós usando uma estratégia de upgrade sem respeitar as políticas de manutenção

Consulte a tabela a seguir para entender como essas mudanças manuais podem interromper um ambiente de cluster. Esta lista inclui mudanças de quando o GKE usa upgrades súbitos e quando o GKE usa upgrades azuis/verdes que não estão incluídas na outra seção, porque não respeitam as políticas de manutenção.

Alterar Iniciada automaticamente ou manualmente Respeita as políticas de manutenção Frequência Tipo de interrupção Nível de interrupção
Atualização do rótulo do pool de nós Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão O GKE usa upgrades súbitos imediatamente para recriar o pool de nós quando você atualiza os rótulos de um pool de nós atual, independentemente das políticas de manutenção ativas.
Escalonar verticalmente os nós mudando os atributos da máquina de nós Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão O GKE usa upgrades súbitos imediatamente para recriar os nós em um pool de nós atual, independentemente das políticas de manutenção ativas.
Mudanças no tipo de imagem Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa a estratégia de upgrade de nós configurada (súbita ou azul-verde) para clusters padrão.

Adicionar ou substituir pools de armazenamento em um pool de nós de cluster padrão Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa a estratégia de upgrade de nós configurada (súbita ou azul-verde) para clusters padrão.

Como ativar o streaming de imagens Iniciada manualmente

Ao atualizar no nível do cluster, respeita as políticas de manutenção.

Ao atualizar pools de nós individuais, não respeita as políticas de manutenção.

Uma vez por mudança desse tipo

Se alternado no nível do pool de nós, todos os nós no pool de nós do cluster padrão.

Se alternado no nível do cluster, os nós de qualquer pool de nós de cluster padrão em que você não ativou ou desativou individualmente a configuração do pool de nós.

O GKE usa upgrades súbitos para recriar os nós de um pool de nós.
Atualizações de configuração de desempenho da rede Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos imediatamente para recriar os nós em um pool de nós atual, independentemente das políticas de manutenção ativas.

Ativar a gVNIC Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos imediatamente para recriar os nós em um pool de nós atual, independentemente das políticas de manutenção ativas.

Mudanças na configuração do sistema de nós Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos imediatamente para recriar os nós em um pool de nós atual, independentemente das políticas de manutenção ativas.

Nós confidenciais Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós em um pool de nós de cluster padrão

Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos.

O GKE usa upgrades súbitos imediatamente para recriar os nós em um pool de nós atual, independentemente das políticas de manutenção ativas.

Mudanças que não exigem a recriação dos nós

Consulte a tabela a seguir para entender quais mudanças na configuração do nó não exigem a recriação dos nós. Essas mudanças não são perturbadoras, mas a interrupção ainda é possível se a configuração do nó atualizado afetar sua carga de trabalho.

Alterar Iniciada automaticamente ou manualmente Respeita as políticas de manutenção Frequência Tipo de interrupção Nível de interrupção

Atualize as seguintes configurações:

Iniciada manualmente Não respeita as políticas de manutenção e faz as mudanças imediatamente. Uma vez por mudança desse tipo Todos os nós relevantes são atualizados. Os pods não precisam ser substituídos, porque a configuração do nó é atualizada sem recriar os nós.

A seguir