Atualize um cluster

Este documento explica como atualizar clusters no Google Distributed Cloud (apenas software) para VMware. Este documento fornece os passos para atualizar a estação de trabalho do administrador, os clusters de utilizadores e os clusters de administrador. Os passos para atualizar um cluster de utilizador mostram como atualizar o plano de controlo e todos os conjuntos de nós. Se quiser atualizar o painel de controlo do cluster de utilizador e os node pools separadamente, consulte o artigo Atualize node pools.

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 que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Antes de continuar, recomendamos que reveja a seguinte documentação:

  • Vista geral da atualização
    Entre outras coisas, este documento descreve a variação de versões suportada e as regras de versão para atualizações, que foram alteradas para a versão 1.28 e posteriores.

  • Práticas recomendadas de atualização
    Este documento fornece listas de verificação e práticas recomendadas para atualizar clusters.

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 desvio 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.

Requisitos

Esta secção fornece informações sobre os requisitos relacionados com a versão e os requisitos para usar os clientes da API GKE On-Prem (a Google Cloud consola, a CLI do Google Cloud e o Terraform) para atualizações.

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 é a 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.

Reveja as regras de firewall

Na versão 1.29 e posteriores, as verificações prévias do lado do servidor estão ativadas por predefinição. As verificações prévias do lado do servidor requerem regras de firewall adicionais. Em Regras de firewall para clusters de administrador, pesquise "Verificações prévias" e certifique-se de que todas as regras de firewall necessárias estão configuradas.

Com as verificações prévias do lado do servidor, quando atualiza um cluster de utilizadores com o comando gkectl, as verificações prévias são executadas no cluster de administrador em vez de localmente na estação de trabalho de administrador. As verificações prévias do lado do servidor também são executadas no cluster de administração quando usa a consola, a Google Cloud CLI ou o Terraform para atualizar um cluster. Google Cloud

Quando atualiza um cluster de administrador, o Google Distributed Cloud implementa um cluster Kubernetes in Docker (kind) para alojar temporariamente os controladores do Kubernetes necessários para atualizar o cluster de administrador. Este cluster transitório é denominado cluster de arranque. As verificações prévias do lado do servidor são executadas no cluster de arranque quando atualiza um cluster de administrador.

Ative o Dataplane V2

O Dataplane V2 tem de estar ativado em todos os clusters de utilizadores a partir da versão 1.31. Antes de atualizar um cluster de utilizadores para a versão 1.31, siga estes passos. Se tiver dúvidas acerca da remoção temporária da especificação NetworkPolicy, contacte o Apoio técnico da Google.

Defina enableDataplaneV2 como true no ficheiro de configuração do cluster de utilizadores.

Se o seu cluster estiver a usar um NetworkPolicy, remova temporariamente a respetiva especificação do cluster da seguinte forma:

  1. Verifique se existem NetworkPolicynão pertencentes ao sistema aplicadas ao seu cluster:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system
    
  2. Se o resultado do passo anterior não estiver vazio, guarde cada especificação num ficheiro para que possa reaplicar a especificação após atualizar o cluster.NetworkPolicy

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
    

    Substitua o seguinte:

    • NETWORK_POLICY_NAME: o nome do NetworkPolicy que está a guardar.
    • NETWORK_POLICY_NAMESPACE: o espaço de nomes do NetworkPolicy.
  3. Elimine o NetworkPolicy através do seguinte comando:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE
    
  4. Continuar com a atualização.

  5. Após a conclusão da atualização, se removeu especificações não pertencentes ao sistema NetworkPolicy, volte a aplicá-las com este comando:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
    

Requisitos da API Google e da IAM

Para atualizar um cluster para a versão 1.28 e posterior, tem de ativar o kubernetesmetadata.googleapis.com e conceder a kubernetesmetadata.publisherfunção do IAM à conta de serviço de registo e monitorização. Estas alterações são necessárias para usar o Cloud Monitoring.

  1. Ative kubernetesmetadata.googleapis.com:

    gcloud services enable --project PROJECT_ID  \
        kubernetesmetadata.googleapis.com
    

    Substitua PROJECT_ID pelo ID do projeto anfitrião da frota no qual o cluster de utilizadores é membro. Este é o projeto que especificou quando o cluster foi criado. Se criou o cluster usando gkectl, este é o ID do projeto no campo gkeConnect.projectID do ficheiro de configuração do cluster.

  2. Se a sua organização tiver configurado uma lista de autorizações que permita a passagem de tráfego das APIs Google e de outros endereços através do seu servidor proxy, adicione kubernetesmetadata.googleapis.com à lista de autorizações.

  3. Conceda a função kubernetesmetadata.publisher à conta de serviço de registo e monitorização:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
        --role "roles/kubernetesmetadata.publisher"
    

    Substitua SERVICE_ACCOUNT_EMAIL pelo endereço de email da sua conta de serviço de registo e monitorização.

Funcionalidades antigas bloqueadas em atualizações

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

  • Dataplane V1 (Calico)
  • 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.

Requisitos da IAM para atualizar clusters de utilizadores

Ignore esta secção se planear usar o gkectl para a atualização do cluster de utilizadores.

Se quiser usar a Google Cloud consola, a CLI do Google Cloud ou o Terraform para atualizar um cluster de utilizadores e não for proprietário do projeto, tem de lhe ser atribuído o papel de gestão de identidades e acessos roles/gkeonprem.admin no projeto Google Cloud em que o cluster foi criado. Para ver detalhes sobre as autorizações incluídas nesta função, consulte Funções do GKE On-Prem na documentação da IAM.

