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:
Edite o arquivo de configuração do cluster para definir
anthosBareMetalVersion
como a versão de destino do upgrade.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.
Faça o download do
bmctl
mais recente pelo bucket do Cloud Storage e usechmod
para conceder permissões debmctl
a todos os usuários:gsutil cp gs://anthos-baremetal-release/bmctl/1.13.10/linux-amd64/bmctl bmctl chmod a+x bmctl
Modifique o arquivo de configuração do cluster para alterar os clusters do Anthos em bare metal da versão
1.12.2
para1.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
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.- 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".
- Faça referência às chaves JSON salvas nos campos
gkeConnectAgentServiceAccountKeyPath
egkeConnectRegisterServiceAccountKeyPath
associados do arquivo de configuração do cluster.
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.