Vista geral da atualização

Esta página oferece uma vista geral do processo de atualização e das informações de variação de versão do Google Distributed Cloud (apenas software) para clusters VMware. Estas informações devem ajudar a planear a ordem pela qual atualiza os clusters num ambiente de vários clusters. Para informações de planeamento mais detalhadas, incluindo uma lista de verificação para ajudar a planear a atualização, consulte as práticas recomendadas de atualização.

Esta página destina-se a administradores de TI e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE.

Diferenças entre clusters avançados

Quando os clusters avançados estão ativados, existem algumas diferenças com as atualizações, particularmente na pré-visualização de clusters avançados na versão 1.31. Para ver as diferenças da atualização, pesquise a palavra advanced neste documento. Para ver uma tabela de todas as diferenças, consulte Diferenças ao executar clusters avançados.

Atualização automática para clusters avançados na versão 1.33

  • Certifique-se de que tem a versão gkectl: a versão gkectl tem de ser igual à versão de destino. Por exemplo, se estiver a atualizar um cluster não avançado 1.32 para um cluster avançado 1.33.0-gke.799, a versão gkectl tem de ser 1.33.0-gke.799. Este requisito de versão rigoroso só se aplica durante a transição para um cluster avançado. Para todas as atualizações subsequentes no cluster avançado, as regras de variação da versão padrão estão em vigor.
  • Diferença de versões não permitida: quando atualiza de um cluster não avançado para um cluster avançado, não pode atualizar o painel de controlo e os conjuntos de nós separadamente. Tem de atualizar o plano de controlo e todos os conjuntos de nós para a versão 1.33 em simultâneo.

Regras de versões

As regras para atualizações dependem da versão secundária do cluster.

  • Para as versões 1.30 e inferiores, a versão secundária do cluster de utilizadores tem de ser superior ou igual à versão secundária do cluster de administrador. A versão do patch não é importante. Por exemplo, se um cluster de utilizadores estiver na versão 1.30.1, o cluster de administrador pode ser atualizado para uma versão de patch superior, como a 1.30.3.

  • Para as versões 1.31 e superiores, a versão do cluster de administrador, incluindo a versão de patch, tem de ser superior ou igual à versão do cluster de utilizador. Por exemplo, se um cluster de administrador estiver na versão 1.31.1, a versão mais elevada para a qual o cluster de utilizador pode ser atualizado é 1.31.1.

Quando quiser atualizar os seus clusters para a versão 1.31, tem de atualizar primeiro todos os seus clusters para a versão 1.30. Depois de todos os clusters estarem na versão 1.30, atualize o cluster de administrador para a versão 1.31. Depois disso, pode atualizar os clusters de utilizadores para a mesma versão de patch 1.31 que o cluster de administrador.

Regras de versão para gkectl

A versão do gkectl que pode usar para a atualização depende da versão do cluster de destino (ou seja, a versão do cluster para a qual está a fazer a atualização). Normalmente, usa a mesma versão do gkectl que a versão de destino do cluster. As seguintes regras são aplicadas durante a atualização:

  • A versão gkectl não pode ser uma versão secundária inferior à versão secundária do cluster de destino. Por exemplo, se estiver a atualizar um cluster 1.29 para 1.30, não pode usar gkectl 1.29, uma vez que é inferior à versão do cluster de destino. As versões de patch não são importantes. Por exemplo, pode usar a versão gkectl1.29.0-gke.1456 para atualizar para uma versão de patch superior, como 1.29.1000-gke.94.

  • A versão gkectl não pode ser mais de duas versões secundárias superior à versão atual do cluster. Por exemplo, se estiver a atualizar um cluster 1.28 para 1.29, a versão gkectl pode ser 1.29 ou 1.30. No entanto, não pode usar a versão 1.31, uma vez que é três versões secundárias superior à versão do cluster.gkectl

  • Se estiver a atualizar o cluster para um cluster avançado, a versão gkectl tem de ser igual à versão de destino. Por exemplo, se estiver a atualizar um cluster não avançado 1.32 para um cluster avançado 1.33.0-gke.799, a versão gkectl tem de ser 1.33.0-gke.799.

    • O seu cluster vai ser atualizado para o cluster avançado por predefinição na versão 1.33. Isto significa que, para atualizações de 1.32 para 1.33, a versão gkectl tem de ser igual à versão atualizada.

    • Este requisito de versão rigoroso só se aplica durante a transição para um cluster avançado. Para todas as atualizações subsequentes no cluster avançado, as regras de variação da versão padrão estão em vigor.