Para usar a consola para atualizar o cluster, no mínimo, também precisa do seguinte:

  • roles/container.viewer. Esta função permite que os utilizadores vejam a página Clusters do GKE e outros recursos de contentores na consola. Para ver detalhes sobre as autorizações incluídas nesta função ou para conceder uma função com autorizações de leitura/escrita, consulte as funções do Kubernetes Engine na documentação do IAM.

  • roles/gkehub.viewer. Esta função permite que os utilizadores vejam clusters na consola. Para ver detalhes sobre as autorizações incluídas nesta função ou para conceder uma função com autorizações de leitura/escrita, consulte as funções do GKE Hub na documentação do IAM.

Limitações com clusters avançados

Tenha em atenção as seguintes limitações se tiver os clusters avançados ativados:

  • Tem de usar o gkectl para atualizar clusters. Os clientes da API GKE On-Prem (a consola, a CLI gcloud e o Terraform) não são suportados.

  • Apenas são suportadas atualizações síncronas.

Faça alterações de configuração antes ou depois de uma atualização

Se precisar de fazer alterações de configuração aos seus clusters, faça a atualização do cluster antes ou depois da atualização. A única alteração à configuração do cluster para uma atualização deve ser a versão. Consoante a versão e o tipo do cluster, outras alterações de configuração são ignoradas silenciosamente ou fazem com que a atualização falhe. Para mais informações, consulte o artigo Remova alterações não suportadas para desbloquear a atualização.

Verifique as versões disponíveis para atualizações de clusters

Execute o seguinte comando para ver que versões estão disponíveis para atualização:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de administrador.

O resultado mostra a versão atual e as versões disponíveis para atualização.

Se planeia usar a consola, a CLI gcloud ou o Terraform para a atualização, demoram cerca de 7 a 14 dias após um lançamento para que a versão esteja disponível na API GKE On-Prem em todas as Google Cloud regiões. A consola apresenta apenas as versões disponíveis para a atualização do cluster de utilizadores. Os passos para atualizar um cluster de utilizador através da CLI gcloud ou do Terraform incluem um passo para executar gcloud container vmware clusters query-version-config para obter as versões disponíveis para a atualização.

Atualize a sua estação de trabalho de administrador

A forma como atualiza a estação de trabalho de administrador depende da forma como a criou: gkeadm ou gerida pelo utilizador.

gkeadm

Localize os ficheiros necessários

Antes de criar a estação de trabalho de administrador, preencheu um ficheiro de configuração da estação de trabalho de administrador gerado pelo gkeadm create config. O nome predefinido deste ficheiro é admin-ws-config.yaml.

Além disso, a sua estação de trabalho tem um ficheiro de informações. O nome predefinido deste ficheiro é o mesmo que o nome da sua estação de trabalho de administrador.

Localize o ficheiro de configuração da estação de trabalho do administrador e o ficheiro de informações. Tem de pedir-lhe que siga os passos de atualização. Se estes ficheiros estiverem no seu diretório atual e tiverem os nomes predefinidos, não tem de os especificar quando executar os comandos de atualização. Se estes ficheiros estiverem noutro diretório ou se tiver alterado os nomes dos ficheiros, especifique-os através das flags --config e --info-file.

Se o ficheiro de informações de saída estiver em falta, pode recriá-lo. Consulte o artigo Recrie um ficheiro de informações se estiver em falta.

Atualizar

Para atualizar a estação de trabalho de administrador:

  1. Verifique o campo adminWorkstation.diskGB no ficheiro de configuração da estação de trabalho de administração e certifique-se de que o tamanho especificado é, pelo menos, 100, por exemplo:

    adminWorkstation:
      diskGB: 100
    

    Quando atualiza para a versão 1.28 e superior, são necessários 100 GB, e a atualização do cluster falha se a estação de trabalho do administrador não tiver espaço no disco suficiente.

  2. No servidor de acesso rápido, transfira o ficheiro gkeadm:

    gkeadm upgrade gkeadm --target-version TARGET_VERSION
    

    Substitua TARGET_VERSION pela versão para a qual está a fazer a atualização. Tem de especificar um número de versão completo no formato X.Y.Z-gke.N.. Para ver uma lista das versões do Google Distributed Cloud, consulte o artigo Versões.

  3. Atualize a sua estação de trabalho de administrador:

    gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \
        --info-file INFO_FILE
    

    Substitua o seguinte:

    • AW_CONFIG_FILE: o caminho do ficheiro de configuração da estação de trabalho do administrador. Pode omitir esta flag se o ficheiro estiver no seu diretório atual e tiver o nome admin-ws-config.yaml.

    • INFO_FILE: o caminho do seu ficheiro de informações. Pode omitir esta flag se o ficheiro estiver no seu diretório atual. O nome predefinido deste ficheiro é o mesmo que o nome da sua estação de trabalho de administrador.

Gerido pelo utilizador

Na estação de trabalho do administrador, navegue para um diretório onde quer instalar uma nova versão dogkectl.

  1. Transferir gkectl:

    gcloud storage cp gs://gke-on-prem-release/gkectl/TARGET_VERSION/gkectl ./
    chmod +x gkectl
    

    Substitua TARGET_VERSION pela versão para a qual está a fazer a atualização. Tem de especificar um número de versão completo no formato X.Y.Z-gke.N.. Para ver uma lista das versões do Google Distributed Cloud, consulte o artigo Versões.

  2. Transfira o pacote do Google Distributed Cloud. Certifique-se de que a versão corresponde à que usou para transferir o gkectl:

    gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz ./
    

