Atualização ou substituição de nós de trabalho da VPC que utilizam a Base de Dados d OpenShift

Nuvem Privada Virtual

Para clusters de VPC com uma solução de armazenamento como o OpenShift Data Foundation, é necessário isolar, esvaziar e atualizar cada nó de trabalho sequencialmente. Para nós de trabalho em bare metal, agora é possível usar o comando worker reload em vez de worker replace``. Se você implantou o Data Foundation d OpenShift em um subconjunto de nós de trabalho do seu cluster, após atualizar o nó de trabalho, será necessário editar o recurso ocscluster para incluir o novo nó de trabalho.

O tutorial a seguir aborda as atualizações principais e secundárias e as atualizações do nó de trabalho.

Grande atualização: Conclua as etapas com esse rótulo para aplicar uma atualização principal; por exemplo, se você estiver atualizando seus nós do trabalhador para uma nova versão principal, como de 4.11 para 4.12 e também OpenShift Data Foundation de 4.11 para 4.12.
Pequena atualização: Conclua as etapas com esse rótulo para aplicar uma atualização de correção, por exemplo se você estiver atualizando de 4.12.15_1542_openshift para 4.12.16_1544_openshift enquanto mantém o OpenShift Data Foundation na versão 4.12. Você deve repetir essas etapas para cada nó que deseja atualizar.
Substituição de funcionário: Conclua as etapas com essas etapas de rótulo se você estiver substituindo um nó do trabalhador na mesma versão de correção Você deve repetir essas etapas para cada nó que deseja substituir.

Pular versões durante uma atualização, como de 4.8 para não 4.12 é suportado.

Efetue login na sua conta. If applicable, target the appropriate resource group. Configure o contexto para o seu cluster.

Antes de atualizar os nós do trabalhador, certise-se de fazer backup de seus dados do app. Também, planeje a conclusão das etapas a seguir para um nó do trabalhador de cada vez. Repita as etapas para cada nó do trabalhador que deseja atualizar.

Verifique o status do seu cluster de armazenamento

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Liste os pods executando o comando a seguir. Verifique se todos os pods no namespace openshift-storage estão em um bom estado. Aborde todos os pods que não estejam no estado "Em execução" ou "Concluído".
```
	oc get pods -n openshift-storage
```

Execute o comando a seguir e verifique se o endereço Phase de ocs-storagecluster é Ready.

	oc get storagecluster -n openshift-storage

Exemplo de saída

	NAME                 AGE     PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   3m49s   Ready              2025-04-06T09:37:49Z   4.16.9

Verifique o estado do armazenamento Ceph executando o comando a seguir. Verifique se a saúde é HEALTH_OK, se todos os OSDs são up e IN e se todos os pgs são active+clean. Se alguma dessas verificações falhar, abra um caso de suporte. Nos detalhes do caso, certifique-se de incluir todos os arquivos de registro, mensagens de erro ou saídas de comando relevantes. Resolva todos os problemas antes de continuar.

	oc rsh -n openshift-storage $(oc get pods -n openshift-storage -o name -l app=rook-ceph-operator) ceph status -c /var/lib/rook/openshift-storage/openshift-storage.config

Exemplo de saída

	health: HEALTH_OK  # Verify health is HEALTH_OK
	services:
		mon: 3 daemons, quorum a,b,c (age 3h)
		mgr: a(active, since 6h)
		mds: ocs-storagecluster-cephfilesystem:1 {0=ocs-storagecluster-cephfilesystem-b=up:active} 1 up:standby-replay
		osd: 27 osds: 27 up (since 2h), 27 in (since 111m) # Verify OSDs are “up” and “in”
		rgw: 2 daemons active (ocs.storagecluster.cephobjectstore.a, ocs.storagecluster.cephobjectstore.b)
	data:
		pools:   10 pools, 1136 pgs
		objects: 5.50M objects, 3.3 TiB
		usage:   9.9 TiB used, 43 TiB / 53 TiB avail
		pgs:     1136 active+clean   # Verify psgs are active+clean
	io:
		client:   93 KiB/s rd, 2.0 MiB/s wr, 5 op/s rd, 29 op/s wr

