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

Visão geral do processo de upgrade

É 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.7.0 para 1.7.3 ou de 1.7.1 para 1.8.0.

Se você estiver fazendo upgrade para uma versão que não faz parte da próxima versão secundária, será necessário atualizar uma versão de cada versão secundária entre a versão atual e a desejada. Por exemplo, se você estiver fazendo upgrade da versão 1.6.2 para a versão 1.8.0, não será possível fazer upgrade diretamente. Primeiro, faça o upgrade da versão 1.6.2 para a versão 1.7.x e, em seguida, faça o upgrade para a versão 1.8.0.

Se você estiver fazendo upgrade de um cluster de usuário que tenha a Entrada ativado da versão 1.7 para a 1.8, consulte Migração da Entrada.

Primeiro, faça upgrade da estação de trabalho do administrador, depois dos clusters de usuário e, por último, do cluster de administrador. Não é necessário fazer o upgrade do cluster de administrador logo após o upgrade dos clusters de usuários se quiser manter o cluster de administrador na versão atual.

1. Faça o download da ferramenta gkeadm. A versão do gkeadm precisa ser igual à versão de destino do upgrade.
2. Faça upgrade da estação de trabalho do administrador.
3. Na sua estação de trabalho do administrador, faça upgrade dos clusters de usuário.
4. Na estação de trabalho do administrador, faça upgrade do cluster de administrador.

Exemplo de um processo de upgrade recomendado da versão 1.7.x para a versão 1.8.x

Suponha que sua estação de trabalho de administrador, o cluster de administrador e os clusters de usuário usem a versão 1.7.x no momento e que você quer fazer upgrade dos clusters de administrador e de usuário para a versão 1.8.x. Se você seguir um caminho de upgrade como este a seguir, use um cluster Canary para teste antes de continuar para reduzir o risco de interrupção.

Veja a seguir uma visão geral detalhada de um processo de upgrade recomendado. Antes de começar, crie um cluster de usuário Canary que use 1.7.x, se ainda não tiver feito isso.

1. Teste a versão 1.8.x em um cluster Canary.
   • Faça upgrade da estação de trabalho do administrador para a versão 1.8.x.
   • Execute o comando gkectl prepare, conforme descrito posteriormente, para configurar o upgrade.
     • Faça upgrade do cluster de usuários do Canary para a versão 1.8.x.
2. Atualize todos os clusters de usuário de produção para a versão 1.8.x quando tiver certeza da versão 1.8.x.
3. Faça upgrade do cluster de administrador para a versão 1.8.x.

Como localizar os arquivos de configuração e informações para se preparar para o upgrade

Antes de criar sua estação de trabalho de administrador, você preencheu 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.

Além disso, 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 ao executar os comandos de upgrade. Se esses arquivos estiverem em outro diretório ou se você tiver alterado os nomes dos arquivos, especifique-os utilizando as sinalizações --config e --info-file.

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

Verifique se gkectl e os clusters estão no nível de versão apropriado para um upgrade e se você fez o download do pacote apropriado.

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

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

em que:

• [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.

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. É possível reservar outros IPs conforme necessário, conforme descrito para cada um dos IPs DHCP e estáticos.

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   os endereços IP necessários para os clusters de administrador e de 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.

Para adicionar endereços IP ao cluster de administrador na versão 1.7:

Primeiro, edite o arquivo de bloco de IP, conforme mostrado neste exemplo.

blocks:
- netmask: "255.255.252.0"
  ips:
  - ip: 172.16.20.10
    hostname: admin-host1
  - ip: 172.16.20.11
    hostname: admin-host2
  # Newly-added IPs.
  - ip: 172.16.20.12
    hostname: admin-host3

Em seguida, execute este comando para atualizar a configuração.

gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]