Atualize o cluster de administrador

Os passos para atualizar o cluster de administrador variam ligeiramente consoante a versão secundária para a qual está a fazer a atualização (a versão de destino):

1.31 e superior

Se a versão de destino for 1.31 ou superior, antes de atualizar os clusters de utilizadores para a versão secundária seguinte, tem de atualizar o cluster de administrador. Na versão 1.31 e superior, 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 é a 1.31.1.

Execute o seguinte comando na estação de trabalho de administração para importar imagens do SO para o vSphere:

gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de administrador.

1,30 e inferior

Se a versão de destino for 1.30 ou inferior, tem de atualizar todos os clusters de utilizadores antes de atualizar o cluster de administrador. A versão secundária do cluster de administrador tem de ser inferior ou igual à versão secundária do cluster de utilizador. A versão de correção 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 1.30.3.

Antes de começar:

  1. Se estiver a atualizar para a versão 1.13 ou superior, tem de registar primeiro o cluster de administrador preenchendo a secção gkeConnect no ficheiro de configuração do cluster de administrador. Execute o comando gkectl update cluster com as alterações do ficheiro de configuração.

  2. Certifique-se de que o gkectl e os clusters são a versão adequada para uma atualização e que transferiu o pacote adequado. A diferença entre as versões dos clusters de administrador e de utilizador depende da versão do Google Distributed Cloud. Para se certificar de que pode atualizar o cluster de administrador, consulte o artigo Diferença entre versões do cluster de administrador e do cluster de utilizadores.

  3. Certifique-se de que o campo bundlepath no ficheiro de configuração do cluster de administrador corresponde ao caminho do pacote para o qual quer fazer a atualização.

    Se fizer outras alterações aos campos no ficheiro de configuração do cluster de administração, estas alterações são ignoradas durante a atualização. Para que essas alterações produzam efeito, tem primeiro de atualizar o cluster e, em seguida, executar um comando update cluster com as alterações do ficheiro de configuração para fazer outras alterações ao cluster.

Faça a atualização

Execute os passos desta secção na sua estação de trabalho de administrador. Existem duas variações do comando gkectl upgrade admin:

  • Assíncrona:
    com a variação assíncrona, o comando inicia a atualização e, em seguida, é concluído. Não precisa de ver o resultado do comando durante toda a duração da atualização. Em alternativa, pode verificar periodicamente o progresso da atualização executando gkectl list admin e gkectl describe admin. Para usar a variação assíncrona, inclua a flag --async no comando.

    Requisitos para a atualização assíncrona:

    • Apenas suportado para clusters de administrador de HA com a versão 1.29 ou superior.
    • Todos os clusters de utilizadores têm de ter o Controlplane V2 ativado.
    • Versão 1.31: não suportada em clusters avançados.
    • Versão 1.32 e superior: disponível em clusters avançados.
  • Síncrono:
    Com a variação síncrona, o comando gkectl upgrade admin produz mensagens de estado na estação de trabalho do administrador à medida que a atualização progride.

Atualização assíncrona

  1. Na estação de trabalho de administração, inicie uma atualização assíncrona:

    gkectl upgrade admin \
      --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE \
      --async
    

    Substitua o seguinte:

    • ADMIN_CLUSTER_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

    • ADMIN_CLUSTER_CONFIG_FILE: o caminho para o ficheiro de configuração do cluster de administrador.

    O comando anterior é concluído e pode continuar a usar a estação de trabalho de administrador enquanto a atualização está em curso.

  2. Para ver o estado da atualização:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    O resultado mostra um valor para o cluster STATE. Se o cluster ainda estiver a ser atualizado, o valor de STATE é UPGRADING. Por exemplo:

    NAME              STATE         AGE    VERSION
    gke-admin-test    UPGRADING     9h     1.33.0-gke.799
    

    Os valores possíveis para STATE são RUNNING, UPGRADING, RECONCILING, ERROR e UNKNOWN.

  3. Para ver mais detalhes sobre o progresso da atualização e os eventos de cluster:

    gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    O resultado mostra o recurso personalizado OnPremAdminCluster para o cluster de administrador especificado, que inclui o estado, as condições e os eventos do cluster.

    Registamos eventos para o início e o fim de cada fase de atualização crítica.

    Exemplo de saída:

    Events:
    Type    Reason                             Age   From                             Message
    ----       ------                                  ----     ----                                -------
    Normal  ControlPlaneUpgradeStarted         40m   onprem-admin-cluster-controller  Creating or updating admin cluster API Controller
    Normal  ControlPlaneMachineUpgradeStarted  40m   onprem-admin-cluster-controller  Creating or updating control plane machine
    Normal  StatusChanged                      40m   onprem-admin-cluster-controller  OnPremAdminCluster status changed:
    - New ClusterState condition: UPGRADING
    - New Ready condition: False, CreateOrUpdateControlPlaneMachine, Creating or updating control plane machine
    Normal   StatusChanged      2m                onprem-admin-cluster-controller  OnPremAdminCluster status changed:
    - New ClusterState condition: RUNNING
    - New Ready condition: True, ClusterRunning, Cluster is running
    
  4. Quando a atualização estiver concluída, o gkectl list admin apresenta um STATUS de RUNNING:

    NAME              STATE         AGE    VERSION
    gke-admin-test    RUNNING       9h     1.33.0-gke.799
    

    Além disso, quando a atualização estiver concluída, o gkectl describe admin mostra um campo Last GKE On Prem Version em Status. Por exemplo:

    Status:
      Cluster State:  RUNNING
      Last GKE On Prem Version:  1.33.0-gke.1
    

