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 GKE 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 da versão do GKE em Bare Metal 1.9.0, é 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.

O GKE em Bare Metal oferece suporte ao SELinux apenas nos sistemas RHEL e CentOS.

Fazer upgrade das verificações de simulaçã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ó. O upgrade do cluster não continuará se as verificações de simulação falharem. Para mais informações sobre verificações de simulação, consulte Entender as verificações de simulação.

Verifique se os clusters estão prontos para um upgrade executando a verificação de simulação antes de executar o upgrade. Para mais informações, consulte Verificações de simulação para upgrades.

Número de nós

Se o cluster tiver mais de 51 nós, a operação de upgrade padrão, que usa um cluster de bootstrap, estará suscetível a falhas. As falhas ocorrem devido à quantidade limitada de endereços IP do pod alocados para o cluster de inicialização. O intervalo de endereços IP padrão disponível para pods no cluster de inicialização usa uma máscara de /24 na notação de blocos CIDR.

Há duas soluções alternativas nessa situação:

(Recomendado) Use a sinalização --use-bootstrap=false com o comando bmctl upgrade cluster para realizar um upgrade no local. Essa sinalização faz com que o upgrade ignore o cluster de inicialização e a limitação de endereço do pod. Observe que há um problema conhecido de upgrade no local para os clusters da versão 1.13.0. Se o cluster estiver na versão 1.13.0, consulte o problema conhecido para uma solução alternativa e informações adicionais.
Use a sinalização --bootstrap-cluster-pod-cidr com o comando bmctl upgrade cluster para aumentar a quantidade de endereços IP do pod alocados para o cluster de bootstrap. Por exemplo, ao especificar --bootstrap-cluster-pod-cidr=192.168.122.0/23 pods em execução para a operação de upgrade, é possível usar endereços IP de 192.168.122.0/23 (512 endereços), em vez do CIDR padrão 192.168.122.0/24 (256 endereços). Esses endereços adicionados precisam desbloquear upgrades de clusters com até 52 nós.

No máximo, o número de pods em execução simultaneamente durante um upgrade pode ser cinco vezes o número de nós. Para garantir que o upgrade seja bem-sucedido, especifique um bloco CIDR contendo uma quantidade de endereços IP que sejam cinco vezes o número de nós. Essa sinalização exige endereços IP internos.
Se você não quiser usar nenhuma das opções anteriores, poderá usar a sinalização --skip-bootstrap-cidr-check para ignorar a validação. No entanto, transmitir esse argumento significa que o upgrade pode falhar devido à falta de endereços IP disponíveis no CIDR de pod para o cluster de inicialização.

Upgrades no local para clusters autogerenciados

A partir da versão 1.13.1 dos clusters do GKE 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

O GKE em Bare Metal é compatível com a configuração de até 250 pods no máximo 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 use chmod para conceder permissões de bmctl a todos os usuários:
```
gsutil cp gs://anthos-baremetal-release/bmctl/1.14.11/linux-amd64/bmctl bmctl
chmod a+x bmctl
```

Modifique o arquivo de configuração do cluster para alterar a versão do cluster do GKE em Bare Metal de 1.13.2 para 1.14.11. Confira 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.13.2 to 1.14.11, shown below
  anthosBareMetalVersion: 1.14.11

Ao fazer upgrade de clusters para 1.14.11, é 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.
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.

Upgrades paralelos de nós

Em um upgrade de cluster típico, cada nó de cluster é atualizado sequencialmente, um após o outro. Nesta seção, mostramos como configurar o cluster para que vários nós sejam atualizados em paralelo quando você fizer o upgrade do cluster.

O upgrade de nós em paralelo acelera os upgrades do cluster, especialmente para clusters que têm centenas de nós. Os upgrades paralelos de nós são configurados com base em um pool de nós, e somente os nós em um pool de nós de trabalho podem ser atualizados em paralelo. Só é possível fazer upgrade de um nó em planos de controle ou pools de nós do balanceador de carga de cada vez.

Os upgrades paralelos dos nós de trabalho são um recurso em fase de pré-lançamento. Portanto, não use esse recurso nos clusters de produção.

Como fazer um upgrade paralelo

Para executar um upgrade paralelo de nós em um pool de nós de trabalho, faça o seguinte:

Adicione a anotação preview.baremetal.cluster.gke.io/parallel-upgrade: "enable" ao arquivo de configuração do cluster:

---
gcrKeyPath: /path/to/gcr-sa
gkeConnectAgentServiceAccountKeyPath: /path/to/gke-connect
gkeConnectRegisterServiceAccountKeyPath: /path/to/gke-register
sshPrivateKeyPath: /path/to/private-ssh-key
cloudOperationsServiceAccountKeyPath: /path/to/logging-sa
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/maintenance-mode-deadline-seconds: "180"
    preview.baremetal.cluster.gke.io/parallel-upgrade: "enable"
    ...

Adicione uma seção upgradeStrategy ao manifesto do pool de nós de trabalho. Esse manifesto precisa estar no arquivo de configuração do cluster. Se ele aparecer em um arquivo de manifesto separado, o comando bmctl upgrade cluster não vai atuar nele. Veja um exemplo:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np1
  namespace: cluster-ci-bf8b9aa43c16c47
spec:
  clusterName: ci-bf8b9aa43c16c47
  nodes:
  - address:  10.200.0.7
  - address:  10.200.0.8
  - address:  10.200.0.9
  upgradeStrategy:
    parallelUpgrade:
      concurrentNodes: 5
  
```
Neste exemplo, o valor do campo concurrentNodes é 5, o que significa que cinco nós farão upgrade em paralelo. O valor mínimo e padrão desse campo é 1, e o valor máximo permitido é o número de nós no pool de nós de trabalho. No entanto, recomendamos que você defina esse valor como não superior a 3% do número total de nós no seu cluster. Se o valor de concurrentNodes for muito alto, as cargas de trabalho poderão ser comprometidas durante um upgrade paralelo.
Faça upgrade do cluster conforme descrito na seção anterior Upgrade de clusters administrativos, independentes, híbridos ou de usuário.

Como desativar upgrades paralelos de nós

Para desativar upgrades paralelos de nós, defina a anotação preview.baremetal.cluster.gke.io/parallel-upgrade como disable no arquivo de configuração do cluster.