• [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig.

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

Não é possível remover endereços IP, apenas adicioná-los.

Nas versões anteriores à 1.7, é possível editar um endereço adicional editando o objeto Cluster diretamente.

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.

Importante: a partir da versão 1.5.0, o mesmo procedimento não funciona para clusters de usuários, e é necessário usar gkectl update cluster para cada um deles.

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, abra o arquivo de bloco IP do cluster do usuário para edição:

• Se algum dos endereços reservados para um cluster de usuário estiver incluído no arquivo de bloqueio de IP, adicione-o ao bloco correspondente com base em netmask e gateway.

• Adicione quantos endereços IP estáticos adicionais ao bloco correspondente forem necessários e execute gkectl update cluster.

Instalar o pacote para upgrade

Para disponibilizar uma versão para criação ou upgrade do cluster, instale o pacote correspondente. Siga estas etapas para instalar um pacote para TARGET_VERSION, que é o número da versão para que você quer fazer upgrade.

Para verificar as versões atuais de gkectl e de cluster, execute este comando. Use a sinalização --details/-d para informações mais detalhadas.

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Veja um exemplo de saída:

gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0
current admin cluster version: 1.6.2-gke.0
current user cluster versions (VERSION: CLUSTER_NAMES):
- 1.6.2-gke.0: user-cluster1
available admin cluster versions:
- 1.6.2-gke.0
available user cluster versions:
- 1.6.2-gke.0
- 1.7.2-gke.2
Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters.
Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.

Com base no resultado, procure os seguintes problemas e corrija-os conforme necessário.

• Se a versão gkectl for anterior à 1.7, o novo fluxo de upgrade não estará disponível diretamente. Siga o fluxo de upgrade original para fazer upgrade de todos os clusters para a versão 1.6 e, em seguida, faça upgrade da estação de trabalho de administrador para 1.7 para começar a usar o novo fluxo de upgrade.

• Se a versão atual do cluster de administrador for mais de uma versão secundária inferior a TARGET_VERSION, faça upgrade de todos os clusters para uma versão secundária à TARGET_VERSION.

• Se a versão do gkectl for inferior à TARGET_VERSION, faça o upgrade da estação de trabalho do administrador para a TARGET_VERSION, seguindo as instruções.

Depois de determinar que gkectl e as versões de cluster são apropriadas para um upgrade, faça o download do pacote.

Verifique se o tarball 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 de administrador, faça o download dele.

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

Instale o pacote.

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

em que:

• [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig. É possível omitir essa sinalização se o arquivo estiver no diretório atual e tiver o nome kubeconfig.

Observação: por padrão, é feito o download do pacote normal em vez do pacote completo. O pacote completo contém todas as imagens de contêiner e de VM, enquanto o pacote normal faz o download das imagens do contêiner e da VM do Google Cloud Platform para a estação de trabalho do administrador durante a instalação. Para usar o pacote completo, defina o caminho do pacote no comando de instalação como gke-onprem-vsphere-{TARGET_VERSION}-full.tgz.

Liste as versões de cluster disponíveis e verifique se a versão de destino está incluída nas versões disponíveis do cluster de usuário.

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Agora você pode criar um cluster de usuário na versão de destino ou fazer upgrade de um cluster de usuário para a versão de destino.

Como fazer upgrade de um cluster de usuário

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

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.

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

em que:

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

• [USER_CLUSTER_CONFIG_FILE] são os clusters do Anthos no arquivo de configuração do cluster de usuário da VMware na nova estação de trabalho 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: na versão 1.8 dos clusters do Anthos no VMware (GKE no local), o mecanismo de entrada mudou substancialmente em relação às versões anteriores. Para fazer upgrade de um cluster de usuário 1.7 que tenha a entrada ativada, é necessário converter para o mecanismo de entrada. Para mais informações, consulte Migração de entrada.

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] \
--skip-validation-all

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. Verifique se gkectl e os clusters estão no nível de versão apropriado para o upgrade e se você fez o download do pacote apropriado.

A versão de destino do upgrade não pode ser superior à versão do gkectl e no máximo uma versão secundária anterior à versão do gkectl. Assim, se a versão do gkectl for 1.7, a versão de destino do upgrade poderá ser 1.6.x para 1.7. O cluster de administrador só pode ser atualizado para uma versão secundária quando todos os clusters de usuário tiverem sido atualizados para essa versão secundária. Por exemplo, se você tentar fazer upgrade do cluster de administrador para a versão 1.7, enquanto ainda houver clusters de usuário 1.6.2, você verá um erro:

admin cluster can't be upgraded to
"1.7.0-gke.0" yet, because there are still user clusters at "1.6.2-gke.0".

Execute este comando:

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

em que:

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

• [ADMIN_CLUSTER_CONFIG_FILE] são os arquivos de configuração do cluster do Anthos no cluster de administrador do VMware na nova estação de trabalho 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. Use a sinalização --force-upgrade-admin para voltar ao fluxo de upgrade antigo, em que o cluster de administrador é atualizado primeiro e, em seguida, os 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.

Se você fez o download de um pacote completo e executou os comandos gkectl prepare e gkectl upgrade admin, exclua o pacote completo para economizar espaço em disco na estação de trabalho do administrador. Use este comando:

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

Como retomar um upgrade de cluster de administrador

Não interrompa um upgrade do cluster de administrador. Atualmente, os upgrades de cluster de administrador nem sempre são recuperáveis. Se um upgrade de cluster de administrador for interrompido por qualquer motivo, entre em contato com o Suporte do Google para receber ajuda.

Como solucionar problemas do processo de upgrade

Se você tiver um problema ao seguir o processo de upgrade recomendado, siga estas recomendações para resolvê-los. Essas sugestões presumem que você começou com a configuração da versão 1.6.2 e está seguindo o processo de upgrade recomendado.

Como solucionar problemas de upgrade de cluster de usuário

Digamos que você tenha um problema na versão 1.7 ao testar o cluster Canary ou ao fazer upgrade de um cluster de usuário. Você determina com o Suporte do Google que o problema será corrigido em uma versão de patch 1.7.x. Você pode prosseguir da seguinte forma:

1. Continue usando a 1.6.2 para produção.
2. Teste a versão de patch 1.7.x em um cluster Canary quando ela for lançada.
3. Faça upgrade de todos os clusters de usuário de produção para a versão 1.7.x quando você tiver certeza.
4. Faça upgrade do cluster de administrador para a versão 1.7.x.

Como gerenciar uma versão de patch 1.6.x ao testar a 1.7

Suponha que você esteja testando ou migrando para a versão 1.7, mas que ainda não tenha certeza disso, e o cluster de administrador ainda use a versão 1.6.2. Você descobre que uma versão de patch 1.6.x significativa foi lançada. Você ainda pode aproveitar esta versão de patch do 1.6.x enquanto continua fazendo testes com a 1.7. Siga este processo de upgrade:

1. Instale o pacote 1.6.x-gke.0.
2. Atualize todos os clusters de usuário de produção 1.6.2 para a versão 1.6.x.
3. Faça upgrade do cluster de administrador para a versão 1.6.x.

Como solucionar problemas de upgrade de cluster de administrador

Se você encontrar um problema ao fazer upgrade do cluster de administrador, entre em contato com o Suporte do Google para resolvê-lo.

Enquanto isso, com o novo fluxo de upgrade, você ainda pode aproveitar os novos recursos de cluster de usuário sem ser bloqueado pelo upgrade do cluster de administrador, o que permite reduzir a frequência de upgrade do cluster de administrador se quiser. Por exemplo, use o pool de nós do Container-Optimized OS lançado na versão 1.7. O processo de upgrade pode prosseguir da seguinte maneira:

1. Fazer upgrade dos clusters de usuários de produção para a versão 1.7;
2. Manter o cluster de administrador na versão 1.6 e continuar recebendo patches de segurança;
3. Testar o upgrade do cluster de administrador de 1.6 para 1.7 em um ambiente de teste e informar eventuais problemas;
4. Se o problema for resolvido por uma versão de patch 1.7, você pode fazer upgrade do cluster de administrador de produção de 1.6 para esta versão de patch 1.7, se desejar.

Problemas conhecidos

Os seguintes problemas conhecidos afetam o upgrade de clusters.

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

Se você atualizar a estação de trabalho de administrador com o comando gkectl upgrade admin-workstation, o upgrade poderá falhar se o disco de dados estiver quase cheio, porque o sistema tentará fazer o backup da estação de trabalho de administrador atual localmente durante o upgrade para uma nova estação de trabalho de administrador. Se não for possível liberar espaço suficiente no disco de dados, use o comando gkectl upgrade admin-workstation com a sinalização adicional --backup-to-local=false para evitar fazer um backup local da estação de trabalho do administrador atual.

Versão 1.7.0: alterações nas atualizações do Anthos Config Management

Nas versões anteriores à 1.7.0, os clusters do Anthos no VMware incluíam as imagens necessárias para instalar e atualizar o Anthos Config Management. A partir da versão 1.7.0, o software Anthos Config Management não está mais incluído nos pacotes de clusters do Anthos no VMware e é necessário adicioná-lo separadamente. Se você estava usando o Anthos Config Management anteriormente nos clusters, o software não será atualizado.

Observação: se você estiver usando um registro particular com clusters do Anthos no VMware na versão 1.7.0 ou mais recente, será necessário adicionar essas imagens manualmente ao registro particular antes de instalar ou fazer upgrade do Anthos Config Management. Para saber mais, consulte Como atualizar o Anthos Config Management usando um registro particular.

Para mais informações sobre como instalar o Anthos Config Management, consulte Como instalar o Anthos Config Management.

Versão 1.1.0-gke.6, 1.2.0-gke.6: campo stackdriver.proxyconfigsecretname removido

O campo stackdriver.proxyconfigsecretname foi removido na versão 1.1.0-gke.6. Os clusters do Anthos nas verificações de simulação do VMware retornarão um erro se o campo estiver presente no arquivo de configuração.

Para contornar esse problema, antes de fazer upgrade para o 1.2.0-gke.6, exclua o campo proxyconfigsecretname do arquivo de configuração.

O Stackdriver referencia a versão antiga

Antes da versão 1.2.0-gke.6, um problema conhecido impede que o Stackdriver atualize a configuração após os upgrades do cluster. O Stackdriver ainda referencia uma versão antiga, impedindo que o Stackdriver receba os recursos mais recentes do pipeline de telemetria. Esse problema pode dificultar o Suporte do Google para solucionar problemas de clusters.

Depois de fazer upgrade dos clusters para a 1.2.0-gke.6, execute o seguinte comando nos clusters de administrador e de usuário:

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

[KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster.

Interrupção de cargas de trabalho com PodDisruptionBudgets

Atualmente, o upgrade de clusters pode causar interrupção ou inatividade para cargas de trabalho que usam PodDisruptionBudgets (PDBs).

Versão 1.2.0-gke.6: Prometheus e Grafana desativados após o upgrade

Nos clusters do usuário, o Prometheus e o Grafana são desativados automaticamente durante o upgrade. No entanto, os dados de configuração e métricas não são perdidos. Nos clusters de administrador, o Prometheus e o Grafana permanecem ativados.

Para instruções, consulte os clusters do Anthos nas notas da versão do VMware.

Versão 1.1.2-gke.0: os nós de cluster de usuário excluídos não são removidos do armazenamento de dados vSAN

Para instruções, consulte os clusters do Anthos nas notas da versão do VMware.

Versão 1.1.1-gke.2: o disco de dados da pasta de armazenamento de dados vSAN pode ser excluído

Se você usa um armazenamento de dados vSAN, é preciso criar uma pasta para salvar o VMDK. Um problema conhecido exige que você forneça o caminho do identificador universal exclusivo (UUID, na sigla em inglês) da pasta, em vez do caminho do arquivo, para vcenter.datadisk. Essa incompatibilidade pode causar falhas nos upgrades.

Para instruções, consulte os clusters do Anthos nas notas da versão do VMware.

Como fazer upgrade da versão 1.0.2-gke.3 para a versão 1.1.0-gke.6: problema do OIDC

Os clusters da versão 1.0.11, 1.0.1-gke.5 e 1.0.2-gke.3 com o OpenID Connect (OIDC) configurado não podem ser atualizados para a versão 1.1.0-gke.6. Esse problema foi corrigido na versão 1.1.1-gke.2.

Se você tiver configurado um cluster da versão 1.0.11, 1.0.1-gke.5 ou 1.0.2-gke.3 com OIDC durante a instalação, não será possível fazer upgrade. Em vez disso, crie novos clusters.

Como fazer upgrade da versão 1.0.2-gke.3 para a versão 1.0.11

A versão 1.0.2-gke.3 introduz os campos OIDC (usercluster.oidc) a seguir. Esses campos permitem fazer login em um cluster do Console do Cloud:

• usercluster.oidc.kubectlredirecturl
• usercluster.oidc.clientsecret
• usercluster.oidc.usehttpproxy

Se você quiser usar o OIDC, o campo clientsecret será obrigatório mesmo se você não quiser fazer login em um cluster do console do Cloud. Para usar o OIDC, talvez seja necessário fornecer um valor do marcador para clientsecret:

oidc:
  clientsecret: "secret"

Falha no processo de upgrade dos nós

Se você tiver objetos PodDisruptionBudget configurados que não podem permitir outras interrupções, o upgrade dos nós poderá falhar no upgrade para a versão do plano de controle após várias tentativas. Para evitar essa falha, recomendamos que você escalone verticalmente Deployment ou HorizontalPodAutoscaler para permitir que o nó seja drenado enquanto respeita a configuração 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}'

Apêndice

Sobre as regras do VMware DRS ativadas na versão 1.1.0-gke.6

A partir da versão 1.1.0-gke.6, os clusters do Anthos na VMware cria automaticamente regras de antiafinidade do VMware Distributed Resource Scheduler (DRS) para os nós do cluster de usuário, fazendo com que eles sejam distribuídos por pelo menos três hosts físicos no seu data center (link em inglês). A partir da versão 1.1.0-gke.6, 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.

• O nome de usuário do vSphere fornecido no arquivo de confirmação de credenciais 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 este problema conhecido nas notas da versão sobre os clusters do Anthos no VMware.

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.