Resolva problemas de atualização assíncrona

Para uma atualização assíncrona, a duração do limite de tempo baseia-se no número de nós no cluster. Se a atualização demorar mais do que a duração do limite de tempo, o estado do cluster é alterado de UPGRADING para ERROR, com um evento a indicar que a operação de atualização excedeu o limite de tempo. Tenha em atenção que o estado ERROR aqui significa que a atualização está a demorar mais do que o esperado, mas não foi terminada. O controlador continua a conciliação e continua a tentar a operação. Quando uma atualização é bloqueada ou falha, pode executar o comando gkectl diagnose para verificar se existem problemas comuns no cluster. Com base no resultado, pode decidir se quer fazer uma correção manual ou contactar o Google Cloud apoio técnico para receber assistência adicional.

Atualização síncrona

  1. Execute o seguinte comando:

    gkectl upgrade admin \
      --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG_FILE
    

    Substitua o seguinte:

    • ADMIN_CLUSTER_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.

    • ADMIN_CLUSTER_CONFIG_FILE: o caminho para o ficheiro de configuração do cluster de administrador.

    O comando gkectl upgrade executa verificações de pré-publicação. Se as verificações prévias falharem, o comando é bloqueado. Tem de corrigir as falhas ou usar a flag --skip-preflight-check-blocking com o comando para desbloqueá-lo.

  2. Se estiver a atualizar para a versão 1.14.0 ou superior, é gerado um novo ficheiro kubeconfig para o cluster de administrador que substitui qualquer ficheiro existente. Para ver os detalhes do cluster no ficheiro, execute o seguinte comando:

    kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Atualize um cluster de utilizadores

Pode usar gkectl, a consola, a CLI gcloud ou o Terraform para atualizar um cluster de utilizadores. Para obter informações sobre como decidir que ferramenta usar, consulte o artigo Escolha uma ferramenta para atualizar os grupos de utilizadores.

gkectl

Prepare-se para atualizar um cluster de utilizadores

Siga os passos abaixo na estação de trabalho do administrador:

  1. Execute este passo apenas se o TARGET_VERSION for 1.30 ou inferior, ou se estiver a atualizar o cluster de utilizadores para uma versão diferente do cluster de administrador. Execute gkectl prepare para importar imagens do SO para o vSphere:

    gkectl prepare \
      --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
      --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    
  2. Se o cluster tiver um node pool do Windows, execute gkectl prepare windows e atualize o campo osImage para o node pool. Para obter instruções detalhadas, consulte o artigo Atualize o cluster de utilizadores com pools de nós do Windows.

  3. No ficheiro de configuração do cluster de utilizadores, defina gkeOnPremVersion para a versão de destino da atualização.

Execute verificações prévias

Quando fizer a atualização para a versão 1.29 e superior, pode executar as verificações prévias antes de atualizar um cluster de utilizadores:

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG \
    --dry-run

Substitua USER_CLUSTER_CONFIG pelo caminho para o ficheiro de configuração do cluster do utilizador.

Com a flag --dry-run, o gkectl upgrade cluster executa as verificações prévias, mas não inicia o processo de atualização. Embora as versões anteriores do Google Distributed Cloud executem verificações preliminares, não é possível executá-las separadamente da atualização. Ao adicionar a flag --dry-run, pode encontrar e corrigir quaisquer problemas que as verificações prévias encontrem no seu cluster de utilizadores antes da atualização.

Execução gkectl upgrade cluster

Existem duas variações do comando gkectl upgrade cluster:

  • Assíncrona: (recomendada)
    Com a variação assíncrona, o comando inicia a atualização e, em seguida, é concluído. Não precisa de ver o resultado do comando durante toda a duração da atualização. Em alternativa, pode verificar periodicamente o progresso da atualização executando gkectl list clusters e gkectl describe clusters. Para usar a variação assíncrona, inclua a flag --async no comando.

    • Versão 1.31: não disponível em clusters avançados.
    • Versão 1.32 e superior: disponível em clusters avançados.
  • Síncrono:
    Com a variação síncrona, o comando gkectl upgrade cluster produz mensagens de estado na estação de trabalho do administrador à medida que a atualização progride.

Atualização assíncrona

  1. Ignore este passo se estiver a atualizar para uma versão posterior a 1.16.

    Se estiver a usar credenciais preparadas e um registo privado para o cluster de utilizadores, certifique-se de que a credencial do registo privado está preparada antes de atualizar o cluster de utilizadores. Para ver informações sobre como preparar a credencial do registo privado, consulte o artigo Configure credenciais preparadas para clusters de utilizadores.

  2. Na estação de trabalho de administração, inicie uma atualização assíncrona:

    gkectl upgrade cluster \
      --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config USER_CLUSTER_CONFIG \
      --async
    

    O comando anterior é concluído e pode continuar a usar a estação de trabalho de administrador enquanto a atualização está em curso.

  3. Para ver o estado da atualização:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    O resultado mostra um valor para o cluster STATE. Se o cluster ainda estiver a ser atualizado, o valor de STATE é UPGRADING. Por exemplo:

    NAMESPACE             NAME    READY   STATE       AGE   VERSION
    my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.33.0-gke.1
    

    Os valores possíveis para STATE são PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR e UNKNOWN.

  4. Para ver mais detalhes sobre o progresso da atualização e os eventos de cluster:

    gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --cluster USER_CLUSTER_NAME -v 5
    

    O resultado mostra o recurso personalizado OnPremUserCluster para o cluster de utilizadores especificado, que inclui o estado, as condições e os eventos do cluster.

    Registamos eventos para o início e o fim de cada fase de atualização crítica, incluindo:

    • ControlPlaneUpgrade
    • MasterNodeUpgrade
    • AddonsUpgrade
    • NodePoolsUpgrade

    Exemplo de saída:

    Events:
    Type    Reason                      Age    From                            Message
    ----     ------                     ----   ----                            -------
    Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
    Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
    Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
    Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running
    
  5. Quando a atualização estiver concluída, o gkectl list clusters apresenta um STATUS de RUNNING:

    NAMESPACE             NAME    READY   STATE     AGE     VERSION
    my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.33.0-gke.1
    

    Além disso, quando a atualização estiver concluída, o gkectl describe clusters mostra um campo Last GKE On Prem Version em Status. Por exemplo:

    Status:
    Cluster State:  RUNNING
    Last GKE On Prem Version:  1.33.0-gke.1
    