Se necessário, consulte Transferir gkectl para obter uma versão suportada do gkectl.

Para obter informações sobre as diferenças de versão entre os clusters de administrador e de utilizador, consulte a secção Diferença de versão neste documento.

Funcionalidades antigas bloqueadas em atualizações

O plano de dados V2 é obrigatório para todos os clusters de utilizadores. Antes de atualizar um cluster de utilizadores para a versão 1.31, siga os passos em Ative o Dataplane V2.

As seguintes funcionalidades antigas estão bloqueadas durante a atualização do cluster para a versão 1.32:

  • Configuração do balanceador de carga F5 Big IP integrado
  • Cluster de administrador não de HA
  • Cluster de utilizadores do Kubeception
  • Balanceador de carga Seesaw

Tem de migrar os seus clusters para as funcionalidades recomendadas antes de atualizar para a versão 1.32.

Atualizar sequência

A sequência em que atualiza os clusters de administrador e de utilizador depende da versão do cluster para a qual está a fazer a atualização, denominada versão de destino:

1.31 e superior

Quando a versão de destino é 1.31 ou superior, tem de atualizar o cluster de administrador antes de atualizar os clusters de utilizadores geridos pelo cluster de administrador. Os passos seguintes descrevem a sequência de atualização.

  1. Atualize a estação de trabalho do administrador. Recomendamos que o faça mesmo que planeie usar a Google Cloud consola, a Google Cloud CLI ou o Terraform para atualizar os clusters de utilizadores.

  2. Atualize o cluster de administrador.

  3. Atualize os clusters de utilizadores, um de cada vez.

    • Opcionalmente, pode atualizar o painel de controlo de um cluster de utilizador separadamente dos conjuntos de nós no cluster de utilizador. Para mais informações, consulte o artigo Atualize os conjuntos de nós.

      • Versão 1.31: não disponível em clusters avançados.
      • Versão 1.32 e superior: disponível em clusters avançados.

    • Opcionalmente, pode ignorar uma versão secundária quando atualizar os conjuntos de nós. Para mais informações, consulte o artigo Ignore uma versão ao atualizar conjuntos de nós.

      • Versão 1.31: não disponível em clusters avançados.
      • Versão 1.32 e superior: disponível em clusters avançados.

    Depois de todos os conjuntos de nós num cluster de utilizador estarem na mesma versão que o plano de controlo do cluster de utilizador, o cluster de utilizador é totalmente atualizado.

1,30 e inferior

Quando a versão de destino é 1.30 ou inferior, tem de atualizar todos os clusters de utilizadores antes de atualizar o cluster de administrador que os gere.

  1. Atualize a estação de trabalho do administrador. Recomendamos que o faça mesmo que planeie usar a Google Cloud consola, a Google Cloud CLI ou o Terraform para atualizar os clusters de utilizadores.

  2. Atualize os clusters de utilizadores, um de cada vez.

    • Na versão 1.14 e posteriores, pode atualizar opcionalmente o painel de controlo de um cluster de utilizador separadamente dos conjuntos de nós no cluster de utilizador.

    • Na versão 1.16 e posteriores, pode optar por ignorar uma versão secundária ao atualizar os conjuntos de nós. Para mais informações, consulte o artigo Ignore uma versão ao atualizar conjuntos de nós.

    Depois de todos os conjuntos de nós num cluster de utilizador estarem na mesma versão que o plano de controlo do cluster de utilizador, o cluster de utilizador é totalmente atualizado.

    Um cluster de administrador não pode ter uma versão secundária superior à de qualquer um dos clusters de utilizadores que gere. Se algum dos seus clusters de utilizadores estiver na mesma versão secundária que o cluster de administrador, não pode atualizar o cluster de administrador.

  3. Quando todos os clusters de utilizadores tiverem, pelo menos, uma versão secundária posterior à do cluster de administrador, pode atualizar opcionalmente o cluster de administrador.