Repita essas verificações de integridade antes de repetir o procedimento de atualização para nós adicionais. A desativação de mais de um pod OSD ao mesmo tempo pode comprometer os dados do usuário.

Atualizar o cluster principal

Grande atualização

Se você estiver atualizando seus nós do trabalhador para uma nova versão principal, como de 4.11 para 4.12, atualize o cluster mestre primeiro.

	ibmcloud oc cluster master update --cluster CLUSTER [--version MAJOR.MINOR.PATCH] [--force-update] [-f] [-q]

Exemplo de comando:

	ibmcloud oc cluster master update --cluster mycluster --version 4.21.27 --force-update

Aguarde até que a atualização principal seja concluída

Decida quais nós de armazenamento você deseja atualizar ou substituir

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Liste seus nós de trabalho usando o comando oc get nodes e determine quais nós de armazenamento você deseja atualizar.

	oc get nodes

Exemplo de saída

	NAME           STATUS   ROLES           AGE    VERSION
	10.241.0.4     Ready    master,worker   106s   v1.21.6+4b61f94
	10.241.128.4   Ready    master,worker   22d    v1.21.6+bb8d50a
	10.241.64.4    Ready    master,worker   22d    v1.21.6+bb8d50a

Certifique-se de que o cluster de armazenamento esteja íntegro

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Execute os seguintes comandos para verificar a integridade do cluster de armazenamento.

oc get storagecluster -n openshift-storage
oc get cephcluster -n openshift-storage

Certifique-se de que o cluster de armazenamento esteja íntegro antes de continuar.

Reduzir a capacidade do OpenShift Data Foundation

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Para cada nó do trabalhador localizado na etapa anterior, localize as implementações rook-ceph-mon e rook-ceph-osd.
```
oc get pods -n openshift-storage -o wide | grep -i <node_name>
```
Se os pods Noobaa ficarem presos durante a drenagem, você pode excluí-los manualmente para que sejam NooBaa agendados em um nó diferente.

Exclua todos os pods Noobaa restantes na seguinte ordem.

   noobaa-db
   noobaa-core
   noobaa-endpoint
   noobaa-operator

Reduza a capacidade das implementações localizadas na etapa anterior.

	oc scale deployment rook-ceph-mon-c --replicas=0 -n openshift-storage

	oc scale deployment rook-ceph-osd-2 --replicas=0 -n openshift-storage

	oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=NODE-NAME --replicas=0 -n openshift-storage

Cordon e drene o nó do trabalhador

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Bloqueie o nó. O bloqueio do nó impede que quaisquer pods sejam programados neste nó.
```
oc adm cordon NODE_NAME
```
Exemplo de saída
```
node/10.241.0.4 cordoned
```

Drene o nó para remover todos os pods. Ao drenar o nó do trabalhador, os pods se movem para os outros nós do trabalhador garantindo que não haja tempo de inatividade. A drenagem também garante que não haja interrupção do orçamento de disrupção do pod.

	oc adm drain NODE_NAME --force --delete-emptydir-data --ignore-daemonsets

Exemplo de saída

	evicting pod "managed-storage-validation-webhooks-7fd79bc9f7-pdpv6"
	evicting pod "calico-kube-controllers-647dbbd685-fmrp9"
	evicting pod "certified-operators-2v852"
	evicting pod "csi-snapshot-controller-77fbf474df-47ddt"
	evicting pod "calico-typha-8574d89b8c-7f2cc"
	evicting pod "dns-operator-6d48cbff67-vrrsw"
	evicting pod "router-default-6fc798b98b-9m6kh"
	evicting pod "prometheus-adapter-5b77ffdd5f-hzqrp"
	evicting pod "alertmanager-main-1"
	evicting pod "prometheus-k8s-0"
	evicting pod "network-check-source-66c7fbb86-2r78z"

Aguarde até que a drenagem seja concluída e, em seguida, execute as etapas a seguir para atualizar o nó de trabalho.