Resolva problemas de atualização assíncrona

Para uma atualização assíncrona, a duração do limite de tempo baseia-se no número de nós no cluster. Se a atualização demorar mais do que a duração do limite de tempo, o estado do cluster é alterado de UPGRADING para ERROR, com um evento a indicar que a operação de atualização atingiu o limite de tempo. Tenha em atenção que o estado ERROR aqui significa que a atualização está a demorar mais do que o esperado, mas não foi terminada. O controlador continua a conciliação e volta a tentar a operação.

Normalmente, um limite de tempo é o resultado de um impasse causado por um PodDisruptionBudget (PDB). Nesse caso, não é possível desalojar os pods dos nós antigos, nem esvaziar os nós antigos. Se a remoção do pod demorar mais de 10 minutos, escrevemos um evento no objeto OnPremUserCluster. Pode capturar o evento executando gkectl describe clusters. Em seguida, pode ajustar o PDB para permitir que o nó seja esvaziado. Após esse período, a atualização pode prosseguir e, eventualmente, ser concluída.

Exemplo de evento:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

Além disso, quando uma atualização é bloqueada ou falha, pode executar gkectl diagnose para verificar se existem problemas comuns no cluster. Com base no resultado, pode decidir se quer fazer uma correção manual ou contactar a equipa de apoio técnico do Anthos para receber mais assistência.

Atualização síncrona

O comando gkectl upgrade executa verificações de pré-publicação. Se as verificações prévias falharem, o comando é bloqueado. Tem de corrigir as falhas ou usar a flag --skip-preflight-check-blocking. Só deve ignorar as verificações pré-lançamento se tiver a certeza de que não existem falhas críticas.

Siga estes passos na estação de trabalho do administrador:

  1. Ignore este passo se estiver a atualizar para uma versão posterior a 1.16.

    Se estiver a usar credenciais preparadas e um registo privado para o cluster de utilizadores, certifique-se de que a credencial do registo privado está preparada antes de atualizar o cluster de utilizadores. Para ver informações sobre como preparar a credencial do registo privado, consulte o artigo Configure credenciais preparadas para clusters de utilizadores.

  2. Atualize o cluster:

    gkectl upgrade cluster \
      --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config USER_CLUSTER_CONFIG
    
  3. Se estiver a atualizar para a versão 1.14.0 ou superior, é gerado um novo ficheiro kubeconfig para o cluster de utilizador que substitui qualquer ficheiro existente. Para ver os detalhes do cluster no ficheiro, execute o seguinte comando:

    kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG

Retome uma atualização

Se uma atualização do cluster de utilizadores for interrompida, pode retomar a atualização do cluster de utilizadores executando o mesmo comando de atualização com a flag --skip-validation-all:

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE \
    --skip-validation-all

Consola

A atualização de um cluster de utilizadores requer algumas alterações ao cluster de administrador. A consola faz automaticamente o seguinte:

  • Inscreve o cluster de administrador na API GKE On-Prem se ainda não estiver inscrito.

  • Transfere e implementa um pacote de componentes no cluster de administrador. A versão dos componentes corresponde à versão especificada para a atualização. Estes componentes permitem que o cluster de administrador faça a gestão dos clusters de utilizadores nessa versão.

Para atualizar um cluster de utilizadores:

  1. Na consola, aceda à página Vista geral dos clusters do Google Kubernetes Engine.

    Aceda aos clusters do GKE

  2. Selecione o Google Cloud projeto e, de seguida, selecione o cluster que quer atualizar.

  3. No painel Detalhes, clique em Mais detalhes.

  4. Na secção Noções básicas do cluster, clique em Atualizar.

  5. Na lista Escolher versão de destino, selecione a versão para a qual quer fazer a atualização. A lista organizada contém apenas os lançamentos de patches mais recentes.

  6. Clique em Atualizar.

Antes de o cluster ser atualizado, são executadas verificações prévias para validar o estado do cluster e o estado de funcionamento dos nós. Se as verificações pré-implementação forem aprovadas, o cluster de utilizadores é atualizado. A atualização demora cerca de 30 minutos a ser concluída.

Para ver o estado da atualização, clique em Mostrar detalhes no separador Detalhes do cluster.

CLI gcloud

A atualização de um cluster de utilizadores requer algumas alterações ao cluster de administrador. O comando gcloud container vmware clusters upgrade faz automaticamente o seguinte:

  • Inscreve o cluster de administrador na API GKE On-Prem se ainda não estiver inscrito.

  • Transfere e implementa um pacote de componentes no cluster de administrador. A versão dos componentes corresponde à versão especificada para a atualização. Estes componentes permitem que o cluster de administrador faça a gestão dos clusters de utilizadores nessa versão.