A variação da versão e as regras de versão para atualizações foram alteradas na versão 1.28 e posterior. Para mais informações, consulte a secção Diferença entre versões neste documento.

Ordem pela qual os nós são atualizados

A ordem pela qual os nós do plano de controlo do cluster de administrador, os nós do plano de controlo do cluster de utilizador e os nós de trabalho do cluster de utilizador são atualizados depende da versão de destino e se o Controlplane V2 está ativado no cluster de utilizador.

Controlplane V2

Quando o Controlplane V2 está ativado, o plano de controlo para o cluster de utilizadores é executado no próprio cluster de utilizadores. Para o Controlplane V2, os nós do plano de controlo do cluster de utilizadores são atualizados durante a atualização do cluster de utilizadores, e os nós do plano de controlo do cluster de administrador são atualizados durante a atualização do cluster de administrador.

Kubeception

Quando o Controlplane V2 não está ativado, o plano de controlo do cluster de utilizadores é executado num ou mais nós no cluster de administrador. Esta configuração é denominada kubeception. Para clusters kubeception, a versão de atualização determina o comportamento de atualização dos nós:

Versão de atualização Comportamento de atualização do nó
1.32 e superior Os clusters Kubeception não são suportados. Tem de migrar todos os clusters de utilizadores para o plano de controlo V2 antes de atualizar para a versão 1.32.
1.31
  • Os nós do cluster de administrador são atualizados durante a atualização do cluster de administrador.
  • Os nós do painel de controlo do cluster de utilizadores são atualizados durante a atualização do cluster de utilizadores.
1,30 e inferior Os nós do painel de controlo do cluster de utilizadores e os nós do painel de controlo do cluster de administrador são atualizados durante a atualização do cluster de administrador.

Atualizações de clusters de administrador

1.31 e superior

Quando a versão de destino é 1.31 ou superior, tem de atualizar primeiro o cluster de administrador e, em seguida, atualizar os clusters de utilizadores.

Pode usar gkectl ou a CLI gcloud para atualizar clusters de administrador.

1,30 e inferior

Quando a versão de destino é 1.30 ou inferior, atualize primeiro todos os clusters de utilizadores e, em seguida, atualize o cluster de administrador. Pode atualizar o cluster de administrador quando o plano de controlo e os conjuntos de nós em todos os clusters de utilizador estiverem, pelo menos, uma versão secundária superior à do cluster de administrador.

Apenas o gkectl suporta a atualização de clusters de administrador. Os clientes da API GKE On-Prem não suportam a atualização de clusters de administrador.

Atualizações de clusters de utilizadores

Quando atualiza clusters de utilizadores, pode optar por atualizar o cluster de utilizadores como um todo (o que significa que pode atualizar o plano de controlo e todos os conjuntos de nós no cluster) ou pode atualizar o plano de controlo do cluster de utilizadores e deixar os conjuntos de nós na versão atual. A abordagem que adotar depende de vários fatores, como:

  • O ambiente (produção ou não produção) em que o cluster se encontra.
  • A duração do período de manutenção.
  • A versão do cluster de utilizadores.

Por exemplo, num ambiente de desenvolvimento, pode querer manter o processo simples e atualizar o plano de controlo do cluster de utilizadores e todos os conjuntos de nós. No entanto, num ambiente de produção com um curto período de manutenção, pode querer atualizar apenas o plano de controlo, uma vez que demora menos tempo e, com planos de controlo de alta disponibilidade (HA), a atualização do plano de controlo não deve interromper as cargas de trabalho do utilizador. Quando o plano de controlo está na versão 1.28 ou superior, pode ignorar uma versão secundária ao atualizar os conjuntos de nós.

  • Versão 1.31: não disponível em clusters avançados.
  • Versão 1.32 e superior: disponível em clusters avançados.

Atualize seletivamente os node pools

