Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Esta página foi traduzida pela API Cloud Translation.

Visão geral do upgrade

Nesta página, você encontra uma visão geral do processo de upgrade e informações do desvio de versão que ajudam a planejar a ordem de upgrade dos clusters em um ambiente de vários clusters. Para informações de planejamento mais detalhadas, incluindo uma lista de verificação para ajudar a planejar o upgrade, consulte as práticas recomendadas de upgrade.

Fazer upgrade da sequência

Os upgrades no local desde a versão 1.7 precisam sempre seguir uma sequência de upgrade específica:

Faça upgrade da estação de trabalho do administrador. Recomendamos que você faça isso mesmo que se planeja usar o console do Google Cloud, a CLI do Google Cloud ou o Terraform para fazer upgrade de clusters de usuário.
Upgrade de clusters de usuário, um de cada vez. Na versão 1.14 e mais recentes, é possível fazer upgrade do plano de controle de um cluster de usuário separadamente do pools de nós no cluster de usuário. Para mais informações sobre por que você pode querer fazer isso, consulte Upgrades de cluster de usuário.

Depois que todos os pools de nós em um cluster de usuário estiverem na mesma versão que plano de controle do cluster do usuário, o cluster do usuário terá o upgrade concluído.

Um cluster de administrador não pode estar em uma versão secundária mais recente do que qualquer um dos clusters que o usuário gerencia. Se algum dos seus clusters de usuário estiver na mesma versão secundária que o cluster de administrador, não vai ser possível fazer upgrade do cluster de administrador.
Quando todos os clusters de usuário forem pelo menos uma versão secundária posterior ao cluster de administrador, será possível fazer upgrade dele.

O desvio de versão e as regras de versão para upgrades mudaram na versão 1.28 e nas versões mais recentes. Para mais informações, consulte Desvio da versão.

Upgrades de cluster de usuário

Ao fazer upgrade de clusters de usuário, é possível fazer upgrade deles como um todo (ou seja, é possível fazer upgrade do plano de controle e de todos os pools de nós cluster) ou fazer upgrade do plano de controle do cluster de usuário e deixar os pools de nós na versão atual. A abordagem adotada depende de vários fatores, como:

O ambiente (produção ou não produção) em que o cluster está.
A duração da sua janela de manutenção.
A versão do cluster de usuário.

Por exemplo, em um ambiente de desenvolvimento, convém manter o processo e fazer upgrade do plano de controle do cluster de usuário e de todos os pools de nós. Mas, em um ambiente de produção com uma janela de manutenção curta, é possível fazer upgrade apenas do plano de controle, já que isso leva menos tempo e com planos de controle de alta disponibilidade (HA), a atualização do plano de controle não deve interromper as cargas de trabalho do usuário. Quando o plano de controle estiver na versão 1.28 ou mais recente, será possível pular uma versão secundária ao fazer upgrade de pools de nós.

O upgrade de pools de nós separadamente do plano de controle é compatível com pools de nós do Ubuntu e do COS, mas não com os do Windows.

Fazer upgrade seletivo dos pools de nós

Em determinadas situações, pode ser necessário fazer upgrade de alguns, mas não de todos os pools de nós em um cluster de usuário. Por exemplo, depois de fazer upgrade do plano de controle, é possível fazer upgrade de um pool de nós com tráfego leve ou executar suas cargas de trabalho menos importantes. Depois que você estiver convencido de que as cargas de trabalho são executadas corretamente na nova versão, será possível fazer upgrade de outros pools de nós até que todos eles sejam atualizados.

Escolher uma ferramenta para fazer upgrade dos clusters de usuário

O Google Distributed Cloud oferece várias ferramentas para fazer upgrade dos clusters de usuário.

A ferramenta de linha de comando gkectl, executada na estação de trabalho do administrador. Antes do upgrade, você modifica o arquivo de configuração do seu cluster de usuário para definir a versão de destino do plano de controle do cluster e, opcionalmente, para os pools de nós. Esse arquivo é especificado na linha de comando como gkectl.
O console do Google Cloud, a CLI do Google Cloud ou o Terraform, que pode ser executado em qualquer computador que tenha conectividade de rede com a API GKE On-Prem. Essas ferramentas padrão são clientes API GKE On-Prem, que são executados na infraestrutura do Google Cloud.
- O Terraform só pode ser usado para o upgrade se você tiver criado o cluster do usuário usando o Terraform.
- Se o cluster de usuário foi criado usando gkectl, ele precisa ser registrado na API GKE On-Prem para usar o console ou a gcloud CLI para o upgrade. Na versão 1.16 e mais recentes, os clusters criados usando gkectl são registrados na API GKE On-Prem por padrão. Para clusters criados nas versões anteriores, é possível inscrever o cluster depois de criado.
  
  Mesmo que você decida usar gkectl no upgrade, convém registrar o cluster na API GKE On-Prem para receber informações sobre os clusters usando o console ou a gcloud CLI.