Para atualizar um cluster de utilizadores:

  1. Atualize os componentes da CLI do Google Cloud:

    gcloud components update
    
  2. Obtenha uma lista das versões disponíveis para atualização:

    gcloud container vmware clusters query-version-config \
      --cluster=USER_CLUSTER_NAME \
      --project=PROJECT_ID \
      --location=REGION
    

    O resultado do comando é semelhante ao seguinte:

    versions:
    - version: 1.16.3-gke.45
    - version: 1.16.2-gke.28
    - version: 1.16.1-gke.45
    - version: 1.16.0-gke.669
    - version: 1.15.6-gke.25
    - version: 1.15.5-gke.41
    
    An Anthos version must be made available on the admin cluster ahead of the user
    cluster creation or upgrade. Versions annotated with isInstalled=true are
    installed on the admin cluster for the purpose of user cluster creation or
    upgrade whereas other version are released and will be available for upgrade
    once dependencies are resolved.
    
    To install the version in the admin cluster, run:
    $ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION
    

    Pode ignorar a mensagem após a lista de versões. Não importa se a versão para a qual está a fazer a atualização está instalada no cluster de administrador. O comando upgrade transfere e implementa um pacote dos componentes que correspondem à versão especificada no comando upgrade.

  3. Atualize o cluster.

    gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
      --project=PROJECT_ID \
      --location=REGION \
      --version=VERSION
    

    Substitua VERSION pela versão do Google Distributed Cloud para a qual quer fazer a atualização. Especifique uma versão a partir do resultado do comando anterior. Recomendamos que atualize para a versão de patch mais recente.

    O resultado do comando é semelhante ao seguinte:

    Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
    

    No exemplo de saída, a string operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 é o OPERATION_ID da operação de longa duração. Pode saber o estado da operação executando o seguinte comando noutra janela do terminal:

    gcloud container vmware operations describe OPERATION_ID \
      --project=PROJECT_ID \
      --location=REGION
    

Terraform

  1. Atualize os componentes da CLI do Google Cloud:

    gcloud components update
    
  2. Se ainda não o fez, inscreva o cluster de administrador na API GKE On-Prem. Depois de o cluster estar inscrito na API GKE On-Prem, não precisa de fazer este passo novamente.

  3. Obtenha uma lista das versões disponíveis para atualização:

    gcloud container vmware clusters query-version-config \
      --cluster=USER_CLUSTER_NAME \
      --project=PROJECT_ID \
      --location=REGION
    

    Substitua o seguinte:

    • USER_CLUSTER_NAME: o nome do cluster de utilizadores.

    • PROJECT_ID: o ID do projeto da frota no qual esse cluster de utilizadores é membro. Este é o projeto que especificou quando o cluster foi criado. Se criou o cluster usando gkectl, este é o ID do projeto no campo gkeConnect.projectID do ficheiro de configuração do cluster.

    • REGION: A Google Cloud região na qual a API GKE On-Prem é executada e armazena os respetivos metadados. No ficheiro main.tf que usou para criar o cluster de utilizadores, a região está no campo location do recurso de cluster.

    O resultado do comando é semelhante ao seguinte:

    versions:
    - version: 1.16.3-gke.45
    - version: 1.16.2-gke.28
    - version: 1.16.1-gke.45
    - version: 1.16.0-gke.669
    - version: 1.15.6-gke.25
    - version: 1.15.5-gke.41
    
    An Anthos version must be made available on the admin cluster ahead of the user
    cluster creation or upgrade. Versions annotated with isInstalled=true are
    installed on the admin cluster for the purpose of user cluster creation or
    upgrade whereas other version are released and will be available for upgrade
    once dependencies are resolved.
    
    To install the version in the admin cluster, run:
    $ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION
    
  4. Transfira a nova versão dos componentes e implemente-os no cluster de administração:

    gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
      --project=PROJECT_ID \
      --location=REGION \
      --required-platform-version=VERSION
    

    Este comando transfere a versão dos componentes que especificar em --required-platform-version para o cluster de administrador e, em seguida, implementa os componentes. Estes componentes permitem que o cluster de administrador faça a gestão dos clusters de utilizadores nessa versão.

  5. No ficheiro main.tf que usou para criar o cluster de utilizadores, altere on_prem_version no recurso de cluster para a nova versão.

  6. Inicialize e crie o plano do Terraform:

    terraform init
    

    O Terraform instala todas as bibliotecas necessárias, como o Google Cloud fornecedor.

  7. Reveja a configuração e faça alterações, se necessário:

    terraform plan
    
  8. Aplique o plano do Terraform para criar o cluster de utilizadores:

    terraform apply
    

Remova o pacote completo

Se transferiu um pacote completo e executou com êxito gkectl prepare e atualizou o cluster de administrador e todos os clusters de utilizadores, deve eliminar o pacote completo para poupar espaço em disco na estação de trabalho do administrador. Execute o seguinte comando para eliminar o pacote completo:

rm /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION-full.tgz

Retomar uma atualização do cluster de administrador

Se uma atualização do cluster de administrador for interrompida ou falhar, a atualização pode ser retomada se o ponto de verificação do cluster de administrador contiver o estado necessário para restaurar o estado anterior à interrupção.

Aviso: não repare o mestre de administrador com gkectl repair admin-master após uma tentativa de atualização falhada. Isto faz com que o cluster de administração entre num estado inválido.

