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

Esta página oferece uma visão geral do processo de upgrade e informações sobre o desvio de versão do Google Distributed Cloud (somente software) para clusters do VMware. Essas informações 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.

Esta página é destinada a administradores de TI e operadores que gerenciam o ciclo de vida da infraestrutura de tecnologia subjacente. Para saber mais sobre papéis comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE Enterprise.

Regras de versão

As regras para upgrades dependem da versão secundária do cluster.

Nas versões 1.30 e anteriores, a versão secundária do cluster de usuário precisa ser igual ou maior que a do cluster de administrador. A versão do patch não importa. Por exemplo, se um cluster de usuário estiver na versão 1.30.1, o cluster de administrador poderá ser atualizado para uma versão de patch mais recente, como 1.30.3.
Para as versões 1.31 e mais recentes, a versão do cluster de administrador, incluindo a versão do patch, precisa ser maior ou igual à do cluster de usuário. Por exemplo, se um cluster de administrador estiver na versão 1.31.1, a versão mais recente para a qual o cluster de usuário pode ser atualizado é 1.31.1.

Quando você quiser fazer upgrade dos clusters para a versão 1.31, primeiro é necessário levar todos os clusters para a versão 1.30. Depois que todos os clusters estiverem na versão 1.30, faça upgrade do cluster de administrador para a versão 1.31. Depois disso, você pode fazer upgrade dos clusters de usuário para a mesma versão do patch 1.31 do cluster de administrador.

Para informações sobre os desvios de versão entre clusters de administrador e de usuário, consulte a seção Desvio da versão neste documento.

Fazer upgrade da sequência

A sequência em que você faz upgrade dos clusters de administrador e de usuário depende da versão do cluster para a qual você está fazendo upgrade, chamada de versão de destino:

1.31 e versões mais recentes

Quando a versão de destino for 1.31 ou mais recente, faça upgrade do cluster de administrador antes de fazer upgrade dos clusters de usuário gerenciados por ele. As etapas a seguir descrevem a sequência de upgrade.

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 Google Cloud CLI ou o Terraform para fazer upgrade de clusters de usuário.
Faça upgrade do cluster de administrador.
Upgrade de clusters de usuário, um de cada vez.
- É possível fazer upgrade do plano de controle de um cluster de usuário separadamente dos pools de nós no cluster de usuário. Para mais informações, consulte Fazer upgrade de pools de nós.
  
  Não disponível para clusters avançados.
- Você pode pular uma versão secundária ao fazer upgrade de pools de nós. Para mais informações, consulte Pular uma versão ao fazer upgrade de pools de nós.
  
  Não disponível para clusters avançados.
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.

1.30 e versões anteriores

Quando a versão de destino for 1.30 ou anterior, será necessário fazer upgrade de todos os clusters de usuário antes de fazer upgrade do cluster de administrador que os gerencia.

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 Google Cloud CLI 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 dos pools de nós no cluster de usuário.
- Na versão 1.16 e mais recentes, é possível pular uma versão secundária ao fazer upgrade de pools de nós. Para mais informações, consulte Pular uma versão ao fazer upgrade de pools de nós.
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 de usuário que ele 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 mais recentes. Para mais informações, consulte a seção Desvio da versão neste documento.

Upgrades do cluster de administrador

1.31 e versões mais recentes

Quando a versão de destino for 1.31 ou mais recente, faça upgrade do cluster de administrador primeiro e depois dos clusters de usuário.

É possível usar gkectl ou a CLI gcloud para fazer upgrade de clusters de administrador.

1.30 e versões anteriores

Quando a versão de destino for 1.30 ou anterior, faça upgrade de todos os clusters de usuário primeiro e depois do cluster de administrador. É possível fazer upgrade 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 mais recente que o 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.

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.

Não disponível em clusters avançados.

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. Para mais informações, consulte Fazer upgrade de pools de nós.

Pular uma versão secundária ao fazer upgrade de pools de nós

Se os clusters estiverem na versão 1.16 ou mais recente, será possível pular uma versão secundária ao fazer upgrade de pools de nós. A execução de um upgrade de versão de salto reduz pela metade o tempo necessário para fazer upgrade sequencial de duas versões dos pools de nós. Além disso, os upgrades de versão pulada permitem aumentar o tempo entre os upgrades necessários para permanecer em uma versão com suporte. Reduzir o número de upgrades diminui as interrupções na carga de trabalho e o tempo de verificação. Para mais informações, consulte Pular uma versão ao fazer upgrade de pools de nós.

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.

Se você tiver clusters avançados ativados, use gkectl para fazer o upgrade. Os clientes da API GKE On-Prem não são compatíveis com clusters avançados.
O console do Google Cloud , a Google Cloud CLI 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 da API GKE On-Prem, que é executada na infraestrutura 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 Google Cloud CLI 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.

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.31 e versões mais recentes

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

Em termos gerais, se 1.n for a versão secundária do cluster de administrador, os clusters do usuário poderão estar em 1.n-2, 1.n-1 ou 1.n. O cluster de administrador não pode ser atualizado para a próxima versão secundária até que todos os clusters de usuário estejam em 1.n ou 1.n-1.

1.29 a 1.30

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.29, os clusters de usuário gerenciados por esse cluster de administrador poderão estar na 1.29, 1.30 ou 1.31.

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.31, os pools de nós no cluster poderão estar na 1.29, 1.30 ou 1.31.

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.31.0 para 1.31.1 ou da 1.30.1 para 1.31.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 você quiser atualizar da versão 1.29.x para a versão 1.31.x, não será possível fazer upgrade diretamente. Primeiro, faça upgrade da versão 1.29.x para a 1.30.x e, em seguida, faça upgrade para a 1.31.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.31 e um pool de nós estiver na 1.29, você poderá pular a 1.30 e fazer upgrade do pool de nós diretamente para a 1.31. 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.

Não disponível em clusters avançados.

Upgrades de versão de patchs

Recomendamos que você faça upgrade para a versão mais recente do patch 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.31.X para a versão 1.31.Y, desde que Y seja maior que X. Por exemplo, é possível fazer upgrade de 1.30.0 para 1.30.1 e de 1.30.1 para 1.30.3.

A seguir

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