Limpar volumes persistentes dos nós de trabalho bare metal

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Apenas para nós de trabalho em bare metal: Se você estiver atualizando ou substituindo um nó de trabalho em bare metal, siga as etapas a seguir para limpar os volumes persistentes e preparar o nó para a nova implantação. Se você estiver trabalhando com nós de trabalho em instâncias de servidor virtual (VSI), pule esta seção e prossiga para a seção “Atualizar o nó de trabalho ”.

Antes de começar, certifique-se de ter concluído as etapas anteriores para isolar e esvaziar o nó de trabalho.

Identifique quaisquer volumes persistentes (PVs) no estado “ Released ” que estejam associados à classe de armazenamento “ localblock ” no nó que você está atualizando.

	oc get pv -L kubernetes.io/hostname | grep localblock | grep Released

Exemplo de saída

	local-pv-d6bf175b  1490Gi  RWO  Delete  Released  openshift-storage/ocs-deviceset-0-data-0-6c5pw  localblock  2d22h  compute-1

Se houver algum PV no estado “ Released ”, exclua-os. Substitua “ <persistent_volume> ” pelo nome do PV da etapa anterior.
```
	oc delete pv <persistent_volume>
```
Exemplo de comando
```
	oc delete pv local-pv-d6bf175b
```
Exemplo de saída
```
	persistentvolume "local-pv-d6bf175b" deleted
```
Apague os discos ODF no nó bare metal para preparar a criação de um novo volume persistente. Inicie um pod de depuração no nó que você está atualizando. Substitua <node-name> pelo nome do seu nó do Worker em bare metal.
```
	kubectl debug node/<node-name> -it --image=registry.access.redhat.com/ubi8/ubi
```
Exemplo de comando
```
	kubectl debug node/kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -it --image=registry.access.redhat.com/ubi8/ubi
```
Dentro do pod de depuração, acesse o diretório raiz do host.
```
	chroot /host
```

Apague todos os discos NVMe que foram utilizados pelo ODF. Ajuste o intervalo de discos (nvme{0..7}n1) de acordo com o número de discos em sua configuração.

	for disk in /dev/nvme{0..7}n1; do
	  echo "Wiping $disk..."
	  wipefs -af $disk
	  dd if=/dev/zero of=$disk bs=1M count=100
	  sgdisk --zap-all $disk 2>/dev/null || true
	done

Verifique se os discos estão limpos e não contêm mais nenhuma assinatura de sistema de arquivos.
```
	for disk in /dev/nvme{0..7}n1; do
	  echo "=== $disk ==="
	  blkid $disk 2>&1 || echo "Clean"
	done
```
Cada disco deve exibir “Clean” na saída, indicando que todas as assinaturas do sistema de arquivos foram removidas.
Saia do pod de depuração.
```
	exit
	exit
```

Consulte os recursos do localvolumediscoveryresults para localizar a entrada correspondente ao nó que você está atualizando.

	kubectl get localvolumediscoveryresults -n openshift-local-storage

Exemplo de saída

	NAME                                                                      AGE
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3   5d
	discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000004a1   5d

Exclua o recurso localvolumediscoveryresults do nó que você está atualizando. Substitua “ <discovery-result-name> ” pelo nome da etapa anterior.

	kubectl delete localvolumediscoveryresults <discovery-result-name> -n openshift-local-storage

Exemplo de comando

	kubectl delete localvolumediscoveryresults discovery-result-kube-d8g2ek0l0bd8e4oss13g-bhargavibmu-default-000003b3 -n openshift-local-storage

Após concluir essas etapas, novos volumes persistentes serão criados automaticamente e agendados no nó bare metal após sua reinicialização. Passe para a próxima seção para atualizar o nó de trabalho.

Atualizar o nó de trabalho

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Liste seus nós do trabalhador usando o comando ibmcloud oc worker ls e localize o nó do trabalhador que você isolou e drenou na etapa anterior..

	ibmcloud oc worker ls -c CLUSTER