Siga estes passos:

  1. Verifique se o plano de controlo de administrador está em bom estado antes de iniciar a tentativa de atualização inicial. Consulte o artigo Diagnosticar problemas de clusters. Conforme abordado nesse tópico, execute o comando gkectl diagnose cluster para o cluster de administrador.

  2. Se o plano de controlo do administrador não estiver em bom estado antes da tentativa de atualização inicial, repare o plano de controlo do administrador com o comando gkectl repair admin-master.

  3. Quando executar novamente o comando de atualização depois de uma atualização ter sido interrompida ou ter falhado, use o mesmo pacote e versão de destino que usou na tentativa de atualização anterior.

Quando executa novamente o comando de atualização, a atualização retomada recria o estado do cluster de administrador a partir do ponto de verificação e executa novamente toda a atualização. A partir da versão 1.12.0, se o plano de controlo do administrador não estiver em bom estado, o processo de atualização é feito diretamente para a versão de destino sem tentar restaurar o cluster de administrador na versão de origem antes de avançar para a atualização.

A atualização é retomada a partir do ponto em que falhou ou foi terminada se o ponto de verificação do cluster de administrador estiver disponível. Se o ponto de verificação não estiver disponível, a atualização volta a depender do plano de controlo do administrador e, por isso, o plano de controlo do administrador tem de estar em bom estado para continuar com a atualização. Após uma atualização bem-sucedida, o ponto de verificação é regenerado.

Se o gkectl sair inesperadamente durante uma atualização do cluster de administrador, o cluster do tipo não é limpo. Antes de executar novamente o comando de atualização para retomar a atualização, elimine o cluster do tipo:

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Depois de eliminar o cluster do Kind, volte a executar o comando de atualização.

Reverta uma estação de trabalho de administrador após uma atualização

Pode reverter a estação de trabalho de administração para a versão usada antes da atualização.

Durante a atualização, o gkeadm regista a versão antes da atualização no ficheiro de informações de saída. Durante a reversão, o gkeadm usa a versão indicada para transferir o ficheiro mais antigo.

Para reverter a estação de trabalho de administração para a versão anterior:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Pode omitir --config=AW_CONFIG_FILE se o ficheiro de configuração da estação de trabalho do administrador for o admin-ws-config.yaml predefinido. Caso contrário, substitua AW_CONFIG_FILE pelo caminho para o ficheiro de configuração da estação de trabalho do administrador.

O comando de reversão executa estes passos:

  1. Transfere a versão de reversão de gkeadm.
  2. Faz uma cópia de segurança do diretório inicial da estação de trabalho de administração atual.
  3. Cria uma nova estação de trabalho de administrador com a versão de reversão de gkeadm.
  4. Elimina a estação de trabalho de administração original.

Instale o pacote com uma versão diferente para atualização

Se atualizar a estação de trabalho, é instalado um pacote com uma versão correspondente para atualizar os clusters. Se quiser uma versão diferente, siga estes passos para instalar um pacote para TARGET_VERSION, que é a versão para a qual quer atualizar.

  1. Para verificar as versões atuais do gkectl e do cluster, execute este comando. Use a flag --details/-d para ver informações mais detalhadas.

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
    

    O resultado fornece informações sobre as versões do cluster.

  2. Com base no resultado que obtém, procure os seguintes problemas e corrija-os conforme necessário.

    • Se a versão atual do cluster de administrador for mais de uma versão secundária inferior à TARGET_VERSION, atualize todos os seus clusters para que sejam uma versão secundária inferior à TARGET_VERSION.

    • Se a versão gkectl for inferior a 1.11 e quiser atualizar para a versão 1.12.x, tem de fazer várias atualizações. Atualize uma versão secundária de cada vez até chegar à versão 1.11.x e, em seguida, siga as instruções neste tópico.

    • Se a versão do gkectl for inferior à do TARGET_VERSION, atualize a estação de trabalho de administração para a versão TARGET_VERSION.

  3. Quando tiver determinado que as versões do gkectl e do cluster são adequadas para uma atualização, transfira o pacote.

    Verifique se o ficheiro tar.gz do pacote já existe na estação de trabalho do administrador.

    stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz

    Se o pacote não estiver na estação de trabalho do administrador, transfira-o.

    gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
    

  4. Instale o pacote.

    gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

    Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do seu ficheiro kubeconfig. Pode omitir esta flag se o ficheiro estiver no seu diretório atual e tiver o nome kubeconfig.

  5. Liste as versões de cluster disponíveis e certifique-se de que a versão de destino está incluída nas versões de cluster de utilizador disponíveis.

    gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Agora, pode criar um cluster de utilizadores na versão de destino ou atualizar um cluster de utilizadores para a versão de destino.

Resolução de problemas do processo de atualização

Se tiver um problema ao seguir o processo de atualização recomendado, siga estas recomendações para o resolver. Estas sugestões partem do princípio de que começou com uma configuração da versão 1.11.x e está a seguir o processo de atualização recomendado.

Consulte também: Resolução de problemas de criação e atualização de clusters

Resolução de problemas de atualização de um cluster de utilizadores

Suponha que encontra um problema com a versão de atualização quando atualiza um cluster de utilizadores. Determina através do apoio técnico da Google que o problema vai ser corrigido numa versão de patch futura. Pode proceder da seguinte forma:

  1. Continuar a usar a versão atual para produção.
  2. Teste o lançamento do patch num cluster de não produção quando for lançado.
  3. Atualize todos os clusters de utilizadores de produção para a versão de lançamento de patch quando tiver confiança.
  4. Atualize o cluster de administrador para a versão de lançamento do patch.