Em determinadas situações, pode querer atualizar alguns, mas não todos os node pools num cluster de utilizador. Por exemplo, depois de atualizar o plano de controlo, pode atualizar um conjunto de nós com pouco tráfego ou que execute as suas cargas de trabalho menos críticas. Depois de se certificar de que as suas cargas de trabalho são executadas corretamente na nova versão, pode atualizar pools de nós adicionais até que todos os pools de nós sejam atualizados. Para mais informações, consulte o artigo Atualize os conjuntos de nós.

Ignorar uma versão secundária ao atualizar node pools

Se os seus clusters estiverem na versão 1.16 ou superior, pode ignorar uma versão secundária ao atualizar os conjuntos de nós. A execução de uma atualização de versão ignorada reduz para metade o tempo necessário para atualizar sequencialmente os node pools duas versões. Além disso, as atualizações de versões ignoradas permitem-lhe aumentar o tempo entre as atualizações necessárias para permanecer numa versão suportada. Reduzir o número de atualizações reduz as interrupções da carga de trabalho e o tempo de validação. Para mais informações, consulte o artigo Ignore uma versão ao atualizar conjuntos de nós.

Escolha uma ferramenta para atualizar os grupos de utilizadores

O Google Distributed Cloud oferece-lhe uma escolha de ferramentas para atualizar clusters de utilizadores.

  • A ferramenta de linhas de comandos gkectl, que executa na sua estação de trabalho de administrador. Antes da atualização, modifique o ficheiro de configuração do cluster de utilizadores para definir a versão de destino do painel de controlo do cluster e, opcionalmente, dos conjuntos de nós. Especifica este ficheiro na linha de comandos para gkectl.

    Se tiver o cluster avançado ativado, tem de usar gkectl para a atualização. Os clientes da API GKE On-Prem não são suportados em clusters avançados.

  • A Google Cloud consola, a CLI Google Cloud ou o Terraform, que pode executar a partir de qualquer computador com conetividade de rede à API GKE On-Prem. Estas ferramentas padrão são clientes da API GKE On-Prem, que é executada na infraestrutura do Google Cloud .

    • Só pode usar o Terraform para a atualização se tiver criado o cluster de utilizadores com o Terraform.

    • Se o cluster de utilizadores foi criado com gkectl, o cluster tem de ser inscrito na API GKE On-Prem para usar a consola ou a CLI gcloud para a atualização. Na versão 1.16 e posteriores, os clusters criados com gkectl são inscritos na API GKE On-Prem por predefinição. Para clusters criados em versões anteriores, pode inscrever o cluster depois de este ser criado.

      Mesmo que decida usar gkectl para a atualização, é recomendável inscrever o cluster na API GKE On-Prem para obter informações sobre os clusters através da consola ou da CLI gcloud.

A ferramenta que usa depende da forma como planeia atualizar os clusters de utilizadores:

  • Atualize o cluster como um todo: Pode usar gkectl, a Google Cloud consola, a Google Cloud CLI ou o Terraform para atualizar um cluster de utilizador (o plano de controlo juntamente com todos os conjuntos de nós).

  • Atualize apenas o painel de controlo: pode usar gkectl, a CLI gcloud ou o Terraform para atualizar o painel de controlo de um cluster de utilizador separadamente dos conjuntos de nós. A consola não suporta a atualização apenas do plano de controlo.

  • Atualize seletivamente os conjuntos de nós após a atualização do plano de controlo: pode usar o gkectl, a CLI gcloud ou o Terraform para atualizar conjuntos de nós específicos após a atualização do plano de controlo.

  • Atualizar o plano de controlo e um ou mais conjuntos de nós ao mesmo tempo: Apenas o gkectl suporta este exemplo de utilização.

Divergência de versões

A variação da versão é a diferença nas versões secundárias entre um cluster de administrador e os respetivos clusters de utilizadores geridos. Nas secções seguintes, a versão do cluster do utilizador refere-se à versão do plano de controlo e dos conjuntos de nós em conjunto, como um todo.