A ferramenta usada depende de como você planeja fazer upgrade dos clusters de usuário:

Faça upgrade do cluster como um todo: é possível usar o gkectl, o console do Google Cloud, a CLI do Google Cloud ou o Terraform para fazer upgrade de um cluster de usuário (o plano de controle com todos os pools de nós).
Faça upgrade apenas do plano de controle: é possível usar o gkectl, a gcloud CLI ou o Terraform para fazer upgrade de um plano de controle do cluster do usuário separadamente dos pools de nós. O console não dá suporte ao upgrade apenas do plano de controle.
Fazer upgrade seletivo dos pools de nós após o upgrade do plano de controle: é possível usar gkectl, a gcloud CLI ou o Terraform para fazer upgrade pools de nós específicos após o upgrade do plano de controle.
Faça upgrade do plano de controle e de um ou mais pools de nós ao mesmo tempo: apenas gkectl oferece suporte a esse caso de uso.

Upgrades do cluster de administrador

Quando o plano de controle e os pools de nós em todos os clusters de usuário são pelo menos uma versão secundária posterior ao cluster de administrador, é possível fazer upgrade cluster de administrador. Apenas gkectl oferece suporte ao upgrade de clusters de administrador. Os clientes da API GKE On-Prem não oferecem suporte ao upgrade de clusters de administrador.

Versão skew

O desvio da versão é a diferença de versões secundárias entre um cluster de administrador e os clusters de usuário gerenciados. Nas seções a seguir, a versão do cluster do usuário se refere à versão do plano de controle e dos pools de nós como um todo.

Além disso, o desvio de versão é a diferença em versões secundárias entre o plano de controle de um cluster de usuário e os pools de nós no cluster de usuário.

Em um ambiente de vários clusters, entender o desvio de versão com suporte e as regras de versão para upgrades pode ajudar você a planejar a ordem do upgrade dos clusters.

Desvio da versão do cluster de administrador e de usuário

Um cluster de administrador pode gerenciar clusters de usuários que estejam em versões diferentes. Esse recurso permite fazer upgrade de uma frota de clusters de usuários em uma programação que funcione para sua organização.

1.29 e versões mais recentes

O desvio da versão é o mesmo da 1.28. Na versão 1.29, esse recurso foi transferido para o estágio de Disponibilidade geral.

Na versão 1.29 e mais recentes, os clusters de usuário podem ter até duas versões secundárias mais recentes que o cluster de administrador. Por exemplo, se um cluster de administrador estiver na versão 1.28, os clusters de usuário gerenciados por esse cluster de administrador poderão estar na 1.28, 1.29 ou 1.30.

Em termos gerais, se 1.n for a versão secundária do cluster de administrador, os clusters do usuário podem estar em 1.n, 1.n+1 ou 1.n+2. Os clusters de usuário em 1.n+2 não podem fazer upgrade para a próxima versão secundária até que o cluster de administrador seja atualizado em uma versão secundária.

1.28

Na versão 1.28, os clusters de usuário podem ser até duas versões secundárias mais recentes que o cluster de administrador. Por exemplo, se um cluster de administrador estiver em 1.15, os clusters do usuário gerenciados pelo cluster de administrador podem estar em 1,15, 1,16 ou 1,28. Os clusters do usuário em 1.28 não podem ser atualizados para 1.29 até que o cluster de administrador seja para a versão 1.16 ou mais recente.

1.16 e versões anteriores

Na versão 1.16 e anteriores, os clusters de usuário só podem ter uma versão secundária mais recente que o cluster de administrador. Por exemplo, se um cluster de administrador estiver em 1.15, os clusters do usuário gerenciados pelo cluster de administrador podem estar em 1,15 ou 1,16.

Em termos gerais, se 1.n for a versão secundária do cluster de administrador, os clusters do usuário podem estar em 1.n ou 1.n+1. Não é possível fazer upgrade dos clusters de usuário para a próxima versão secundária até que o cluster de administrador esteja na mesma versão secundária que o cluster de usuário.

Desvio da versão do pool de nós e do plano de controle do cluster de usuário

1.29 e versões mais recentes

O desvio da versão é o mesmo da 1.28. Na versão 1.29, esse recurso foi transferido para o estágio de Disponibilidade geral.

