Nesta página, explicamos como você e o Google Kubernetes Engine (GKE) gerenciam as mudanças durante o ciclo de vida de um cluster para maximizar o desempenho 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 de cluster para minimizar as interrupções nas cargas de trabalho. Leia esta página antes ou depois de aprender a realizar as tarefas básicas de gerenciamento de clusters descritas em Como gerenciar 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 do Kubernetes. Como 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 das cargas de trabalho, com o máximo de desempenho, disponibilidade e o mínimo de interrupção, é uma responsabilidade compartilhada:
- A responsabilidade do GKE é manter um ambiente de cluster confiável, disponível, seguro e de alto desempenho. Para 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 de plataforma é configurar o cluster e gerenciar as cargas de trabalho, incluindo prepará-las para lidar com interrupções. No modo Standard, você também cria e gerencia os nós de trabalho, que são agrupados em pools de nós.
Para mais informações, 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 suas cargas de trabalho. Para gerenciar o cluster, o GKE realiza 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 podem 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 aquelas que reiniciam os nós que executam as cargas de trabalho. Usando os recursos do GKE e do Kubernetes, é possível especificar quando e como você quer que a interrupção ocorra para que, quando isso acontecer, suas cargas de trabalho possam lidar com as mudanças de maneira adequada.
As seções a seguir explicam quais tipos de mudanças o GKE faz nos clusters, que tipo de interrupção elas causam e como você pode 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, refere-se à atualização da versão do Kubernetes do plano de controle (upgrades do plano de controle) ou nós (upgrades de nó), ou ambos. Ao usar clusters Standard, os upgrades de nós também podem ser chamados de upgrades de pool de nós, porque o GKE usa uma única operação para fazer upgrade de 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 no plano de controle ou no nó, incluindo a atualização das versões deles. O GKE gerencia ativamente o ambiente do cluster realizando upgrades, outros tipos de atualizações e operações de manutenção necessárias. Essas ações garantem que o cluster permaneça com bom desempenho, seguro e atualizado com os recursos e as 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 as interrupções durante esses processos.
Como planejar interrupções na atualização de nós
Alguns tipos de mudanças no cluster, principalmente nos nós, podem causar interrupções.
O GKE usa estratégias de upgrade de nós para atualizar nós, sejam eles do Autopilot ou pools de nós de clusters Standard, de uma forma otimizada para as necessidades da sua 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 as interrupções ao realizar atualizações de nós, que são importantes para manter os clusters funcionais e com bom desempenho.
Use janelas de manutenção e exclusões para escolher quando a manutenção do cluster ocorre ou não e, para clusters do Standard, escolha uma estratégia de upgrade de nó que melhor se adapte ao seu perfil de carga de trabalho e às restrições de recursos.
Para alterações manuais e automáticas 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, elas geralmente respeitam as políticas de manutenção do GKE. Algumas exceções incluem a manutenção de host para determinados tipos de nós, como aqueles com GPUs e TPUs.
Considere o seguinte se você iniciar mudanças manuais que exijam 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 alteração for urgente, aplique manualmente as alterações para aplicar a nova configuração imediatamente.
- Para outras alterações 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 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 que não sejam de versão, ele escolhe uma estratégia de upgrade de nós: upgrades súbitos, upgrades azul-verde ou azul-verde com escalonamento automático (pré-lançamento). O Autopilot sempre usa upgrades súbitos. As alterações nos pools de nós de cluster Standard normalmente usam upgrades súbitos, exceto quando você configura upgrades azul-verde ou azul-verde com escalonamento automático e faz determinados tipos de alterações. Para mais informações sobre qual estratégia está configurada para um pool de nós, consulte Inspecionar as configurações de upgrade de um pool de nós.
As alterações exigem recursos suficientes: quando o GKE aplica uma alteração usando uma estratégia de upgrade de nós, essa alteração requer uma determinada 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 mais informações, consulte Garantir recursos para upgrades de nós.
Para 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 ao se preparar para mudanças disruptivas
Para maximizar a disponibilidade das cargas de trabalho em execução em um cluster do GKE, recomendamos que você siga 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 Standard regional em vez de um cluster Standard zonal. Para mais informações, 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 possibilita implementar as práticas recomendadas:
- Canais de lançamento: escolha um canal de lançamento para receber versões de cluster com o equilíbrio escolhido de disponibilidade e estabilidade de recursos.
- Janelas de manutenção: especifique uma janela de tempo recorrente em que determinados tipos de manutenção de cluster do GKE, como upgrades, podem ocorrer.
- Exclusões de manutenção: evite que a manutenção do cluster ocorra por um período específico.
- Orçamentos de interrupção de cluster: personalize o intervalo de tempo mínimo entre tipos específicos de upgrades de cluster, incluindo upgrades de patch ou secundários.
- Estratégias de upgrade de nós: se você estiver usando um pool de nós padrão, escolha como os nós serão atualizados (upgrades súbitos, azul-verde ou azul-verde com escalonamento automático (pré-lançamento)) para minimizar as interrupções nas cargas de trabalho. Além disso, escolha quantos pools de nós o GKE faz upgrade automaticamente ao mesmo tempo em um cluster.
- Sequenciamento de lançamento: qualifique os upgrades em um ambiente de pré-produção antes que o GKE faça upgrade dos clusters de produção.
- Upgrades manuais: faça upgrade manual do cluster e realize ações como cancelar, retomar, reverter e concluir upgrades automáticos ou manuais em andamento.
Gerenciar e monitorar o cluster
Para gerenciar possíveis interrupções nos clusters, realize continuamente as seguintes tarefas:
- Monitore o cluster com o pacote de observabilidade do GKE.
- Siga as notas de lançamento do GKE para ver os anúncios.
- Confira as notificações do cluster, como quando os upgrades começam ou são concluídos, quando novas versões estão disponíveis, boletins de segurança e datas de fim do suporte.
- Tenha visibilidade dos upgrades de cluster para entender o estado dos upgrades dos seus clusters.
- Confira a programação de lançamento do GKE para uma estimativa do melhor caso de quando as versões secundárias estarão disponíveis para upgrades e chegarão ao fim do suporte.
- Use orientações prescritivas que identificam possíveis oportunidades de otimização e explicam como otimizar o uso do cluster, incluindo orientações para descontinuações de recursos e APIs.
Preparar as cargas de trabalho
Gerencie as interrupções tornando as cargas de trabalho o mais resilientes possível:
- Execute réplicas das cargas de trabalho para garantir a redundância e evitar um ponto único de falha.
- Especifique um orçamento de interrupção para seu aplicativo usando um orçamento de interrupção de pods.
- Defina um período de carência de encerramento com a duração certa para que a carga de trabalho seja encerrada normalmente.
- Se a carga de trabalho estiver usando GPUs ou TPUs, siga as instruções para gerenciar interrupções de nós do GKE para GPUs e TPUs.
- Para aplicativos com estado, que geralmente precisam de tempo para interromper a E/S de maneira limpa e se desconectar do armazenamento, siga as etapas em Garantir que as cargas de trabalho com estado estejam prontas para interrupções.
Para uma discussão geral sobre esses tópicos, consulte a seção Gerenciar interrupções da postagem do blog Práticas recomendadas do GKE: operações do dia 2 para 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.
| Mudar | Iniciadas de modo manual ou automático | 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 extremamente raros de correções de emergência, conforme necessário. Os upgrades manuais não são bloqueados por políticas de manutenção. |
Upgrades de patch, com frequência semanal, dependendo do canal de lançamento. Upgrades secundários aproximadamente a cada quatro meses. Para clusters do canal estendido, os upgrades secundários só ocorrem quando a versão secundária se aproxima do fim do suporte. |
Plano de controle |
Para clusters do Autopilot e Standard regionais, o plano de controle permanece disponível. Para clusters zonais do Standard, vários minutos em que não é possível se comunicar com o plano de controle, o que significa que 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 extremamente raros de correções de emergência, conforme necessário. Os upgrades manuais não são bloqueados por políticas de manutenção. |
Geralmente, é 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 upgrade manual dos pools de nós do cluster. |
Todos os nós para clusters do Autopilot ou um ou mais pools de nós de cluster Standard. |
Os nós precisam ser encerrados para serem recriados, e os pods precisam ser substituídos. O GKE usa upgrades súbitos para o Autopilot ou a estratégia de upgrade de nós configurada (súbito, azul-verde ou azul-verde com escalonamento automático (pré-lançamento)) para clusters do Standard. |
Mudanças manuais que recriam os nós usando uma estratégia de upgrade de nós 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, mudanças manuais que respeitam as políticas de manutenção do GKE.
| Mudar | Iniciadas de modo manual ou automático | Respeita as políticas de manutenção | Frequência | Tipo de interrupção | Nível de interrupção |
|---|---|---|---|---|---|
| Como desativar a porta somente leitura do kubelet | Iniciada manualmente | Não respeita as políticas de manutenção, faz mudanças imediatamente. | Uma vez por mudança desse tipo. | Todos os nós em um cluster do Autopilot Todos os nós em um pool de nós de cluster Standard. |
Os nós precisam ser encerrados para serem recriados. Os pods precisam ser substituídos. O GKE usa imediatamente upgrades súbitos para recriar os nós, independentemente de qualquer política de manutenção ativa. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| Como fazer a rotação das credenciais do cluster | Automática se as credenciais do cluster expirarem em até 30 dias. Também pode ser iniciada manualmente. | Respeita as políticas de manutenção. No entanto, o GKE pode substituir as políticas de manutenção em até 30 dias após a expiração da credencial. Em até 30 dias, o GKE ignora a disponibilidade de manutenção para a primeira etapa, que é iniciar a rotação. 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 do ciclo de vida da credencial do cluster para início automático. É possível invocar manualmente operações para etapas específicas no processo de rotação. | Em algumas etapas, o plano de controle. Para outras etapas, todos os nós dos clusters do Autopilot, todos os nós em cada pool de nós do cluster Standard. |
Quando você inicia a rotação e conclui a rotação, o nível de interrupção é o seguinte:
Quando os nós são recriados, o nível de interrupção é o seguinte:
|
| 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 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. | Em algumas etapas, o plano de controle. Para outras etapas, todos os nós dos clusters do Autopilot, todos os nós em cada pool de nós do cluster Standard. |
Quando você inicia a rotação e conclui a rotação, o nível de interrupção é o seguinte:
Quando os nós são recriados, o nível de interrupção é o seguinte:
|
| Como configurar nós protegidos | Iniciada manualmente |
A recriação do plano de controle não respeita as políticas de manutenção e 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:
Quando os nós são recriados, o nível de interrupção é o seguinte:
|
| 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 para clusters do Autopilot, todos os nós em cada pool de nós do cluster Standard. |
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. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| 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 para clusters do Autopilot, todos os nós em cada pool de nós do cluster Standard. |
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. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| 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 Standard que está sendo atualizado 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. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| 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 ativado no nível do pool de nós, todos os nós no pool de nós do cluster Standard. Se ativada no nível do cluster, os nós de qualquer pool de nós do cluster padrão em que você não tenha ativado ou desativado individualmente a configuração para o pool de nós. |
O GKE usa upgrades súbitos para recriar os nós de um pool de nós. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
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.
| Mudar | Iniciadas de modo manual ou automático | 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 do Autopilot e Standard regionais. O redimensionamento do plano de controle é pouco frequente, mas aumenta em frequência com eventos de escalonamento de cluster e também não tem impacto para clusters do Autopilot e clusters regionais do Standard. |
Plano de controle |
Para clusters do Autopilot e Standard regionais, o plano de controle permanece disponível. Para clusters zonais do Standard, vários minutos em que não é possível se comunicar com o plano de controle, o que significa que 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 saber 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 mais interrupções. Para mais informações, consulte Outras manutenções do Cloud de Confiance by S3NS . |
| Reparo automático de nós | Automático | Não respeita as políticas de manutenção | A frequência de reparo automático de nós é aleatória. |
Um nó | O nó é reiniciado, então todos os pods em execução nele 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 spot, quando o Compute Engine precisa dos recursos em outro lugar. |
Um nó | Confira detalhes sobre o encerramento e o encerramento completo das VMs spot e o encerramento e o encerramento completo das VMs preemptivas. |
| Manutenção do banco de dados de estado do cluster baseado no Spanner | Automático | Não respeita as políticas de manutenção | Os eventos são aleatórios e não afetam os clusters ou as cargas de trabalho. | Nenhuma. O banco de dados baseado no Spanner é executado separadamente do plano de controle do cluster e dos nós na infraestrutura do Google. | Nenhuma. O banco de dados baseado no Spanner é replicado para todos os tipos de clusters e permanece disponível durante a manutenção. |
Mudanças manuais que recriam os nós usando uma estratégia de upgrade de nós 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. Essa lista inclui mudanças de quando o GKE usa upgrades de aumento e quando o GKE usa upgrades azul-verde que não estão incluídas na outra seção porque não respeitam as políticas de manutenção.
| Mudar | Iniciadas de modo manual ou automático | Respeita as políticas de manutenção | Frequência | Tipo de interrupção | Nível de interrupção |
|---|---|---|---|---|---|
| Mudanças na coleta de registros do plano de controle | Iniciada manualmente | Não respeita as políticas de manutenção, faz as mudanças imediatamente. | Uma vez por mudança desse tipo | O plano de controle é atualizado. | Quando o plano de controle é recriado, o nível de interrupção é o seguinte:
|
| Atualização do rótulo do pool de nós | Iniciada manualmente | Não respeita as políticas de manutenção, 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 imediatamente upgrades de aumento para recriar o pool de nós quando você atualiza os rótulos de nós em um pool de nós atual, independentemente de qualquer política de manutenção ativa. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| Escalonar verticalmente os nós alterando os atributos da máquina do nó | Iniciada manualmente | Não respeita as políticas de manutenção, 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 imediatamente upgrades súbitos para recriar os nós em um pool de nós atual, independentemente de qualquer política de manutenção ativa. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| Mudanças no tipo de imagem | Iniciada manualmente | Não respeita as políticas de manutenção, 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úbito, azul-verde ou azul-verde com escalonamento automático (pré-lançamento)) para clusters Standard. |
| 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, 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úbito, azul-verde ou azul-verde com escalonamento automático (pré-lançamento)) para clusters Standard. |
| 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 ativado no nível do pool de nós, todos os nós no pool de nós do cluster Standard. Se ativada no nível do cluster, os nós de qualquer pool de nós do cluster padrão em que você não tenha ativado ou desativado individualmente a configuração para o pool de nós. |
O GKE usa upgrades súbitos para recriar os nós de um pool de nós. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| Atualizações de configuração de desempenho da rede | Iniciada manualmente | Não respeita as políticas de manutenção, 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 imediatamente upgrades súbitos para recriar os nós em um pool de nós atual, independentemente de qualquer política de manutenção ativa. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| Ativar a gVNIC | Iniciada manualmente | Não respeita as políticas de manutenção, 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 imediatamente upgrades súbitos para recriar os nós em um pool de nós atual, independentemente de qualquer política de manutenção ativa. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| Alterações na configuração do sistema de nós (usando a estratégia de upgrade padrão) | Iniciada manualmente | Não respeita as políticas de manutenção, 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 imediatamente upgrades súbitos para recriar os nós em um pool de nós atual, independentemente de qualquer política de manutenção ativa. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
| Nós confidenciais | Iniciada manualmente | Não respeita as políticas de manutenção, 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 imediatamente upgrades súbitos para recriar os nós em um pool de nós atual, independentemente de qualquer política de manutenção ativa. O GKE usa upgrades súbitos, independentemente de uma estratégia de upgrade de nó diferente, como upgrades azul-verde, estar configurada. |
Mudanças que não exigem a recriação dos nós
Consulte a tabela a seguir para entender quais alterações na configuração do nó não exigem a recriação dos nós. Essas mudanças não são disruptivas, mas ainda é possível que ocorram interrupções se a configuração atualizada do nó afetar sua carga de trabalho.
| Mudar | Iniciadas de modo manual ou automático | 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, 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
- Visão geral do GKE
- Arquitetura de cluster do GKE
- Responsabilidade compartilhada do GKE
- Controle de versão e suporte do GKE
- Contrato de nível de serviço do GKE
- Upgrades de cluster do GKE