Além disso, a variação da versão é a diferença nas versões secundárias entre o painel de controlo de um cluster de utilizador e os conjuntos de nós no cluster de utilizador.

Num ambiente de vários clusters, compreender a variação de versões suportada e as regras de versões para atualizações pode ajudar a planear a ordem em que atualiza os clusters.

Diferença entre a versão do cluster de administrador e de utilizador

Um cluster de administrador pode gerir clusters de utilizadores que estão em versões diferentes. Esta capacidade permite-lhe atualizar um conjunto de clusters de utilizadores de acordo com uma programação que funcione para a sua organização.

1.31 e superior

Na versão 1.31 e superior, o cluster de administrador pode ter até 2 versões secundárias superiores aos respetivos clusters de utilizador. Por exemplo, se um cluster de administrador estiver na versão 1.31, os clusters de utilizadores geridos por esse cluster de administrador podem estar nas versões 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 de utilizadores podem estar em 1.n-2, 1.n-1 ou 1.n. Não é possível atualizar o cluster de administrador para a versão secundária seguinte até que todos os clusters de utilizadores estejam na versão 1.n ou 1.n-1.

1,29 - 1,30

A variação da versão é igual à da versão 1.28. Na versão 1.29, esta funcionalidade transitou para a fase de disponibilidade geral.

Na versão 1.29 e superior, os clusters de utilizadores podem ter até 2 versões secundárias superiores ao respetivo cluster de administrador. Por exemplo, se um cluster de administrador estiver na versão 1.31, os clusters de utilizadores geridos por esse cluster de administrador podem estar nas versões 1.31, 1.32 ou 1.33.

Em termos gerais, se 1.n for a versão secundária do cluster de administrador, os clusters de utilizadores podem estar em 1.n, 1.n+1 ou 1.n+2. Os clusters de utilizadores em 1.n+2 não podem ser atualizados para a versão secundária seguinte até que o cluster de administrador seja atualizado para, pelo menos, uma versão secundária.

1,28

Na versão 1.28, os clusters de utilizadores podem ter até 2 versões secundárias superiores ao cluster de administrador. Por exemplo, se um cluster de administrador estiver na versão 1.15, os clusters de utilizadores geridos por esse cluster de administrador podem estar nas versões 1.15, 1.16 ou 1.28. Não é possível atualizar os clusters de utilizadores na versão 1.28 para a versão 1.29 até que o cluster de administrador seja atualizado para, pelo menos, a versão 1.16.

1,16 e inferior

Na versão 1.16 e inferior, os clusters de utilizadores só podem ter uma versão secundária superior à do respetivo cluster de administrador. Por exemplo, se um cluster de administrador estiver na versão 1.15, os clusters de utilizadores geridos por esse cluster de administrador podem estar na versão 1.15 ou 1.16.

Em termos gerais, se 1.n for a versão secundária do cluster de administrador, os clusters de utilizadores podem estar na versão 1.n ou 1.n+1. Não é possível atualizar os clusters de utilizadores para a versão secundária seguinte até que o cluster de administrador esteja na mesma versão secundária que o cluster de utilizadores.

Diferença entre a versão do painel de controlo do cluster de utilizadores e a versão do node pool

1.29 e superior

A variação da versão é igual à da versão 1.28. Na versão 1.29, esta funcionalidade transitou para a fase de disponibilidade geral.

Na versão 1.29 e superior, o plano de controlo de um cluster de utilizadores pode ter até 2 versões secundárias superiores aos conjuntos de nós no cluster. Por exemplo, se o plano de controlo de um cluster de utilizador estiver na versão 1.33, os conjuntos de nós no cluster podem estar nas versões 1.31, 1.32 ou 1.33.

Em termos gerais, se 1.n for a versão secundária de um plano de controlo do cluster de utilizadores, os node pools no cluster podem estar em 1.n, 1.n-1 ou 1.n-2. Não é possível atualizar os painéis de controlo do cluster de utilizadores para a versão secundária seguinte até que todos os conjuntos de nós estejam na versão 1.n ou 1.n-1.

1,28

