Fazer upgrade de clusters

Quando você instala uma nova versão de bmctl, é possível fazer upgrade dos clusters atuais que foram criados com uma versão anterior. O upgrade de um cluster para a versão mais recente do Clusters do Anthos em bare metal disponibiliza recursos e correções no cluster. Isso também garante que o cluster permaneça compatível. É possível fazer upgrade de clusters de administrador, híbridos, autônomos ou de usuários com o comando bmctl upgrade cluster.

Considerações sobre upgrades

As seções a seguir descrevem as regras e práticas recomendadas a serem consideradas antes de fazer upgrade de um cluster.

Prévia dos recursos

Os recursos de Visualização estão sujeitos a alterações e são fornecidos apenas para fins de teste e avaliação. Não use os recursos de Visualização nos clusters de produção. Não podemos garantir que os clusters que usam recursos de Visualização podem ser atualizados. Em alguns casos, bloqueamos explicitamente os upgrades de clusters que usam recursos da Visualização.

Para informações sobre alterações interruptivas relacionadas a upgrade, consulte as notas da versão.

SELinux

Se você quiser ativar o SELinux para proteger seus contêineres, verifique se o SELinux está ativado no modo Enforced em todas as máquinas host. A partir dos clusters do Anthos na versão Bare Metal 1.9.0 ou posterior, é possível ativar ou desativar o SELinux antes ou depois da criação do cluster ou dos upgrades do cluster. O SELinux é ativado por padrão no Red Hat Enterprise Linux (RHEL) e no CentOS. Se o SELinux estiver desativado em suas máquinas host ou se você não tiver certeza, consulte Como proteger seus contêineres usando o SELinux para instruções sobre como ativá-lo.

Os clusters do Anthos em bare metal são compatíveis com o SELinux apenas em sistemas RHEL e CentOS.

Upgrades de regras de versão

Ao fazer o download e instalar uma nova versão de bmctl, será possível fazer upgrade dos clusters de administrador, híbridos, independentes e de usuário criados ou atualizados com uma versão anterior de bmctl. Não é possível fazer downgrade dos clusters para uma versão anterior.

Só é possível fazer upgrade de um cluster para uma versão que corresponda à de bmctl que você está usando. Ou seja, se você estiver usando a versão 1.13.10 de bmctl, será possível fazer upgrade de um cluster apenas para a versão 1.13.10.

Upgrades de versão de patchs

Para uma determinada versão secundária, é possível fazer upgrade para qualquer versão de patch superior. Ou seja, é possível fazer upgrade de um cluster de versão 1.13.X para a versão 1.13.Y, desde que Y seja maior que X. Por exemplo, é possível fazer upgrade de 1.12.0 para 1.12.1, bem como de 1.12.1 para 1.12.3. Recomendamos que você faça o upgrade para a versão de patch mais recente sempre que possível para garantir que os clusters tenham as correções de segurança mais recentes.

Upgrades de versão secundária

É possível fazer upgrade de clusters de uma versão secundária para a próxima, independentemente da versão do patch. Ou seja, é possível fazer upgrade de 1.N.X para 1.N+1.Y, em que 1.N.X é a versão do seu cluster, e N+1 é a próxima versão secundária disponível. As versões de patch, X e Y, não afetam a lógica de upgrade neste caso. Por exemplo, é possível fazer upgrade de 1.12.3 para 1.13.10.

Não é possível pular versões secundárias ao fazer upgrade de clusters. Se você tentar fazer upgrade para uma versão secundária que seja duas ou mais versões secundárias mais recentes que a versão do cluster, bmctl emitirá um erro. Por exemplo, não é possível fazer upgrade de um cluster da versão 1.11.0 para a versão 1.13.0.

Um cluster de administrador pode gerenciar clusters de usuário que estão em uma versão secundária igual ou anterior. Os clusters de usuário gerenciados não podem ser mais que uma versão secundária anterior ao cluster de administrador. Portanto, antes de fazer upgrade de um cluster de administrador para uma nova versão secundária, verifique se todos os clusters de usuário gerenciados estão na mesma versão secundária que o cluster de administrador.

Os exemplos nas instruções de upgrade a seguir mostram o processo de upgrade da versão 1.12.2 para clusters do Anthos em bare metal 1.13.10.

Upgrades no local para clusters autogerenciados

A partir da versão 1.13.1 dos clusters do Anthos em Bare Metal, é possível realizar upgrades no local em clusters de administradores, híbridos e autônomos. Um upgrade no local elimina a necessidade de um cluster de inicialização, o que simplifica o processo e reduz os requisitos de recursos para um upgrade. Antes de realizar um upgrade no local no cluster autogerenciado, ele precisa estar na versão 1.13.0 ou mais recente.

