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

Virtual Private Cloud

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 do OpenShift em um subconjunto de nós de trabalho do seu cluster, após atualizar um 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.

Major update: 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.
Minor update: 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.
Worker replace: 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

Major update Minor update Worker replace

Liste os pods executando o comando a seguir. Verifique se todos os pods no namespace openshift-storage estão em um bom estado. Trate todos os pods que não estejam no estado “ Running ” ou “ Completed ”.
```
	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. Desativar mais de um pod OSD ao mesmo tempo pode comprometer os dados dos usuários.

Atualizar o cluster principal

Major update

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_NAME --version MAJOR.MINOR.PATCH --force-update

Exemplo de comando:

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

Aguarde alguns minutos e, em seguida, verifique se a atualização principal foi concluída.
```
	  ibmcloud oc cluster ls
```

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

Major update Minor update Worker replace

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

Major update Minor update Worker replace

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.

Isolar e reduzir a escala da Base de Dados do OpenShift

Major update Minor update Worker replace

Reduzir a escala das implantações do rook-ceph-mon, ` `rook-ceph-osd e do crashcollector antes da drenagem garante que esses processos de armazenamento sejam encerrados de forma controlada, em vez de serem encerrados à força. Os pods de OSD e de monitor devem ser desligados de forma controlada, para que o Ceph possa interromper as operações de E/S com segurança e manter a integridade dos dados enquanto o nó estiver offline. Depois que o nó atualizado ou substituído voltar a fazer parte do cluster, o operador do Rook-Ceph dimensiona automaticamente essas implantações de volta às contagens originais de réplicas.

Bloqueie o nó. Isolar o nó impede que quaisquer pods sejam agendados nesse nó enquanto você reduz as implantações do ODF.
```
	oc adm cordon NODE_NAME
```
Exemplo de saída
```
	node/10.241.0.4 cordoned
```
Encontre os pods rook-ceph-mon e rook-ceph-osd em execução no nó que você está atualizando. Anote os nomes dos pods na saída — você precisará deles na próxima etapa.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
O nome da implantação é o nome do pod sem os sufixos finais “ ReplicaSet ” e o ID do pod. Por exemplo, um pod chamado rook-ceph-osd-1-6d9f99c68f-pgvxt pertence à implantação rook-ceph-osd-1, e um pod chamado rook-ceph-mon-e-85fbb8bcc-kttbt pertence à implantação rook-ceph-mon-e.
Reduza a escala das implantações dos pods que você identificou na etapa anterior. Substitua ROOK_CEPH_MON_DEPLOYMENT e ROOK_CEPH_OSD_DEPLOYMENT pelos nomes de implantação que você derivou dos nomes dos pods. Se o comando anterior não tiver retornado nenhum pod do tipo rook-ceph-mon ou rook-ceph-osd neste nó, pule esses dois comandos e passe diretamente para o comando crashcollector.
```
	oc scale deployment ROOK_CEPH_MON_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment ROOK_CEPH_OSD_DEPLOYMENT --replicas=0 -n openshift-storage
```
```
	oc scale deployment --selector=app=rook-ceph-crashcollector,node_name=NODE_NAME --replicas=0 -n openshift-storage
```
Se o comando retornar “ error: no objects passed to scale ”, verifique se não há nenhum pod do crashcollector em execução neste nó, executando “ oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep crashcollector ”. Se nenhum pod for retornado, você pode pular esse comando sem problemas e continuar.

Drene o nó do trabalhador

Major update Minor update Worker replace

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"

Se algum pod do NooBaa ficar travado durante a drenagem, exclua-os na seguinte ordem para que sejam reprogramados em um nó diferente.

	oc delete pod -n openshift-storage -l app=noobaa-db

	oc delete pod -n openshift-storage -l app=noobaa-core

	oc delete pod -n openshift-storage -l app=noobaa-endpoint

	oc delete pod -n openshift-storage -l app=noobaa-operator

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

Major update Minor update Worker replace

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 apagar os discos ODF 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.

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, passe para a próxima seção para atualizar o nó de trabalho. Novos volumes persistentes são criados e agendados automaticamente no nó bare metal após sua recarga.

Atualizar o nó de trabalho

Major update Minor update Worker replace

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 NODE_NAME Nós de trabalho do VSI: Major update 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 NODE_NAME --update Nós de trabalho do 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 NODE_NAME 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

Major update Minor update Worker replace

Depois que o nó volta a se juntar ao cluster, o operador do Rook-Ceph dimensiona automaticamente de volta as implantações do rook-ceph-mon, rook-ceph-osd e crashcollector. Verifique se os pods ODF estão em execução antes de continuar.

Verifique se os pods rook-ceph-mon e rook-ceph-osd, cujo tamanho foi reduzido anteriormente, estão novamente no estado “ Running ” no nó atualizado. Substitua NODE_NAME pelo nome do nó atualizado ou substituído.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME
```
Verifique se a saída exibe os pods “ rook-ceph-mon ” e “ rook-ceph-osd ” no estado “ Running ”. Se ainda houver pods ausentes ou que ainda não estejam em “ Running ”, aguarde alguns minutos e execute o comando novamente antes de continuar.
Verifique se o pod OSD foi iniciado no nó substituído no estado “ Running ”. Substitua “ NODE_NAME ” pelo nome do novo nó substituto.
```
	oc get pods -n openshift-storage -o wide | grep NODE_NAME | grep osd
```
Se o pod estiver em execução, continue atualizando o recurso OcsCluster com o novo nó. Se o pod apresentar falha, execute as etapas a seguir. Se mais de um pod OSD não estiver em estado “ Running ”, interrompa o processo 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

Apenas para nós de trabalho “bare metal ”: Após a remoção do OSD, identifique quaisquer volumes persistentes (PVs) no estado “ Released ” que estejam associados à classe de armazenamento “ localblock ”. A remoção do OSD coloca esses PVs no est Released, portanto, essa etapa deve ser concluída após a remoção do OSD.
```
	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
```
Apenas para nós de trabalho “bare metal ”: 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
```

Atualize o recurso OcsCluster com o novo nó

Antes de prosseguir para as etapas seguintes, certifique-se de ter concluído as etapas anteriores para este nó de armazenamento antes de passar para o próximo nó do cluster.

Major update Minor update Worker replace

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ê aplicou o ODF a todos os seus nós de trabalho e não limitou a implantação a um subconjunto de nós, pule esta etapa e prossiga para a atualização do complemento “ OpenShift Data Foundation ”.

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

Major update

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

Major update

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

Exemplo de saída.

	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

Exemplo de saída.

	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

Exemplo de saída.

	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