Öppet skift: Förkontroll av OCP-uppgradering misslyckades på grund av torrkörningsnodfel

Under LCM-förkontrollen kan det uppstå ett torrkörningsfel på dräneringsnoden, vilket blockerar LCM-processen.


Felmeddelandet kan innehålla men inte begränsat till följande scenarier:

• Scenario 1: "VMI XXXXXX är konfigurerat med en borttagningsstrategi men kan inte migreras live."
• Scenario 2: "Det går inte att vräka podden eftersom den skulle bryta mot poddens störningsbudget."
• Scenario 3: "pods xxx" hittades inte för POD:xxxxxxxxxxxx

Scenario 1 – rotororsak: Den virtuella datorn konfigureras med ReadWriteOnce-lagringsvolymen (RWO) som inte kan direktmigreras på felrapporteringsnoden.

Rotorsak till scenario 2: Inställningen "PodDistruptionBudget" för podden är konfigurerad som "minAvailable: 1", Det blockerar borttagningsprocessen för poddar.

Grundorsaken till Senario 3: Det schemalagda Openshift-jobbet startar en podd och podden avslutas när jobbet har slutförts. Så det finns en risk att podden inte kan hittas under förkontrollen av torrkörningstömningsnoden.

Scenario 1-lösning

1. Stoppa VM-instansen innan du ändrar dess PV-inställningar.


2. Klicka på den virtuella datorn och växla till YAML-fliken.



3. Ändra accessModes från "ReadWriteOnce" till "ReadWriteMany".


4. Om PV inte kan anges till ReadWriteMany (den virtuella datorn kan inte börja använda ReadWriteMany) anger du evictionStrategy från "LiveMigrate" till "None".

Observera: Utför antingen steg 3 eller 4 som gäller för din miljö, du behöver inte utföra båda stegen.

5. Klicka på Spara och starta om den virtuella datorn.


6. Gör en ny LCM-förkontroll och fortsätt med uppgraderingen.
 

Scenario 2-lösning

Utför någon av följande procedurer som gäller för din miljö.

Förfarande 1: Ta bort de poddar som inte kan avlägsnas manuellt.

• Kör kommandot nedan för att ta bort de poddar som inte kan avlägsnas och låt dem återskapas i olika noder.

$ oc delete pod <pod_name> -n <pod_namespace>

• Gör en ny LCM-förkontroll och fortsätt med uppgraderingen.

Förfarande 2: Om podden inte kan tas bort manuellt korrigerar du podden vars "PodDisruptionBudget" har konfigurerats som "minAvailable: 1"

• Kör kommandot nedan för att kontrollera värdet för podden "PodDisruptionBudget"

$ oc get pdb <pdb_name> -n <pod_namespace> 
 
NAME         MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
<pdb_name>   1               N/A               0                     18h

 

• Om kommandoutdata visar att "MIN AVAILABLE" är "1" korrigerar du PodDisruptionBudget minAvailable-värdet till "0" med kommandot nedan.

$ oc patch pdb <pdb_name> -n <pod_namespace> --type=merge -p '{"spec":{"minAvailable":0}}'

• Gör en ny LCM-förkontroll och fortsätt med uppgraderingen.
• Vänta tills uppgraderingen är klar och MCO är tillgänglig. Kör kommandot nedan för att kontrollera att allt är bra.

$ watch -n10 "oc get clusterversion; echo; oc get mcp; echo; oc get nodes -o wide; echo; oc get co"

 

• När OCP-uppgraderingen har slutförts återställer du värdet PodDisruptionBudget minAvailable till "1"

$ oc patch pdb <pdb_name> -n <pod_namespace> --type=merge -p '{"spec":{"minAvailable":1}}'

Förfarande 3: Om korrigeringen av poddträfffelet "PodDisruptionBudget.policy "<pdb_name>" är ogiltig: spec: Förbjudet: uppdateringar av poddisruptionbudget-specifikationen är förbjudna.", följ stegen nedan för att kringgå problemet.

• Säkerhetskopiera PodDisruptionBudget som är konfigurerad med "minAvailable: 1"

$ oc get pdb <pdb_name> -n <pod_namespace> -o yaml > <pdb_name>_backup.yaml

 

• Ta bort PodDisruptionBudget som har konfigurerats med "minAvailable: 1"

$ oc delete pdb <pdb_name> -n <pod_namespace>

 

• Gör en ny LCM-förkontroll och fortsätt med uppgraderingen.
• Vänta tills uppgraderingen är klar och MCO är tillgänglig. Kör kommandot nedan för att kontrollera att allt är bra.

$ watch -n10 "oc get clusterversion; echo; oc get mcp; echo; oc get nodes -o wide; echo; oc get co"

 

• När OCP-uppgraderingen är klar återställer du yaml-säkerhetskopian.

$ oc create -f <pdb_name>_backup.yaml -n <pod_namespace>

 

Scenario 3-lösning

Försök helt enkelt att kontrollera LCM igen, det bör klara den här gången.

Se OpenShift-dokumentet nedan för mer information om lagringsvolymer för virtuella datordiskar.

https://access.redhat.com/documentation/en-us/openshift_container_platform/4.13/html/virtualization/about-virt