Esta página explica como o utilizador e o Google Kubernetes Engine (GKE) gerem as alterações durante o ciclo de vida de um cluster para maximizar o desempenho e a disponibilidade, ao mesmo tempo que minimizam a interrupção da carga de trabalho.
Esta página destina-se a administradores de plataformas que querem planear e otimizar o respetivo ambiente de cluster para minimizar a interrupção das respetivas cargas de trabalho. Pode ler esta página antes ou depois de saber como realizar as tarefas básicas de gestão de clusters descritas em Gerir clusters e Vista geral da administração de clusters.
Uma plataforma gerida e responsabilidade partilhada
O GKE é uma implementação gerida pela Google da plataforma de orquestração de contentores de código aberto Kubernetes. Conforme mencionado em Como funciona o GKE, um cluster do GKE consiste num plano de controlo, que inclui nós de gestão que executam componentes do sistema, e nós de trabalho, onde implementa cargas de trabalho.
A criação de um ambiente de cluster ideal para a execução das suas cargas de trabalho, com o máximo de desempenho, disponibilidade e interrupções mínimas, é uma responsabilidade partilhada:
- A responsabilidade do GKE é manter um ambiente de cluster fiável, disponível, seguro e com bom desempenho. Para tal, o GKE faz a gestão do plano de controlo, dos componentes do sistema e, para o modo Autopilot, dos nós de trabalho.
- É da sua responsabilidade, enquanto administrador da plataforma, configurar o cluster e gerir as cargas de trabalho, incluindo prepará-las para lidar com interrupções. Com o modo padrão, também cria e gere os nós de trabalho, que são agrupados em conjuntos de nós.
Para saber mais, consulte o artigo Responsabilidade partilhada do GKE.
Como o GKE gere as alterações 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 em conjunto para manter o ambiente ideal para executar as suas cargas de trabalho. Para gerir o cluster, o GKE executa tarefas de manutenção, faz alterações, inicia operações, atualiza componentes e atualiza a versão do painel de controlo e dos nós.
A maioria do funcionamento diário da sua aplicação ocorre silenciosamente em segundo plano, mantendo as suas cargas de trabalho em execução sem interrupções. No entanto, algumas alterações críticas têm de ser concluídas de formas que podem interromper temporariamente as suas cargas de trabalho, conforme descrito na secção seguinte.
Algumas alterações de cluster podem ser disruptivas para as cargas de trabalho
Embora o GKE se esforce por manter as suas cargas de trabalho em execução sem problemas, alguns tipos de alterações essenciais podem exigir interrupções temporárias nas suas cargas de trabalho, principalmente alterações que reiniciam os nós que executam as suas cargas de trabalho. Ao usar as funcionalidades do GKE e do Kubernetes, pode especificar quando e como quer que ocorra a interrupção, para que, quando ocorrer, as suas cargas de trabalho possam processar as alterações de forma adequada.
As secções seguintes explicam os tipos de alterações que o GKE faz aos clusters, o tipo de interrupção que causam e como se pode preparar.
Atualizações com a gestão do ciclo de vida do cluster do GKE
No GKE, as atualizações e as atualizações de clusters têm significados relacionados.
No GKE, o termo atualizações de clusters, ou apenas atualizações, refere-se à atualização da versão do Kubernetes do plano de controlo (atualizações do plano de controlo) ou dos nós (atualizações de nós), ou ambos. Quando usa clusters padrão, as atualizações de nós também podem ser denominadas atualizações de node pool porque o GKE usa uma única operação para atualizar um node pool de nós.
O termo atualizações de clusters, ou apenas atualizações, é um termo mais geral que se refere a qualquer tipo de alterações ao painel de controlo ou aos nós, incluindo a atualização das respetivas versões. O GKE gere ativamente o ambiente do cluster através da realização de atualizações, outros tipos de atualizações e operações de manutenção necessárias. Estas ações garantem que o cluster permanece com bom desempenho, seguro e atualizado com as funcionalidades mais recentes e as correções de erros. O GKE usa ferramentas como estratégias de atualização de nós e políticas de manutenção para minimizar as interrupções durante estes processos.
Planeamento de interrupções de atualizações de nós
Determinados tipos de alterações de cluster, principalmente alterações aos nós, podem causar interrupções.
O GKE usa estratégias de atualização de nós para atualizar os nós, sejam nós do Autopilot ou pools de nós do cluster Standard, de uma forma otimizada para as necessidades da sua carga de trabalho. Estas estratégias aplicam-se a atualizações de versões e também a outros tipos de alterações de nós. As estratégias permitem que o GKE minimize a interrupção durante a realização de atualizações de nós, que são importantes para manter os clusters funcionais e com bom desempenho.
Use períodos de manutenção e exclusões para escolher quando a manutenção de alguns clusters ocorre e quando não ocorre e, para clusters padrão, escolha uma estratégia de atualização de nós que se ajuste melhor ao seu perfil de carga de trabalho e restrições de recursos.
Tanto para as alterações iniciadas manualmente como automaticamente aos nós, o GKE faz alterações com as seguintes caraterísticas gerais:
- As alterações respeitam normalmente as políticas de manutenção: quando o GKE faz alterações aos nós, estas alterações respeitam
geralmente as políticas de manutenção
do GKE.
Tenha em atenção o seguinte se iniciar alterações manuais que exijam a recriação de todos os nós num node pool:
- Para algumas alterações, o GKE respeita as políticas de manutenção e não aplica a alteração que enviou até haver disponibilidade de manutenção. Se o GKE estiver à espera da disponibilidade de manutenção e a alteração for urgente, pode aplicar manualmente as alterações para aplicar a nova configuração imediatamente.
- Para outras alterações manuais, incluindo atualizações manuais, o GKE não respeita as políticas de manutenção. Para estas alterações manuais, certifique-se de que as suas cargas de trabalho estão preparadas para uma interrupção imediata.
- As alterações usam geralmente estratégias de atualização de nós: quando o GKE aplica a maioria das alterações automáticas ou iniciadas manualmente aos nós, incluindo atualizações de nós que não sejam atualizações de versões, o GKE escolhe uma estratégia de atualização de nós: atualizações rápidas ou atualizações azul-verde. O piloto automático usa sempre atualizações de picos. As alterações aos conjuntos de nós do cluster padrão usam normalmente atualizações rápidas, exceto quando configurou atualizações azul-verde e faz determinados tipos de alterações.
- As alterações requerem recursos suficientes: quando o GKE aplica uma alteração através de uma estratégia de atualização de nós, esta alteração requer uma determinada quantidade de recursos, consoante a estratégia e a respetiva configuração. O projeto do cluster tem de ter uma quota de recursos, uma disponibilidade de recursos e uma capacidade de reserva suficientes (para pools de nós com afinidade de reserva específica). Para saber mais, consulte o artigo Garanta recursos para atualizações de nós.
Para uma lista detalhada das alterações específicas e das respetivas caraterísticas, consulte Tipos de alterações a um cluster do GKE nesta página.
Maximize a disponibilidade da carga de trabalho preparando-se para alterações disruptivas
Para maximizar a disponibilidade das suas cargas de trabalho em execução num cluster do GKE, recomendamos que tome as medidas descritas nas secções seguintes:
Escolha a disponibilidade do cluster
Se a disponibilidade do plano de controlo 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 o artigo Acerca das opções de configuração de clusters.
Controle as atualizações com as ferramentas do GKE
Pode usar as seguintes ferramentas para controlar quando e como o GKE atualiza o cluster, o que permite implementar as práticas recomendadas:
- Canais de lançamento: Escolha um canal de lançamento para obter versões de clusters com o equilíbrio escolhido entre disponibilidade e estabilidade de funcionalidades.
- Períodos de manutenção: especifique um período recorrente durante o qual podem ocorrer determinados tipos de manutenção de clusters do GKE>, como atualizações.
- Exclusões de manutenção: impedem que a manutenção do cluster ocorra durante um período específico.
- Estratégias de atualização de nós: se usar clusters padrão, escolha como os nós são atualizados (atualizações de picos ou atualizações azul-verde) para minimizar a interrupção das cargas de trabalho.
- Sequência de implementação: qualifique as atualizações num ambiente de pré-produção antes de o GKE atualizar os seus clusters de produção.
- Atualizações manuais: atualize manualmente o cluster e execute ações como cancelar, retomar, reverter e concluir atualizações automáticas ou manuais em curso.
Faça a gestão e a monitorização do seu cluster
Para gerir potenciais interrupções nos seus clusters, realize continuamente as seguintes tarefas:
- Monitorize o seu cluster com o conjunto de ferramentas de observabilidade do GKE.
- Siga as notas de lançamento do GKE para ver os anúncios.
- Veja notificações de clusters, como quando as atualizações começam ou terminam, quando estão disponíveis novas versões, boletins de segurança e datas de fim do suporte.
- Obtenha visibilidade sobre as atualizações de clusters para compreender o estado das atualizações dos seus clusters.
- Consulte o cronograma de lançamentos do GKE para obter uma estimativa otimista de quando as versões secundárias estão disponíveis para atualizações e atingem o fim do apoio técnico.
- Use orientações prescritivas que identificam potenciais oportunidades de otimização e explicam como otimizar a utilização do cluster, incluindo orientações para descontinuações de funcionalidades e APIs.
Prepare as suas cargas de trabalho
Faça a gestão da interrupção tornando as suas cargas de trabalho o mais resilientes possível à interrupção:
- Execute réplicas das suas cargas de trabalho para garantir a redundância e evitar um único ponto de falha.
- Especifique um orçamento de interrupção para a sua aplicação através de um orçamento de interrupção de pods.
- Defina um período de tolerância de rescisão com a duração adequada para que a sua carga de trabalho seja encerrada de forma adequada.
- Se a sua carga de trabalho estiver a usar GPUs ou TPUs, siga as instruções para gerir interrupções de nós do GKE para GPUs e TPUs.
- Para aplicações com estado, que muitas vezes precisam de tempo para parar corretamente a E/S e desmontar o armazenamento, siga os passos em Certifique-se de que as cargas de trabalho com estado estão prontas para interrupções.
Para uma discussão geral destes tópicos, consulte a secção Gerir interrupções da publicação no blogue Práticas recomendadas do GKE: operações do dia 2 para continuidade da empresa.
Tipos de alterações a um cluster do GKE
As tabelas seguintes mostram os tipos mais comuns de alterações importantes a um cluster, incluindo as caraterísticas destas alterações, como a frequência e o nível de interrupção.
Tipos de atualizações
Reveja a tabela seguinte para compreender como as atualizações 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 |
|---|---|---|---|---|---|
| Atualização do plano de controlo | Automático ou manual |
As atualizações automáticas respeitam as políticas de manutenção até ao fim do apoio técnico, exceto no caso de correções de emergência extremamente raras, conforme necessário. As atualizações manuais não são bloqueadas por políticas de manutenção. |
Atualizações de patches, com uma frequência semanal, consoante o canal de lançamento. Atualizações menores aproximadamente a cada quatro meses. Para clusters de canais expandidos, as atualizações secundárias só são feitas quando a versão secundária se aproxima do fim do suporte. |
Plano de controlo |
Para o Autopilot e os clusters padrão regionais, o plano de controlo permanece disponível. Para clusters padrão zonais, vários minutos em que não pode comunicar com o plano de controlo, o que significa que não pode configurar o cluster, os nós e as cargas de trabalho durante esse período. |
| Atualização de nós | Automático ou manual |
As atualizações automáticas respeitam as políticas de manutenção até ao fim do apoio técnico, exceto no caso de correções de emergência extremamente raras, conforme necessário. As atualizações manuais não são bloqueadas por políticas de manutenção. |
Normalmente, o mesmo que as atualizações do plano de controlo. Se o seu cluster não estiver inscrito num canal de lançamento e desativar as atualizações automáticas de nós, é responsável por atualizar manualmente os node pools do cluster. |
Todos os nós para clusters do Autopilot ou um ou mais conjuntos de nós de clusters padrão. |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa atualizações rápidas para o Autopilot ou a estratégia de atualização de nós configurada (rápida ou azul-verde) para clusters Standard. |
Alterações manuais que recriam os nós através de uma estratégia de atualização de nós e respeitando as políticas de manutenção
Reveja a tabela seguinte para compreender como estas alterações manuais podem perturbar um ambiente de cluster. Esta lista inclui, entre outras alterações, alterações 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 |
|---|---|---|---|---|---|
| Desativar a porta só de leitura do kubelet | Iniciada manualmente | Não respeita as políticas de manutenção e faz alterações imediatamente. | Uma vez por alteração deste tipo. | Todos os nós num cluster do Autopilot Todos os nós num node pool de um cluster Standard. |
Os nós têm de ser encerrados para serem recriados. Os auriculares têm de ser substituídos. O GKE usa imediatamente atualizações por picos para recriar os nós, independentemente de quaisquer políticas de manutenção ativas. |
| Rodar as credenciais do cluster | Automático se as credenciais do cluster expirarem no prazo de 30 dias. Também pode ser iniciado manualmente. | Respeita as políticas de manutenção. No entanto, o GKE pode substituir as políticas de manutenção no prazo de 30 dias após a expiração das credenciais. No prazo de 30 dias, o GKE ignora a disponibilidade de manutenção para o primeiro passo, que é iniciar a rotação. Além disso, se acionar manualmente operações específicas após o primeiro passo, essa operação não respeita as políticas de manutenção. | Uma vez por alteração manual deste tipo ou depende da duração das credenciais do cluster para o início automático. Pode invocar manualmente operações para passos específicos no processo de rotação. | Para alguns passos, o plano de controlo. Para outros passos, todos os nós para clusters do Autopilot e todos os nós em cada conjunto de nós do cluster Standard. |
Quando 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:
|
| Rodar o endereço IP do plano de controlo | Iniciada manualmente | Respeita as políticas de manutenção. No entanto, se acionar manualmente operações específicas após o primeiro passo, essa operação não respeita as políticas de manutenção. | Uma vez por alteração manual deste tipo. Pode invocar manualmente operações para passos específicos no processo de rotação. | Para alguns passos, o plano de controlo. Para outros passos, todos os nós para clusters do Autopilot e todos os nós em cada conjunto de nós do cluster Standard. |
Quando 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:
|
| Configurar nós protegidos | Iniciada manualmente |
A recriação do plano de controlo não respeita as políticas de manutenção e aplica imediatamente as alterações. A recriação dos nós respeita as políticas de manutenção. |
Uma vez por alteração deste tipo |
O plano de controlo é atualizado. Após a atualização do painel de controlo, todos os nós em cada pool de nós do cluster Standard têm de ser recriados. |
Quando o plano de controlo é recriado, o nível de interrupção é o seguinte:
Quando os nós são recriados, o nível de interrupção é o seguinte:
|
| Configurar políticas de rede | Iniciada manualmente | Respeita as políticas de manutenção | Uma vez por alteração deste tipo | Todos os nós para clusters do Autopilot, todos os nós em cada node pool do cluster Standard. |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa atualizações de picos para recriar os nós. |
| Configurar a visibilidade intranó | Iniciada manualmente | Respeita as políticas de manutenção | Uma vez por alteração deste tipo | Todos os nós para clusters do Autopilot, todos os nós em cada node pool do cluster Standard. |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa atualizações de picos para recriar os nós. |
| Configurar o DNSCache NodeLocal | Iniciada manualmente | Respeita as políticas de manutenção | Uma vez por alteração deste tipo | Todos os nós no node pool do cluster padrão que está a ser atualizado têm de ser atualizados. |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa atualizações de picos para recriar os nós. |
| Ativar o streaming de imagens | Iniciada manualmente |
Quando atualiza ao nível do cluster, respeita as políticas de manutenção. Quando atualiza node pools individuais, não respeita as políticas de manutenção. |
Uma vez por alteração deste tipo |
Se for ativada ao nível do node pool, todos os nós no node pool do cluster Standard. Se for ativada/desativada ao nível do cluster, aplica-se aos nós de quaisquer node pools de clusters padrão nos quais não tenha ativado/desativado individualmente a definição para o node pool. |
O GKE usa atualizações de picos para recriar os nós de um node pool. |
Manutenção automática que não respeita as políticas de manutenção
Reveja a tabela seguinte para compreender como a manutenção automática que não respeita as políticas de manutenção pode perturbar 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 |
|---|---|---|---|---|---|
| Reparação ou redimensionamento do plano de controlo | Automático | Não respeitar as políticas de manutenção |
A frequência de reparação do plano de controlo é aleatória, mas não tem impacto nos clusters padrão regionais e do Autopilot. O redimensionamento do plano de controlo é pouco frequente, mas aumenta em frequência com os eventos de escalabilidade do cluster e também não tem impacto nos clusters regionais padrão e do Autopilot. |
Plano de controlo |
Para o Autopilot e os clusters padrão regionais, o plano de controlo permanece disponível. Para clusters padrão zonais, vários minutos em que não pode comunicar com o plano de controlo, o que significa que não pode configurar o cluster, os nós e as cargas de trabalho durante esse período. |
| Evento de manutenção do anfitrião | Automático | Não respeitar as políticas de manutenção | Consulte o artigo Eventos de manutenção para ver a frequência aproximada. | Um nó |
Para a maioria dos tipos de nós, o efeito é mínimo. Alguns nós, incluindo os que têm GPUs ou TPUs, podem sofrer uma maior interrupção. Para saber mais, consulte a secção Outra Trusted Cloud by S3NS manutenção. |
| Reparação automática de nós | Automático | Não respeitar as políticas de manutenção | A frequência de reparação automática de nós é aleatória. |
Um nó | O nó é reiniciado, pelo que todos os pods em execução no nó são interrompidos. |
| Reivindique VMs do Spot e VMs preemptivas | Automático | Não respeitar as políticas de manutenção |
Para VMs preemptivas, pelo menos, uma vez a cada 24 horas. Para VMs de capacidade instantânea, quando o Compute Engine precisa dos recursos noutro local. |
Um nó | Veja detalhes sobre o encerramento e o encerramento normal de VMs de capacidade instantânea e o encerramento e o encerramento normal de VMs preemptíveis. |
| Manutenção da base de dados de estado do cluster baseada no Spanner | Automático | Não respeitar as políticas de manutenção | Os eventos são aleatórios e não têm impacto nos clusters nem nas cargas de trabalho. | Nenhum. A base de dados baseada no Spanner é executada separadamente do painel de controlo do cluster e dos nós na infraestrutura da Google. | Nenhum. A base de dados baseada no Spanner é replicada para todos os tipos de clusters e permanece disponível durante a manutenção. |
Alterações manuais que recriam os nós através de uma estratégia de atualização de nós sem respeitar as políticas de manutenção
Reveja a tabela seguinte para compreender como estas alterações manuais podem perturbar um ambiente de cluster. Esta lista inclui alterações de quando o GKE usa atualizações rápidas e quando o GKE usa atualizações azul-verde que não estão incluídas na outra secção, uma vez que 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 |
|---|---|---|---|---|---|
| Alterações à recolha de registos do plano de controlo | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | O plano de controlo é atualizado. | Quando o plano de controlo é recriado, o nível de interrupção é o seguinte:
|
| Atualização da etiqueta do node pool | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão | O GKE usa imediatamente atualizações rápidas para recriar o node pool quando atualiza as etiquetas de nós num node pool existente, independentemente de quaisquer políticas de manutenção ativas. |
| Escalar verticalmente os nós alterando os atributos da máquina do nó | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão | O GKE usa imediatamente as atualizações por picos para recriar os nós num conjunto de nós existente, independentemente de quaisquer políticas de manutenção ativas. |
| Alterações ao tipo de imagem | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa a estratégia de atualização de nós configurada (aumento ou azul-verde) para clusters Standard. |
| Adicione ou substitua pools de armazenamento num pool de nós do cluster padrão | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa a estratégia de atualização de nós configurada (aumento ou azul-verde) para clusters Standard. |
| Ativar o streaming de imagens | Iniciada manualmente |
Quando atualiza ao nível do cluster, respeita as políticas de manutenção. Quando atualiza node pools individuais, não respeita as políticas de manutenção. |
Uma vez por alteração deste tipo |
Se for ativada ao nível do node pool, todos os nós no node pool do cluster Standard. Se for ativada/desativada ao nível do cluster, aplica-se aos nós de quaisquer node pools de clusters padrão nos quais não tenha ativado/desativado individualmente a definição para o node pool. |
O GKE usa atualizações de picos para recriar os nós de um node pool. |
| Atualizações da configuração de desempenho da rede | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa imediatamente as atualizações por picos para recriar os nós num conjunto de nós existente, independentemente de quaisquer políticas de manutenção ativas. |
| Ativar gVNIC | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa imediatamente as atualizações por picos para recriar os nós num conjunto de nós existente, independentemente de quaisquer políticas de manutenção ativas. |
| Alterações à configuração do sistema de nós | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa imediatamente as atualizações por picos para recriar os nós num conjunto de nós existente, independentemente de quaisquer políticas de manutenção ativas. |
| Nós confidenciais | Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós num conjunto de nós do cluster padrão |
Os nós têm de ser encerrados para serem recriados e os pods têm de ser substituídos. O GKE usa imediatamente as atualizações por picos para recriar os nós num conjunto de nós existente, independentemente de quaisquer políticas de manutenção ativas. |
Alterações que não requerem a recriação dos nós
Reveja a tabela seguinte para saber que alterações à configuração do nó não requerem a recriação dos nós. Estas alterações não são disruptivas. No entanto, ainda é possível que ocorram interrupções se a configuração do nó atualizada afetar a 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 definições:
|
Iniciada manualmente | Não respeita as políticas de manutenção e faz as alterações imediatamente. | Uma vez por alteração deste tipo | Todos os nós relevantes são atualizados. | Não é necessário substituir os pods porque a configuração do nó é atualizada sem recriar os nós. |
O que se segue?
- Vista geral do GKE
- Arquitetura do cluster do GKE
- Responsabilidade partilhada do GKE
- Versões e apoio técnico do GKE
- Contrato de Nível de Serviço do GKE
- Atualizações de clusters do GKE