Exemplo de saída

	ID                                                 Primary IP     Flavor     State    Status   Zone        Version
	kube-c85ra07w091uv4nid9ug-vpcoc-default-000001c1   10.241.128.4   bx2.4x16   normal   Ready    us-east-3   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000288   10.241.0.4     bx2.4x16   normal   Ready    us-east-1   4.8.29_1544_openshift*
	kube-c85ra07w091uv4nid9ug-vpcoc-default-00000352   10.241.64.4    bx2.4x16   normal   Ready    us-east-2   4.8.29_1544_openshift*

Atualizar o nó de trabalho. Para nós de trabalho bare metal, use o comando worker reload. Para nós de trabalho de instância de servidor virtual (VSI), use o comando worker replace.

Nós de trabalho bare metal: Use o comando worker reload para recarregar o nó de trabalho. Este comando é compatível com os workers bare metal da VPC. sh {: pre} ibmcloud oc worker reload --worker kube-*** Nós de trabalho VSI: Minor update Exemplo de comando para substituir o nó de trabalho e aplicar a atualização de patch mais recente. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** --update Nós de trabalho VSI: Worker replace Exemplo de comando para substituir o nó de trabalho sem aplicar a atualização de patch mais recente. sh {: pre} ibmcloud oc worker replace -c CLUSTER --worker kube-*** Exemplo de saída para substituição do nó de trabalho VSI: sh {: screen} The replacement worker node is created in the same zone with the same flavor, but gets new public or private IP addresses. During the replacement, all pods might be rescheduled onto other worker nodes and data is deleted if not stored outside the pod. To avoid downtime, ensure that you have enough worker nodes to handle your workload while the selected worker nodes are being replaced. Replace worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288? [y/N]> y Deleting worker node kube-c85ra07w091uv4nid9ug-cluster-default-00000288 and creating a new worker node in cluster

Aguarde até que o nó de trabalho seja recarregado ou substituído e, em seguida, liste os nós de trabalho. Observe que esse processo pode levar 20 minutos ou mais.

	oc get nodes

Exemplo de saída

	NAME           STATUS   ROLES           AGE   VERSION
	10.241.0.4     Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.128.4   Ready    master,worker   22d   v1.21.6+bb8d50a
	10.241.64.4    Ready    master,worker   22d   v1.21.6+bb8d50a

Limpar os recursos do nó antigo

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Verifique se o pod OSD surgiu no nó substituído em um estado running. Se o pod estiver funcionando, vá para a etapa 7. Se o pod tiver falhado, execute o seguinte steps.If mais de um pod OSD não é Running, pare e entre em contato com o suporte. Abrir um caso de suporte. Nos detalhes do caso, certifique-se de incluir todos os arquivos de registro, mensagens de erro ou saídas de comando relevantes.
Navegue para o projeto do openshift-storage
```
	oc project openshift-storage
```
Remova o OSD com falha do cluster Você pode especificar vários OSDs com falha, se necessário.
```
	oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=<failed_osd_id> -p FORCE_OSD_REMOVAL=true | oc create -f -
```
O valor FAILED_osd_id é o número inteiro no nome do pod imediatamente após o prefixo rook-ceph-osd. O valor FORCE_OSD_REMOVAL deve ser mudado para true em clusters que tenham apenas três OSDs ou clusters com espaço insuficiente para restaurar todas as três réplicas dos dados após o OSD ser removido...
Verifique se o OSD foi removido com sucesso, verificando o status do pod ocs-osd-removal-job
```
	oc get pod -l job-name=ocs-osd-removal-job -n openshift-storage
```

Verifique se a remoção do OSD foi concluída

	oc logs -l job-name=ocs-osd-removal-job -n openshift-storage --tail=-1 | egrep -i 'completed removal'

Exemplo de saída

	2023-03-10 06:50:04.501511 I | cephosd: completed removal of OSD 0

Adicione o novo nó de armazenamento

Antes de adicionar novos nós de armazenamento, verifique se você concluiu as etapas anteriores para todos os nós de armazenamento no cluster.

[Atualização importante] {: tag-red}[ Atualização menor] {: tag-blue} Substituição de funcionário