Na versão 1.28, o plano de controlo de um cluster de utilizadores pode ter até 2 versões secundárias superiores aos conjuntos de nós no cluster. Por exemplo, se o plano de controlo de um cluster de utilizadores estiver na versão 1.28, os conjuntos de nós no cluster podem estar nas versões 1.15, 1.16 ou 1.28. Não é possível atualizar os painéis de controlo do cluster de utilizadores para a versão 1.29 até que todos os conjuntos de nós estejam na versão 1.28 ou 1.16.

1,16 e inferior

Na versão 1.16 e inferior, o plano de controlo de um cluster de utilizadores só pode ter uma versão secundária superior à dos conjuntos de nós no cluster. Por exemplo, se o painel de controlo de um cluster de utilizador estiver na versão 1.16, os node pools no cluster podem estar na versão 1.15 ou 1.16.

Em termos gerais, se 1.n for a versão secundária de um painel de controlo do cluster de utilizadores, os conjuntos de nós no cluster podem estar em 1.n ou 1.n-1. Não é possível atualizar os clusters de utilizadores para a versão secundária seguinte até que todos os conjuntos de nós estejam na mesma versão secundária que o plano de controlo.

Regras de versão para atualizações do plano de controlo do cluster de administrador e do cluster de utilizador

As regras de versão para clusters de administrador e atualizações do painel de controlo do cluster de utilizador são as mesmas. Pode atualizar diretamente para qualquer versão que esteja na mesma versão secundária ou na versão secundária seguinte. Por exemplo, pode atualizar de 1.33.0 para 1.33.1 ou de 1.32.1 para 1.33.0. As versões de patch não afetam as regras da versão de atualização.

Se estiver a atualizar para uma versão que não faz parte do próximo lançamento secundário, tem de atualizar através de uma versão de cada lançamento secundário entre a sua versão atual e a versão de destino. Ignorar uma versão secundária não é suportado. Por exemplo, se quiser atualizar da versão 1.31.x para a versão 1.33.x, não pode fazer a atualização diretamente. Primeiro, tem de atualizar de 1.31.x para 1.32.x e, em seguida, atualizar para 1.33.x.

Em termos gerais, apenas são suportadas atualizações de 1.n para 1.n+1 para atualizações do cluster de administrador e atualizações do painel de controlo do cluster de utilizador.

Regras de versão para atualizações de node pools

Na versão 1.28 e posteriores, pode ignorar uma versão secundária ao atualizar um conjunto de nós num cluster de utilizador. Por exemplo, se um painel de controlo do cluster de utilizadores estiver na versão 1.33 e um conjunto de nós estiver na versão 1.31, pode ignorar a versão 1.32 e atualizar o conjunto de nós diretamente para a versão 1.33. As versões de patch não afetam as regras de versão de atualização.

Em termos gerais, se um painel de controlo do cluster de utilizadores estiver na versão 1.n, pode atualizar os conjuntos de nós que estão na versão 1.n-2 diretamente para a versão 1.n. Ignorar uma versão secundária ao atualizar pools de nós pode reduzir o tempo em comparação com a realização de duas atualizações de pools de nós (para atualizar de 1.n-2 para 1.n-1 e, em seguida, para 1.n). Este é outro motivo pelo qual pode preferir atualizar o plano de controlo de um cluster de utilizador separadamente dos pools de nós que são executados no cluster de utilizador.

  • Versão 1.31: não disponível em clusters avançados.
  • Versão 1.32 e superior: disponível em clusters avançados.

Atualizações da versão de patch

Recomendamos que atualize para a versão de patch mais recente sempre que possível para garantir que os seus clusters têm as correções de segurança mais recentes. As versões de patch não afetam a discrepância de versões nem as regras de atualização. Para uma determinada versão secundária, pode atualizar para qualquer versão de patch superior. Ou seja, pode atualizar um cluster de versão 1.33.X para a versão 1.33.Y, desde que Y seja superior a X. Por exemplo, pode atualizar do 1.32.0 para o 1.32.1 e do 1.32.1 para o 1.32.3.

O que se segue?

Reveja as práticas recomendadas de atualização e crie um plano para atualizar os seus clusters.