Para realizar um upgrade no local, é possível usar bmctl ou kubectl:

bmctl

O processo de upgrade é idêntico ao processo de upgrade padrão, exceto pelo comando bmctl upgrade cluster.

  • Para iniciar o upgrade no local, use a sinalização --use-bootstrap=false com o comando de upgrade:

    bmctl upgrade cluster -c CLUSTER_NAME --use-bootstrap=false \
    --kubeconfig ADMIN_KUBECONFIG

    Substitua:

    • CLUSTER_NAME: o nome do cluster a se fazer upgrade.
    • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

Assim como no processo de upgrade padrão, as verificações de simulação são executadas como parte do upgrade do cluster para validar o status do cluster e a integridade do nó. Se as verificações de simulação falharem, o upgrade do cluster será interrompido. Para solucionar falhas, examine o cluster e os registros relacionados, já que nenhum cluster de inicialização foi criado.

kubectl

Para fazer upgrade de um cluster autogerenciado com kubectl, execute as seguintes etapas:

  1. Edite o arquivo de configuração do cluster para definir anthosBareMetalVersion como a versão de destino do upgrade.

  2. Para iniciar o upgrade, execute o seguinte comando:

    kubectl apply -f CLUSTER_CONFIG_PATH

    Substitua CLUSTER_CONFIG_PATH pelo caminho para o arquivo de configuração do cluster de administrador.

Assim como no processo de upgrade padrão, as verificações de simulação são executadas como parte do upgrade do cluster para validar o status do cluster e a integridade do nó. Se as verificações de simulação falharem, o upgrade do cluster será interrompido. Para resolver problemas de falhas, examine o cluster e os registros relacionados, já que nenhum cluster de bootstrap foi criado.

Densidade do pod

Os clusters do Anthos em bare metal são compatíveis com a configuração de até 250 pods máximos por nó com nodeConfig.PodDensity.MaxPodsPerNode. É possível configurar a densidade do pod apenas durante a criação do cluster. Não é possível atualizar as configurações de densidade de pods para clusters.

Problemas conhecidos

Para informações sobre possíveis problemas relacionados a upgrades de cluster, consulte Como fazer upgrade de clusters do Anthos em Bare Metal na página "Problemas conhecidos".

Como fazer upgrade de clusters de administrador, autônomos, híbridos ou de usuários

Ao fazer o download e instalar uma nova versão do bmctl, é possível fazer o upgrade dos clusters de administrador, híbridos, autônomos e de usuários criados com uma versão anterior. Para uma determinada versão de bmctl, um cluster só pode ser atualizado para a mesma versão.

Primeiro, faça o download do bmctl mais recente, modifique os arquivos de configuração de cluster apropriados e emita o comando bmctl upgrade cluster para concluir o upgrade.

  1. Faça o download do bmctl mais recente pelo bucket do Cloud Storage e use chmod para conceder permissões de bmctl a todos os usuários:

    gsutil cp gs://anthos-baremetal-release/bmctl/1.13.10/linux-amd64/bmctl bmctl
chmod a+x bmctl

  2. Modifique o arquivo de configuração do cluster para alterar os clusters do Anthos em bare metal da versão 1.12.2 para 1.13.10. Veja a seguir um exemplo de uma configuração de cluster de administrador:

    ---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: admin
  # Anthos cluster version.
  # Change the following line from 1.12.2 to 1.13.10, shown below
  anthosBareMetalVersion: 1.13.10

  3. Ao fazer upgrade de clusters para 1.13.10, é preciso registrar os clusters com o Connect na frota do projeto, caso eles ainda não tenham sido registrados.

    1. Crie contas de serviço manualmente e recupere os arquivos de chave JSON, conforme descrito em Como configurar contas de serviço para uso com o Connect na página "Como ativar serviços e contas de serviço do Google".
    2. Faça referência às chaves JSON salvas nos campos gkeConnectAgentServiceAccountKeyPath e gkeConnectRegisterServiceAccountKeyPath associados do arquivo de configuração do cluster.

  4. Use o comando bmctl upgrade cluster para concluir o upgrade:

    bmctl upgrade cluster -c CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Substitua:

    • CLUSTER_NAME: o nome do cluster a se fazer upgrade.
    • ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.

    As verificações de simulação são executadas como parte do upgrade do cluster para validar o status do cluster e a integridade do nó. O upgrade do cluster não continuará se as verificações de simulação falharem.