Por predefinição, as atualizações automáticas estão ativadas para clusters do Google Kubernetes Engine (GKE) e para node pools padrão do GKE.
Esta página explica como pedir manualmente uma atualização ou uma mudança para uma versão anterior para o plano de controlo ou os nós de um cluster do GKE. Pode atualizar manualmente a versão da seguinte forma:
- Autopilot: atualize a versão do plano de controlo.
- Padrão: atualize a versão do plano de controlo e a versão do node pool.
Para atualizar um cluster, o GKE atualiza a versão em que o painel de controlo e os nós estão a ser executados. Os clusters são atualizados para uma versão secundária mais recente (por exemplo, de 1.24 para 1.25) ou uma versão de patch mais recente (por exemplo, de 1.24.2-gke.100 para 1.24.5-gke.200). Para mais informações, consulte o artigo Versões e apoio técnico do GKE.
Pode saber mais sobre como funcionam as atualizações automáticas e manuais de clusters. Também pode controlar quando as atualizações automáticas podem e não podem ocorrer configurando janelas de manutenção e exclusões.
As novas versões do GKE são anunciadas regularmente, e pode receber um aviso sobre as novas versões disponíveis para cada cluster específico com notificações de cluster. Para encontrar alvos de atualização automática específicos para clusters, obtenha informações sobre as atualizações de um cluster.
Para saber mais sobre as versões disponíveis, consulte a secção Controlo de versões. Para saber mais acerca dos clusters, consulte o artigo Arquitetura de clusters. Para orientações sobre a atualização de clusters, consulte o artigo Práticas recomendadas para atualizar clusters.
Antes de começar
Antes de começar, certifique-se de que realizou as seguintes tarefas:
- Ative a API Google Kubernetes Engine. Ative a API Google Kubernetes Engine
- Se quiser usar a CLI gcloud para esta tarefa,
instale-a e, em seguida,
inicialize-a. Se instalou anteriormente a CLI gcloud, execute
gcloud components updatepara obter a versão mais recente.
- Certifique-se de que tem um cluster do Autopilot ou Standard existente. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.
Guarde os seus dados em discos persistentes
Antes de atualizar um conjunto de nós, tem de garantir que todos os dados que precisa de manter estão armazenados num pod através de volumes persistentes que usam discos persistentes. Os discos persistentes são desmontados, em vez de apagados, durante as atualizações, e os respetivos dados são "transferidos" entre os pods.
As seguintes restrições aplicam-se a discos persistentes:
- Os nós nos quais os pods estão a ser executados têm de ser VMs do Compute Engine
- Essas VMs têm de estar no mesmo projeto e zona do Compute Engine que o disco persistente
Para saber como adicionar um disco persistente a uma instância de nó existente, consulte o artigo Adicionar ou redimensionar discos persistentes zonais na documentação do Compute Engine.
Acerca da atualização
O painel de controlo e os nós de um cluster são atualizados separadamente.
Os painéis de controlo do cluster são sempre atualizados regularmente, independentemente de o cluster estar ou não inscrito num canal de lançamento.
Limitações
Não é possível atualizar os clusters alfa.
Versões suportadas
As notas de lançamento anunciam quando as novas versões ficam disponíveis e quando as versões mais antigas deixam de estar disponíveis. Em qualquer altura, pode listar todas as versões de nós e clusters suportadas através do seguinte comando:
gcloud container get-server-config \
--location=CONTROL_PLANE_LOCATION
Substitua CONTROL_PLANE_LOCATION pela localização (região ou zona) do plano de controlo, como us-central1 ou us-central1-a.
Se o seu cluster estiver inscrito num canal de lançamento, pode atualizar para uma versão de patch num canal de lançamento diferente com a mesma versão secundária que o seu painel de controlo. Por exemplo, pode atualizar o cluster da versão 1.21.12-gke.1700 no canal Regular para a versão 1.21.13-gke.900 no canal Rapid. Para mais informações, consulte o artigo Execute versões de patches a partir de um canal mais recente. Todos os clusters do Autopilot estão inscritos num canal de lançamento.
Limitações de desatualização
Pode reverter a versão do cluster para uma versão anterior em determinados cenários.
Para mitigar uma atualização do painel de controlo do cluster sem êxito, pode reverter o painel de controlo para uma versão de patch anterior se a versão for uma versão de patch anterior na mesma versão secundária. Por exemplo, se o plano de controlo do cluster estiver a executar o GKE 1.25.3-gke.400, pode fazer o downgrade do plano de controlo para 1.25.2-gke.100, se essa versão ainda estiver disponível.
Não pode alterar a versão do painel de controlo de um cluster do Kubernetes para uma versão secundária anterior. Por exemplo, se o plano de controlo executar a versão 1.25 do GKE, não pode fazer o downgrade para a versão 1.24. Se tentar fazê-lo, é apresentada a seguinte mensagem de erro:
ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.24.3-gke.100": specified version is not
newer than the current version.
Não pode reverter a versão secundária do plano de controlo de um cluster. Por isso, recomendamos que teste e qualifique as atualizações de versões secundárias com clusters num ambiente de teste quando uma nova versão secundária fica disponível, mas antes de a versão se tornar predefinida. Isto é especialmente recomendado se o seu cluster puder ser afetado por alterações significativas na próxima versão secundária, como a remoção de APIs ou funcionalidades descontinuadas.
Para mitigar uma atualização sem êxito do conjunto de nós, pode reverter um conjunto de nós para uma versão de patch ou uma versão secundária anterior. Certifique-se de que não atualiza os nós para uma versão com mais de duas versões secundárias em relação à versão do plano de controlo do cluster.
Atualizar o cluster
A Google atualiza os clusters e os nós automaticamente. Para ter mais controlo sobre as atualizações automáticas que o cluster e os respetivos nós recebem, pode inscrevê-lo num canal de lançamento. Todos os clusters do Autopilot estão automaticamente inscritos num canal de lançamento.
Para saber como gerir a versão do GKE do seu cluster, consulte o artigo Atualizações.
Pode iniciar uma atualização manual em qualquer altura após a disponibilização de uma nova versão.
Atualizar manualmente o plano de controlo
Quando inicia uma atualização do cluster, não pode modificar a configuração do cluster durante vários minutos, até que o plano de controlo esteja novamente acessível. Se precisar de evitar o tempo de inatividade durante as atualizações do painel de controlo, considere usar um cluster do Autopilot ou um cluster padrão regional. Esta operação não afeta a disponibilidade dos nós de trabalho em que as suas cargas de trabalho são executadas, uma vez que permanecem disponíveis durante as atualizações do plano de controlo.
Pode atualizar manualmente o plano de controlo do Autopilot ou Standard através da Google Cloud consola ou da CLI do Google Cloud.
gcloud
Para ver as versões disponíveis para o plano de controlo do cluster, execute o seguinte comando:
gcloud container get-server-config \
--location=CONTROL_PLANE_LOCATION
Para atualizar para a versão do cluster predefinida, execute o seguinte comando:
gcloud container clusters upgrade CLUSTER_NAME \
--master \
--location=CONTROL_PLANE_LOCATION
Para atualizar para uma versão específica que não seja a predefinição, especifique a flag --cluster-version, como no seguinte comando:
gcloud container clusters upgrade CLUSTER_NAME \
--master \
--location=CONTROL_PLANE_LOCATION \
--cluster-version=VERSION
Substitua VERSION pela versão para a qual quer atualizar o cluster. Pode usar uma versão específica, como 1.18.17-gke.100, ou um alias de versão, como latest. Para mais
informações, consulte o artigo Especificar a versão do cluster.
Consola
Para atualizar manualmente o plano de controlo do cluster, siga estes passos:
Aceda à página do Google Kubernetes Engine na Google Cloud consola.
Clique no nome do cluster.
Em Noções básicas do cluster, clique em edit Atualização disponível junto a Versão.
Selecione a versão pretendida e, de seguida, clique em Guardar alterações.
Depois de atualizar um painel de controlo padrão, pode atualizar os respetivos nós. Por predefinição, os nós padrão criados através da consola têm a atualização automática ativada, pelo que isto acontece automaticamente. Google Cloud O Autopilot atualiza sempre os nós automaticamente.
Altere a versão dos clusters
- Defina uma exclusão de manutenção antes de fazer o downgrade para impedir que o GKE atualize automaticamente o plano de controlo depois de fazer o downgrade.
Altere o plano de controlo do cluster para uma versão de patch anterior:
gcloud container clusters upgrade CLUSTER_NAME \ --master \ --location=CONTROL_PLANE_LOCATION \ --cluster-version=VERSION
Desativar as atualizações automáticas de clusters
A segurança da infraestrutura é uma prioridade elevada para o GKE e, como tal, os painéis de controlo são atualizados regularmente e não podem ser desativados. No entanto, pode aplicar períodos de manutenção e exclusões para suspender temporariamente as atualizações dos painéis de controlo e dos nós.
Embora não seja recomendado, pode desativar a atualização automática de nós.
Verifique o histórico de atualizações recentes do plano de controlo
Para ver um resumo do histórico de atualizações automáticas recentes de um cluster, obtenha informações sobre as atualizações de um cluster.
Em alternativa, pode listar as operações recentes para ver quando o plano de controlo foi atualizado:
gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
--location=CONTROL_PLANE_LOCATION
Atualizar node pools
Por predefinição, os nós de um cluster têm a atualização automática ativada. As atualizações automáticas dos nós garantem que a versão do painel de controlo e dos nós do cluster permanecem sincronizadas e em conformidade com a política de variação da versão do Kubernetes, o que garante que os painéis de controlo são compatíveis com nós até duas versões secundárias mais antigas do que o painel de controlo. Por exemplo, os planos de controlo do Kubernetes 1.29 são compatíveis com os nós do Kubernetes 1.27.
Evite desativar as atualizações automáticas de nós para que o cluster beneficie das atualizações indicadas no parágrafo anterior.
Com as atualizações de pool de nós do GKE, pode escolher entre duas estratégias de atualização configuráveis, nomeadamente atualizações de picos e atualizações azul-verde.
Escolha uma estratégia e use os parâmetros para ajustar a estratégia de forma a adequar-se melhor às necessidades do seu ambiente de cluster.
Como funcionam as atualizações de nós
Enquanto um nó está a ser atualizado, o GKE deixa de agendar novos pods no mesmo e tenta agendar os respetivos pods em execução noutros nós. Isto é semelhante a outros eventos que recriam o nó, como ativar ou desativar uma funcionalidade no conjunto de nós.
Durante as atualizações automáticas ou manuais de nós,
os orçamentos de interrupção de pods (PDBs)
e o período de tolerância de encerramento de pods
são respeitados durante um máximo de 1 hora. Se não for possível agendar Pods em execução no nó para novos nós após uma hora, o GKE inicia a atualização na mesma. Este comportamento aplica-se mesmo que configure os PDBs para terem sempre todas as réplicas disponíveis definindo o campo maxUnavailable como 0 ou 0%, ou definindo o campo minAvailable como 100% ou o número de réplicas. Em todos estes cenários, o GKE elimina os pods após uma hora para que a eliminação do nó possa ocorrer.
Se uma carga de trabalho exigir mais flexibilidade com a terminação gradual, use atualizações azul-verde, que fornecem definições para um tempo de teste de esforço adicional para prolongar as verificações de PDB para além da predefinição de uma hora.
Para saber mais sobre o que esperar durante a terminação de nós em geral, consulte o tópico sobre Pods.
A atualização só fica concluída quando todos os nós forem recriados e o cluster estiver no estado pretendido. Quando um nó recém-atualizado se regista no plano de controlo, o GKE marca o nó como agendável.
As novas instâncias de nós executam a versão do Kubernetes pretendida, bem como:
Para que uma atualização do node pool seja considerada concluída, todos os nós no node pool têm de ser recriados. Se uma atualização tiver sido iniciada, mas não tiver sido concluída e estiver num estado parcialmente atualizado, a versão do conjunto de nós pode não refletir a versão de todos os nós. Para saber mais, consulte o artigo Algumas versões de nós não correspondem à versão do conjunto de nós após uma atualização incompleta do conjunto de nós. Para determinar que a atualização do conjunto de nós foi concluída, verifique o estado da atualização do conjunto de nós. Se a operação de atualização estiver fora do período de retenção, verifique se a versão de cada nó individual corresponde à versão do conjunto de nós.
Atualize manualmente um node pool
Pode atualizar manualmente a versão de um conjunto de nós para corresponder à versão do plano de controlo ou a uma versão anterior que ainda esteja disponível e seja compatível com o plano de controlo. Pode atualizar manualmente vários conjuntos de nós em paralelo, enquanto o GKE atualiza automaticamente apenas um conjunto de nós de cada vez.
Quando atualiza manualmente um conjunto de nós, o GKE remove todas as etiquetas que
adicionou a nós individuais através de kubectl.
Para evitar esta situação, aplique etiquetas aos conjuntos de nós.
Antes de atualizar manualmente o conjunto de nós, considere as seguintes condições:
- A atualização de um node pool pode interromper as cargas de trabalho em execução nesse node pool. Para evitar esta situação, pode criar um novo conjunto de nós com a versão pretendida e migrar a carga de trabalho. Após a migração, pode eliminar o conjunto de nós antigo.
- Se atualizar um conjunto de nós com um Ingress num estado de erro, o grupo de instâncias não é sincronizado. Para contornar este problema, verifique primeiro o estado através do comando
kubectl get ing. Se o grupo de instâncias não estiver sincronizado, pode contornar o problema reaplicando o manifesto usado para criar a entrada.
Pode atualizar manualmente os seus conjuntos de nós para uma versão compatível com o plano de controlo através da Google Cloud consola ou da CLI Google Cloud.
gcloud
As seguintes variáveis são usadas nos comandos desta secção:
CLUSTER_NAME: o nome do cluster do node pool a ser atualizado.NODE_POOL_NAME: o nome do node pool a ser atualizado.CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, comous-central1ouus-central1-a.VERSION: a versão do Kubernetes para a qual os nós são atualizados. Por exemplo,--cluster-version=1.7.2oucluster-version=latest.
Atualize um node pool:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION
Para especificar uma versão diferente do GKE nos nós, use a flag --cluster-version opcional:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION \
--cluster-version VERSION
Para mais informações sobre a especificação de versões, consulte o artigo Criação de versões.
Para mais informações, consulte a documentação
gcloud container clusters upgrade.
Consola
Para atualizar um conjunto de nós através da Google Cloud consola, siga os passos seguintes:
Aceda à página do Google Kubernetes Engine na Google Cloud consola.
Clique no nome do cluster.
Na página Detalhes do cluster, clique no separador Nós.
Na secção Conjuntos de nós, clique no nome do conjunto de nós que quer atualizar.
Clique em edit Editar.
Clique em Alterar em Versão do nó.
Selecione a versão pretendida na lista pendente Versão do nó e, de seguida, clique em Alterar.
A alteração da versão do nó pode demorar vários minutos.
Alterar a versão dos node pools
Pode alterar para uma versão anterior de um node pool, por exemplo, para mitigar uma atualização do node pool sem êxito. Reveja as limitações antes de fazer a mudança para uma versão anterior de um conjunto de nós.
Use a estratégia de atualização de nós azul-verde se precisar de otimizar a mitigação de riscos para atualizações de conjuntos de nós que afetam as suas cargas de trabalho. Com esta estratégia, pode reverter uma atualização em curso para os nós originais se a atualização não for bem-sucedida.
- Defina uma exclusão de manutenção para o cluster para impedir que o pool de nós seja atualizado automaticamente pelo GKE após a reversão.
- Para reverter um node pool, especifique uma versão anterior seguindo as instruções para atualizar manualmente um node pool.
Alterar os parâmetros de atualização de aumento
Para saber como alterar os parâmetros de atualização de picos, consulte o artigo Configure atualizações de picos.
A verificar o estado da atualização do node pool
Pode verificar o estado de uma atualização através do gcloud container operations.
Veja uma lista de todas as operações em execução e concluídas no cluster dos últimos 12 dias, se houver menos de 5000 operações, ou as últimas 5000 operações:
gcloud container operations list \
--location=CONTROL_PLANE_LOCATION
A cada operação é atribuído um ID da operação e um tipo de operação, bem como horas de início e fim, cluster de destino e estado. A lista é semelhante ao seguinte exemplo:
NAME TYPE ZONE TARGET STATUS_MESSAGE STATUS START_TIME END_TIME
operation-1505407677851-8039e369 CREATE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT16:47:57.851933021Z 20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4 UPGRADE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:40:05.136739989Z 20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989 DELETE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:41:53.918825764Z 20xx-xx-xxT18:43:48.639506814Z
Para obter mais informações sobre uma operação específica, especifique o ID da operação, conforme mostrado no seguinte comando:
gcloud container operations describe OPERATION_ID \
--location=CONTROL_PLANE_LOCATION
Por exemplo:
gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a
Se a atualização foi cancelada ou falhou e está parcialmente concluída, pode retomar ou reverter a atualização.
A verificar as definições de atualização do node pool
Pode ver detalhes sobre a estratégia de atualização de nós que está a ser usada para os seus conjuntos de nós
com o comando gcloud container node-pools
describe. Para as atualizações azul-verde, o comando também devolve a fase
atual
da atualização.
Execute o seguinte comando:
gcloud container node-pools describe NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Substitua o seguinte:
NODE_POOL_NAME: o nome do node pool a descrever.CLUSTER_NAME: o nome do cluster do grupo de nós a descrever.CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, comous-central1ouus-central1-a.
Este comando produz as definições de atualização atuais. O exemplo seguinte mostra o resultado se estiver a usar a estratégia de atualização azul-verde.
upgradeSettings:
blueGreenSettings:
nodePoolSoakDuration: 1800s
standardRolloutPolicy:
batchNodeCount: 1
batchSoakDuration: 10s
strategy: BLUE_GREEN
Se estiver a usar a estratégia de atualização azul-verde, o resultado também inclui detalhes sobre as definições de atualização azul-verde e a respetiva fase intermédia atual. O exemplo seguinte mostra como pode ser apresentado:
updateInfo:
blueGreenInfo:
blueInstanceGroupUrls:
- https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
greenInstanceGroupUrls:
- https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME}
greenPoolVersion: {GREEN_POOL_VERSION}
phase: DRAINING_BLUE_POOL
Cancelar uma atualização do node pool
Pode cancelar uma atualização em qualquer altura. Para saber mais sobre o que acontece quando cancela uma atualização de pico, consulte o artigo Cancele uma atualização de pico. Para saber mais sobre o que acontece quando cancela uma atualização azul-verde, consulte o artigo Cancele uma atualização azul-verde.
Obtenha o ID da operação de atualização:
gcloud container operations list \ --location=CONTROL_PLANE_LOCATIONCancele a atualização:
gcloud container operations cancel OPERATION_ID \ --location=CONTROL_PLANE_LOCATION
Consulte a
gcloud container operations cancel
documentação.
Retomar uma atualização de um node pool
Pode retomar uma atualização iniciando-a manualmente novamente e especificando a versão de destino da atualização original.
Por exemplo, se uma atualização falhou ou se pausou uma atualização em curso, pode retomar a atualização cancelada iniciando novamente a mesma atualização no conjunto de nós, especificando a versão de destino da operação de atualização inicial.
Para saber mais sobre o que acontece quando retoma uma atualização, consulte os artigos Retome uma atualização rápida e atualização azul/verde.
Para retomar uma atualização, use o seguinte comando:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION \
--cluster-version VERSION
Substitua o seguinte:
NODE_POOL_NAME: o nome do node pool para o qual quer retomar a atualização do node pool.CLUSTER_NAME: o nome do cluster do node pool para o qual quer retomar a atualização.CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, comous-central1ouus-central1-a.VERSION: a versão de destino da atualização do conjunto de nós cancelada.
Para mais informações, consulte a gcloud container clusters upgrade
documentação.
Reverter uma atualização de um node pool
Pode reverter um node pool para fazer o downgrade dos nós atualizados para o respetivo estado original de antes do início da atualização do node pool.
Use o comando rollback se uma atualização em curso tiver sido cancelada, a atualização tiver falhado ou a atualização estiver incompleta devido a um limite de tempo de janela de manutenção. Em alternativa, se quiser especificar a versão, siga as
instruções para fazer o downgrade
do conjunto de nós.
Para saber mais sobre o que acontece quando reverte uma atualização de um conjunto de nós, consulte os artigos Reverta uma atualização de picos ou Reverta uma atualização azul/verde.
Para reverter uma atualização, execute o seguinte comando:
gcloud container node-pools rollback NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Substitua o seguinte:
NODE_POOL_NAME: o nome do node pool para o qual reverter a atualização do node pool.CLUSTER_NAME: o nome do cluster do node pool para o qual reverter a atualização.CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, comous-central1ouus-central1-a.
Consulte a gcloud container node-pools rollback
documentação.
Concluir uma atualização do node pool
Se estiver a usar a estratégia de atualização azul-verde, pode concluir uma atualização do conjunto de nós durante a fase de teste de esforço, ignorando o resto do tempo de teste de esforço.
Para saber como funciona a conclusão de uma atualização de node pool, consulte o artigo Conclua uma atualização de node pool.
Para concluir uma atualização quando usar a estratégia de atualização azul/verde, execute o seguinte comando:
gcloud container node-pools complete-upgrade NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Substitua o seguinte:
NODE_POOL_NAME: o nome do node pool para o qual quer concluir a atualização.CLUSTER_NAME: o nome do cluster do node pool para o qual quer concluir a atualização.CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, comous-central1ouus-central1-a.
Consulte a gcloud container node-pools complete-upgrade
documentação.
Problemas conhecidos
Se tiver objetos PodDisruptionBudget configurados que não permitam interrupções adicionais, as atualizações de nós podem falhar ao atualizar para a versão do plano de controlo após várias tentativas. Para evitar esta falha, recomendamos que aumente a escala de Deployment ou HorizontalPodAutoscaler para permitir que o nó seja esvaziado, ao mesmo tempo que respeita a configuração de PodDisruptionBudget.
Para ver todos os objetos PodDisruptionBudget que não permitem interrupções:
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
Embora as atualizações automáticas possam encontrar o problema, o processo de atualização automática força a atualização dos nós. No entanto, a atualização demora mais uma hora por cada nó no espaço de nomes istio-system que viole o PodDisruptionBudget.
Resolução de problemas
Para obter informações sobre a resolução de problemas, consulte o artigo Resolva problemas de atualizações de clusters.
O que se segue?
- Saiba mais sobre a arquitetura de clusters.
- Saiba mais sobre os canais de lançamento.