Como fazer upgrade de clusters do Anthos no VMware

Nesta página, explicamos como fazer upgrade de clusters do Anthos no VMware (GKE On-Prem).

Versões de destino

A partir dos clusters do Anthos no VMware versão 1.3.2, é 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.3.2 para 1.3.5 ou da 1.5.2 para 1.6.1.

Se sua versão atual for anterior à 1.3.2, será necessário fazer upgrades sequenciais para alcançar a versão 1.3.2 primeiro. Por exemplo, para fazer upgrade da versão 1.3.0 para 1.3.2, primeiro você precisa fazer upgrade da versão 1.3.0 para 1.3.1 e, em seguida, de 1.3.1 para 1.3.2.

Se estiver fazendo upgrade da versão 1.3.2 ou posterior para uma versão que não faça parte da próxima versão secundária, será necessário fazer upgrade por uma versão de cada versão secundária entre a versão atual e a desejada. Por exemplo, se você estiver fazendo upgrade da versão 1.3.2 para a versão 1.6.1, não será possível fazer upgrade diretamente. Primeiro, faça upgrade da versão 1.3.2 para a versão 1.4.x, em que x representa qualquer versão de patch sob essa versão secundária. Você pode fazer upgrade para a versão 1.5.x e depois para a versão 1.6.1.

Observação: se você estiver usando clusters do Anthos no VMware com o Anthos Service Mesh 1.7 ou posterior, consulte este problema conhecido se quiser fazer upgrade para a versão 1.6.0-1.6.3 ou 1.7.0-1.7.2.

Visão geral do processo de upgrade

1. Faça o download da ferramenta gkeadm. A versão do gkeadm precisa ser igual à versão de destino do upgrade.

2. Use gkeadm para fazer upgrade da estação de trabalho do administrador.

3. Na estação de trabalho do administrador, faça upgrade do cluster de administrador.

4. Na sua estação de trabalho do administrador, faça upgrade dos clusters de usuário.

Política de upgrade

Veja o que é necessário depois de fazer upgrade do cluster de administrador:

• Todos os novos clusters de usuário criados precisam ter a mesma versão do cluster de administrador.

• Se você fizer upgrade de um cluster de usuários existente, precisará fazer upgrade para a mesma versão do cluster de administrador.

• Antes de fazer upgrade do cluster de administrador novamente, você precisa fazer upgrade de todos os clusters de usuário para a mesma versão do cluster de administrador atual.

Como localizar seus arquivos de configuração e informações

Ao criar a estação de trabalho de administrador atual, você preenche um arquivo de configuração da estação de trabalho de administrador que foi gerado por gkeadm create config. O nome padrão deste arquivo é admin-ws-config.yaml.

Quando você criou sua estação de trabalho de administrador atual, gkeadm criou um arquivo de informações para você. O nome padrão desse arquivo é o mesmo nome da estação de trabalho do administrador atual.

Localize o arquivo de configuração da estação de trabalho de administrador e o arquivo de informações. Você precisa deles para realizar as etapas deste guia. Se esses arquivos estiverem no diretório atual e tiverem os nomes padrão, não será necessário especificá-los quando você executar gkeadm upgrade admin-workstation. Se esses arquivos estiverem em outro diretório ou se você tiver alterado os nomes dos arquivos, especifique-os usando as sinalizações --config e --info-file.

Como fazer o upgrade da estação de trabalho de administrador

Para fazer upgrade da estação de trabalho de administrador, primeiro faça o download de uma nova versão da ferramenta gkeadm e use-a para fazer upgrade da configuração da estação de trabalho de administrador. A versão de gkeadm precisa ser compatível com a versão de destino do upgrade.

Como fazer o download de gkeadm

Para fazer o download da versão apropriada do gkeadm, siga as instruções na página Downloads.

Como fazer o upgrade da estação de trabalho de administrador

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

onde:

• [AW_CONFIG_FILE] é o caminho do arquivo de configuração da estação de trabalho do administrador. É possível omitir essa sinalização se o arquivo estiver no diretório atual e tiver o nome admin-ws-config.yaml;