Resolução de problemas de atualização de um cluster de administrador

Se encontrar um problema ao atualizar o cluster de administrador, tem de contactar o Apoio técnico da Google para resolver o problema com o cluster de administrador.

Entretanto, com o novo fluxo de atualização, pode continuar a beneficiar das novas funcionalidades do cluster de utilizadores sem ser bloqueado pela atualização do cluster de administrador, o que lhe permite reduzir a frequência de atualização do cluster de administrador, se quiser. O processo de atualização pode prosseguir da seguinte forma:

  1. Atualize os clusters de utilizadores de produção para a versão 1.12.x.
  2. Manter o cluster de administrador na versão anterior e continuar a receber patches de segurança.
  3. Testar a atualização do cluster de administrador de 1.11.x para 1.12.x num ambiente de teste e comunicar problemas, se existirem;
  4. Se o problema for resolvido com um lançamento de patch 1.12.x, pode optar por atualizar o cluster de administrador de produção para este lançamento de patch, se quiser.

Problemas conhecidos das versões recentes

Os seguintes problemas conhecidos podem afetar as atualizações se estiver a atualizar a partir da versão 1.7 ou posterior.

Veja também: Problemas conhecidos

A atualização da estação de trabalho de administração pode falhar se o disco de dados estiver quase cheio

Se atualizar a estação de trabalho de administrador com o comando gkectl upgrade admin-workstation, a atualização pode falhar se o disco de dados estiver quase cheio, porque o sistema tenta fazer uma cópia de segurança da estação de trabalho de administrador atual localmente enquanto atualiza para uma nova estação de trabalho de administrador. Se não conseguir libertar espaço suficiente no disco de dados, use o comando gkectl upgrade admin-workstation com a flag adicional --backup-to-local=false para evitar fazer uma cópia de segurança local da estação de trabalho do administrador atual.

Interrupção para cargas de trabalho com PodDisruptionBudgets

A atualização de clusters pode causar interrupções ou indisponibilidade para cargas de trabalho que usam PodDisruptionBudgets (PDBs).

Os nós não conseguem concluir o respetivo processo de atualização

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}'

Anexo

Acerca das regras do VMware DRS ativadas na versão 1.1.0-gke.6

A partir da versão 1.1.0-gke.6, o Google Distributed Cloud cria automaticamente regras de antiafinidade do VMware Distributed Resource Scheduler (DRS) para os nós do cluster de utilizador, o que faz com que sejam distribuídos por, pelo menos, três anfitriões físicos no seu centro de dados. A partir da versão 1.1.0-gke.6, esta funcionalidade é ativada automaticamente para novos clusters e clusters existentes.

Antes de fazer a atualização, certifique-se de que o seu ambiente vSphere cumpre as seguintes condições:

  • O VMware DRS está ativado. O VMware DRS requer a edição vSphere Enterprise Plus. Para saber como ativar o DRS, consulte o artigo Ativar o VMware DRS num cluster

  • O nome de utilizador do vSphere fornecido no seu ficheiro de configuração de credenciais tem a autorização Host.Inventory.EditCluster.

  • Estão disponíveis, pelo menos, três anfitriões físicos.

Se o seu ambiente vSphere não cumprir as condições anteriores, pode continuar a atualizar, mas, para atualizar um cluster de utilizadores de 1.3.x para 1.4.x, tem de desativar os grupos de antiafinidade. Para mais informações, consulte este problema conhecido nas notas de lançamento do Google Distributed Cloud.

Acerca do tempo de inatividade durante as atualizações

Recurso Descrição
Cluster de administrador

Quando um cluster de administrador está inativo, os planos de controlo do cluster de utilizador e as cargas de trabalho nos clusters de utilizador continuam a ser executados, a menos que tenham sido afetados por uma falha que causou o tempo de inatividade.

Plano de controlo do cluster de utilizadores

Normalmente, não deve esperar uma indisponibilidade percetível nos planos de controlo dos clusters de utilizadores. No entanto, as ligações de longa duração ao servidor da API Kubernetes podem falhar e ter de ser restabelecidas. Nesses casos, o autor da chamada da API deve tentar novamente até estabelecer uma ligação. No pior dos casos, pode haver até um minuto de inatividade durante uma atualização.

Nós do cluster de utilizadores

Se uma atualização exigir uma alteração aos nós do cluster de utilizadores, o Google Distributed Cloud recria os nós de forma contínua e reagenda os pods em execução nestes nós. Pode evitar o impacto nas suas cargas de trabalho configurando PodDisruptionBudgets adequados e regras de anti-afinidade.

Volte a criar um ficheiro de informações se estiver em falta

Se o ficheiro de informações de saída da sua estação de trabalho de administração estiver em falta, tem de recriar este ficheiro para poder prosseguir com a atualização. Este ficheiro foi criado quando criou inicialmente a sua estação de trabalho e, se tiver feito uma atualização desde então, foi atualizado com novas informações.

O ficheiro de informações de saída tem este formato:

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

Segue-se um exemplo de um ficheiro de informações de saída:

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

Crie o ficheiro num editor, substituindo os parâmetros adequados. Guarde o ficheiro com um nome de ficheiro igual ao nome da VM no diretório a partir do qual o gkeadm é executado. Por exemplo, se o nome da VM for admin-ws-janedoe, guarde o ficheiro como admin-ws-janedoe.

O que se segue?