Se você tiver limitado sua implementação do ODF a um subconjunto de nós do trabalhador especificando nomes de nós durante a instalação, deverá atualizar o CRD do ocscluster para incluir o novo nome.

Se você não limitou sua configuração a apenas alguns nós de trabalho, não precisará atualizar o CRD do ocscluster.
```
	oc edit ocscluster
```
```
	apiVersion: ocs.ibm.io/v1
	kind: OcsCluster
	metadata:
	name: ocscluster-auto
	spec:
	. . .
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-metro-10iops-tier
	workerNodes:
	- NODE-NAME # Example 10.248.128.42
	- NODE-NAME
	- NODE-NAME
```
Aguarde a implementação dos pods do OpenShift Data Foundation no novo trabalhador. Verifique se os novos volumes persistentes foram criados e se todos os pods estão em um estado Running
```
	oc get pv
	oc get ocscluster
	oc get pods -n openshift-storage
```

Verifique se todos os outros pods necessários do OpenShift do Data Foundation estão no estado Em Execução

	oc get pod -n openshift-storage | grep mon

Saída de exemplo:

	rook-ceph-mon-a-cd575c89b-b6k66         2/2     Running
	0          38m
	rook-ceph-mon-b-6776bc469b-tzzt8        2/2     Running
	0          38m
	rook-ceph-mon-d-5ff5d488b5-7v8xh        2/2     Running
	0          4m8s

Verifique se os novos pods OSD estão sendo executados no nó de substituição.

	oc get pods -o wide -n openshift-storage| egrep -i <new_node_name> | egrep osd

Atualize o complemento do OpenShift Data Foundation

Grande atualização

Verifique a versão existente.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Atualize o complemento.

	ibmcloud oc cluster addon update openshift-data-foundation --cluster CLUSTER --version VERSION

Verifique se o complemento está atualizado.

	ibmcloud oc cluster addon ls --cluster CLUSTER

Atualize seu recurso de cluster

Grande atualização

Obtenha o nome do seu recurso do ocscluster.

	oc get ocscluster

Exemplo de saída

	NAME             AGE
	ocscluster-vpc   19d

Execute o comando a seguir para editar seu recurso ocscluster.
```
	oc edit ocscluster OCS-CLUSTER-NAME
```

Defina o parâmetro ocsUpgrade como true``.

	...
	spec:
		billingType: hourly
	monSize: 20Gi
	monStorageClassName: ibmc-vpc-block-10iops-tier
	numOfOsd: 1
	ocsUpgrade: true
	osdSize: 250Gi
	osdStorageClassName: ibmc-vpc-block-10iops-tier
	status:
		storageClusterStatus: Decreasing the capacity not allowed

Salve e feche o arquivo.
Aguarde até que a atualização seja concluída.

Verifique se os recursos storagecluster e cephcluster estão implementados corretamente.

	oc get storagecluster -n openshift-storage
	NAME                 AGE   PHASE   EXTERNAL   CREATED AT             VERSION
	ocs-storagecluster   43h   Ready              2023-06-21T09:22:00Z   4.11.0

	oc get cephcluster -n openshift-storage
	NAME                             DATADIRHOSTPATH   MONCOUNT   AGE   PHASE   MESSAGE                        HEALTH      EXTERNAL
	ocs-storagecluster-cephcluster   /var/lib/rook     3          43h   Ready   Cluster created successfully   HEALTH_OK

	oc get csv -n openshift-storage
	NAME                              DISPLAY                       VERSION   REPLACES                          PHASE
	mcg-operator.v4.11.8              NooBaa Operator               4.11.8    mcg-operator.v4.11.7              Succeeded
	ocs-operator.v4.11.8              OpenShift Container Storage   4.11.8    ocs-operator.v4.11.7              Succeeded
	odf-csi-addons-operator.v4.11.8   CSI Addons                    4.11.8    odf-csi-addons-operator.v4.11.7   Succeeded
	odf-operator.v4.11.8              OpenShift Data Foundation     4.11.8    odf-operator.v4.11.7              Succeeded