• [INFO_FILE] é o caminho do seu arquivo de informações. Será possível omitir essa sinalização se o arquivo estiver no seu diretório atual. O nome padrão desse arquivo é o mesmo nome da estação de trabalho do administrador.

O comando anterior executa as seguintes tarefas:

• Faça backup de todos os arquivos no diretório inicial da sua estação de trabalho de administrador atual. São eles:

  • Seus clusters do Anthos no arquivo de configuração do VMware. O nome padrão desse arquivo é config.yaml.

  • Os arquivos kubeconfig do cluster de administrador e dos clusters de usuário.

  • O certificado raiz do seu servidor vCenter. Esse arquivo precisa ter permissão de leitura e gravação de proprietário.

  • O arquivo de chave JSON para sua conta de serviço de acesso a componentes. Esse arquivo precisa ter permissão de leitura e gravação de proprietário.

  • Os arquivos de chave JSON para suas contas de serviço de conexão, registro e agente de monitoramento.

• Crie uma nova estação de trabalho de administrador e copie todos os arquivos armazenados em backup na nova estação de trabalho de administrador.

• Exclua a estação de trabalho de administrador antiga.

Como atualizar a imagem do SO do nó e as imagens do Docker

Na nova estação de trabalho de administrador, execute o seguinte comando:

gkectl prepare --config [ADMIN_CONFIG] [FLAGS]

onde:

• [ADMIN_CONFIG] é o caminho do arquivo de configuração do cluster de administrador.

• [FLAGS] é um conjunto opcional de sinalizações. Por exemplo, inclua a sinalização --skip-validation-infra para pular a verificação da infraestrutura do vSphere.

O comando anterior executa as seguintes tarefas:

• Se necessário, copie uma nova imagem do SO do nó para o ambiente vSphere e marque a imagem do SO como um modelo.

• Se você tiver configurado um registro particular do Docker, envie as imagens atualizadas do Docker para o registro particular do Docker.

Verificar se há endereços IP suficientes disponíveis

Siga as etapas desta seção na nova estação de trabalho do administrador.

Antes de fazer upgrade, verifique se você tem endereços IP suficientes disponíveis para os clusters.

DHCP

Quando você faz upgrade do cluster de administrador, os clusters do Anthos no VMware criam um nó temporário no cluster de administrador. Quando você faz upgrade de um cluster de usuário, os clusters do Anthos no VMware criam um nó temporário nesse cluster de usuário. O objetivo do nó temporário é garantir disponibilidade sem interrupções. Antes de fazer upgrade de um cluster, verifique se o servidor DHCP pode fornecer endereços IP suficientes para o nó temporário. Para mais informações, consulte Endereços IP necessários para clusters de administrador e usuário.

IPs estáticos

Quando você faz upgrade do cluster de administrador, os clusters do Anthos no VMware criam um nó temporário no cluster de administrador. Quando você faz upgrade de um cluster de usuário, os clusters do Anthos no VMware criam um nó temporário nesse cluster de usuário. O objetivo do nó temporário é garantir disponibilidade sem interrupções. Antes de fazer upgrade de um cluster, verifique se você reservou endereços IP suficientes. Para cada cluster, você precisa reservar pelo menos um endereço IP a mais do que o número de nós de cluster. Para mais informações, consulte   Como configurar endereços IP estáticos.

Determine o número de nós no cluster de administrador:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

[ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de administrador.

Em seguida, veja os endereços reservados para o cluster de administrador:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

Na saída, no campo reservedAddresses, é possível ver o número de endereços IP reservados para os nós do cluster de administrador. Por exemplo, a saída a seguir mostra que há cinco endereços IP reservados para os nós do cluster de administrador:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

O número de endereços IP reservados precisa ser pelo menos um a mais do que o número de nós no cluster de administrador. Se esse não for o caso, será possível reservar um endereço extra editando o objeto Cluster.

Abra o objeto Cluster para edição:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

Em reservedAddresses, adicione mais um bloco que tenha gateway, hostname, ip e netmask.

Para determinar o número de nós em um cluster de usuário:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

[USER_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de usuário.

Para ver os endereços reservados para um cluster de usuário:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

onde:

• [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de administrador;

• [USER_CLUSTER_NAME] é o nome do cluster de usuário.

O número de endereços IP reservados precisa ser pelo menos uma unidade a mais do que a quantidade de nós no cluster do usuário. Se esse não for o caso, siga estas etapas:

• Abra o arquivo de bloco de IPs do cluster de usuário para edição.

• Adicione outros endereços IP ao bloco e feche o arquivo.

• Atualize o cluster de usuário:

  gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \
    --config [USER_CLUSTER_CONFIG]
  

(Opcional) Como desativar novos recursos do vSphere

Um novo cluster Anthos na versão VMware pode incluir novos recursos ou suporte para recursos específicos do VMware vSphere. Em alguns casos, o upgrade para clusters do Anthos na versão do VMware ativa automaticamente esses recursos. Você aprende sobre novos recursos nos clusters do Anthos nas Notas da versão do VMware. Às vezes, os novos recursos aparecem nos clusters do Anthos no arquivo de configuração da VMware.

Se você precisar desativar um novo recurso ativado automaticamente em uma nova versão dos clusters do Anthos na versão do VMware e orientado pelo arquivo de configuração, execute as etapas a seguir antes de fazer upgrade do cluster:

1. Na estação de trabalho de administrador atualizada, crie um novo arquivo de configuração com um nome diferente do arquivo de configuração atual:

   gkectl create-config --config [CONFIG_NAME]

2. Abra o novo arquivo de configuração e anote o campo do recurso. Feche o arquivo.

3. Abra o arquivo de configuração atual e adicione o campo do novo recurso. Defina o valor do campo como false ou equivalente.

4. Salve o arquivo de configuração.

Consulte as notas de lançamento antes de fazer upgrade dos clusters. Não é possível alterar declarativamente a configuração de um cluster existente depois de atualizá-la.

Como fazer upgrade do cluster de administrador

Observação: antes de iniciar esse upgrade, determine se os certificados estão atualizados e renove-os, se necessário.

Siga as etapas desta seção na nova estação de trabalho do administrador.

Lembre-se de que a versão de destino do upgrade precisa ser igual à versão gkeadm.

Execute este comando:

gkectl upgrade admin \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [ADMIN_CLUSTER_CONFIG_FILE] \
    [FLAGS]

onde:

• [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de administrador;

• [ADMIN_CLUSTER_CONFIG_FILE] é o caminho do arquivo de configuração do cluster de administrador.

• [FLAGS] é um conjunto opcional de sinalizações. Por exemplo, inclua a sinalização --skip-validation-infra para pular a verificação da infraestrutura do vSphere.

Observação: esse procedimento não faz upgrade de todos os nós no cluster de administrador, porque alguns deles são nós do plano de controle para os clusters de usuário. Eles serão atualizados quando você fizer upgrade dos clusters de usuário.

Observação: o comando gkectl upgrade executa verificações de simulação. Se elas falharem, o comando será bloqueado. Corrija as falhas ou use a sinalização --skip-preflight-check-blocking com o comando para desbloqueá-la.

Como fazer upgrade de um cluster de usuário

Siga as etapas desta seção na nova estação de trabalho do administrador.

Lembre-se de que a versão de destino do upgrade precisa ser igual à versão gkeadm.

gkectl

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    [FLAGS]

onde:

• [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de administrador.

• [USER_CLUSTER_CONFIG_FILE] é o caminho do arquivo de configuração do cluster de usuário.

• [FLAGS] é um conjunto opcional de sinalizações. Por exemplo, inclua a sinalização --skip-validation-infra para pular a verificação da infraestrutura do vSphere.

Console

É possível registrar seus clusters de usuário com o console do Google Cloud durante a instalação ou depois de criá-los. É possível visualizar e fazer login nos clusters registrados do Anthos e nos clusters do GKE no console do Google Cloud.

Quando um upgrade fica disponível para um cluster de usuário, uma notificação é exibida no console do Google Cloud. Clique na notificação para exibir uma lista de versões disponíveis e um comando gkectl que pode ser executado para fazer upgrade do cluster:

1. Acesse a página do Kubernetes Engine no console do Google Cloud.

   Acessar a página do Google Kubernetes Engine

2. Na coluna Notificações do cluster de usuário, clique em Upgrade disponível, se houver.

3. Copie o comando gkectl upgrade cluster.

4. Na estação de trabalho de administrador, execute o comando gkectl upgrade cluster, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de administrador, [CLUSTER_NAME] é o nome do cluster de usuário que você está fazendo upgrade e [USER_CLUSTER_CONFIG_FILE] é o caminho do arquivo de configuração do cluster de usuário.

Observação: o comando gkectl upgrade executa verificações de simulação. Se as verificações de simulação falharem, o comando será bloqueado. Corrija as falhas ou use a sinalização --skip-preflight-check-blocking com o comando.

Como retomar um upgrade

Se um upgrade de cluster de usuário for interrompido, será possível retomá-lo executando o mesmo comando de upgrade com a sinalização --skip-validation-all:

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    --cluster-name [CLUSTER_NAME] \
    --skip-validation-all

Como retomar um upgrade de cluster de administrador

Não interrompa um upgrade do cluster de administrador. Nem sempre é possível retomar os upgrades de cluster de administrador. Se um upgrade de cluster de administrador for interrompido por qualquer motivo, entre em contato com o suporte para receber ajuda.

Como criar um novo cluster de usuários após um upgrade

Depois de fazer upgrade da estação de trabalho de administrador e do cluster de administrador, todos os novos clusters de usuário criados precisam ter a mesma versão que a versão de destino do upgrade.

Regras do DR da VMware

Os clusters do Anthos no VMware criam automaticamente regras de antiafinidade Distributed Resource Scheduler (DRS) do VMware para os nós do cluster de usuário, fazendo com que eles sejam distribuídos em pelo menos três hosts físicos no data center. Esse recurso é ativado automaticamente para clusters novos e atuais.

Antes de fazer upgrade, verifique se o ambiente vSphere atende às condições a seguir:

• O VMware DRS está ativado. O VMware DRS requer a edição de licença do vSphere Enterprise Plus. Para saber como ativar o DRS, consulte Como ativar o VMware DRS em um cluster.
• A conta de usuário do vSphere fornecida no campo vcenter tem a permissão Host.Inventory.EditCluster.
• Há pelo menos três hosts físicos disponíveis.

Caso seu ambiente do vSphere não atenda às condições anteriores, você ainda pode fazer upgrade, mas, para atualizar um cluster de usuário de 1.3.x para 1.4.x, você precisará desativar grupos antiafinidade. Para mais informações, consulte as notas da versão 1.4.0.

inatividade

Sobre a inatividade durante upgrades

Recurso	Descrição
Cluster de administrador	Quando um cluster de administrador fica inativo, os planos de controle do cluster de usuário e as cargas de trabalho em clusters de usuário continuam em execução, a menos que tenham sido afetados por uma falha que causou a inatividade.
Plano de controle do cluster de usuário	Normalmente, não há inatividade perceptível nos planos de controle do cluster de usuário. No entanto, conexões de longa duração com o servidor da API Kubernetes podem falhar e precisam ser restabelecidas. Nesses casos, o autor da chamada da API precisa tentar novamente até estabelecer uma conexão. No pior dos casos, pode haver até um minuto de inatividade durante um upgrade. Observação: se os nós do cluster de usuário não conseguirem alcançar o plano de controle do usuário durante o upgrade, novas cargas de trabalho não serão programadas para o cluster. As cargas de trabalho já existentes não são afetadas.
Nós do cluster de usuário	Se um upgrade exigir uma alteração nos nós de cluster do usuário, os clusters do Anthos no VMware recriarão os nós em um ritmo contínuo e reprogramarão os pods em execução nesses nós. É possível evitar o impacto nas suas cargas de trabalho configurando PodDisruptionBudgets e regras antiafinidade apropriados.

Problemas conhecidos

Consulte Problemas conhecidos.

Solução de problemas

Consulte Solução de problemas na criação e no upgrade de clusters.