Na versão 1.29 e mais recentes, o plano de controle de um cluster de usuário pode ter até duas versões secundárias mais recentes que os pools de nós no cluster. Por exemplo, se um plano de controle do cluster de usuário estiver na 1.30, os pools de nós no cluster poderão estar na 1.28, 1.29 ou 1.30.

Em termos gerais, se 1.n for a versão secundária de um plano de controle de cluster de usuário, os pools de nós no cluster podem estar em 1.n, 1.n-1 ou 1.n-2. Os planos de controle do cluster de usuário não podem ser atualizados para a próxima versão secundária até que todos os pools de nós estão em 1.n ou 1.n-1.

1.28

Na versão 1.28, o plano de controle de um cluster de usuário pode ter até duas versões secundárias mais recentes que os pools de nós no cluster. Por exemplo, se o plano de controle do cluster do usuário estiver em 1,28, os pools de nós no cluster podem estar em 1,15, 1,16, ou 1,28. Não é possível fazer upgrade dos planos de controle do cluster de usuário para a versão 1.29 até que todos os pools de nós estejam em 1.28 ou 1.16.

1.16 e versões anteriores

Na versão 1.16 e anteriores, o plano de controle de um cluster de usuário só pode ter uma versão secundária mais recente que os pools de nós no cluster. Por exemplo, se um plano de controle do cluster de usuário estiver em 1,16, os pools de nós no cluster podem estar em 1,15 ou 1,16.

Em termos gerais, se 1.n for a versão secundária de um plano de controle de cluster de usuário, os pools de nós no cluster podem estar em 1.n ou 1.n-1. Não é possível fazer upgrade de clusters de usuário para a próxima versão secundária até que todos os pools de nós estejam na mesma versão secundária que o plano de controle.

Regras de versão para upgrades do cluster de administrador e do plano de controle do cluster de usuário

As regras de versão para clusters de administrador e upgrades do plano de controle do cluster de usuário são iguais. É possível fazer upgrade diretamente para qualquer versão que esteja na mesma versão secundária ou na próxima versão secundária. Por exemplo, é possível fazer upgrade da versão 1.30.0 para a 1.30.1 ou da 1.29.1 para a 1.30.0. As versões de patch não afetam as regras de versão de atualização.

Se você estiver fazendo upgrade para uma versão que não faz parte da próxima versão secundária, será necessário atualizar uma versão de cada versão secundária entre a versão atual e a desejada. Não é possível pular uma versão secundária. Por exemplo, se quiser atualizar da versão 1.28.x para a versão 1.30.x, não será possível fazer upgrade diretamente. Primeiro, você precisa fazer upgrade da versão 1.28.x para a 1.29.x e, em seguida, fazer upgrade para a 1.30.x.

Em termos gerais, apenas upgrades do 1.n para o 1.n+1 têm suporte para upgrades de cluster de administrador e de plano de controle do cluster de usuário.

Regras de versão para upgrades do pool de nós

Na versão 1.28 e posterior, você pode ignorar uma versão secundária ao atualizar um pool de nós em um cluster de usuário. Por exemplo, se um plano de controle de cluster de usuário estiver na 1.30 e um pool de nós estiver em 1.28, você poderá ignorar a 1.29 e atualizar o pool de nós diretamente para a 1.30. As versões de patch não afetam as regras de versão de upgrade.

Em termos gerais, se um plano de controle do cluster de usuário estiver em 1.n, será possível fazer upgrade dos pools de nós que estão em 1.n-2 diretamente para 1.n. Ignorar uma versão secundária ao atualizar pools de nós pode reduzir o tempo gasto em duas atualizações de pool de nós (para atualizar da 1.n-2 para 1.n-1 e depois para 1.n). Esse é outro motivo pelo qual você pode preferir atualizar o plano de controle de um cluster de usuário separadamente dos pools de nós executados no cluster de usuário.

Upgrades de versão de patchs

Recomendamos que você faça o upgrade para a versão de patch mais recente sempre que possível para garantir que os clusters tenham as correções de segurança mais recentes. As versões de patch não afetam as regras de atualização e distorção de versão. Para uma determinada versão secundária, é possível fazer upgrade para qualquer versão de patch superior. Ou seja, é possível fazer upgrade de um cluster de versão 1.30.X para a versão 1.30.Y, desde que Y seja maior que X. Por exemplo, é possível fazer upgrade de 1.29.0 para 1.29.1, bem como de 1.29.1 para 1.29.3.

A seguir

Consulte as Práticas recomendadas de upgrade e crie um plano para fazer upgrade dos clusters.