Разомкнутое смещение: Сбой предварительной проверки модернизации OCP из-за ошибки узла слива ресурсов Dryrun

Во время предварительной проверки LCM может произойти сбой узла слива ресурсов «сухого запуска», что заблокирует процесс LCM.


Сообщение об ошибке может содержать, помимо прочего, следующие сценарии:

• Сценарий 1. «VMI XXXXXX настроен со стратегией вытеснения, но не переносится в реальном времени».
• Сценарий 2. "Невозможно выселить капсулу, так как это нарушит бюджет на разрушение капсулы."
• Сценарий 3. "pods xxx" не найдено для pod:xxxxxxxxxxxx

Основная причина сценария 1: Для виртуальной машины настроен том хранилища ReadWriteOnce (RWO), который не может быть перенесен в режиме реального времени на узел отчетов об ошибках.

Основная причина сценария 2: Настройка pod "PodDistruptionBudget" настроена как "minAvailable: 1", Это заблокирует процесс вытеснения POD.

Основная причина Senario 3: Запланированное задание Openshift запустит модуль, и модуль будет завершен после завершения задания. Таким образом, есть вероятность, что стручок не будет найден на этапе предварительной проверки узла слива с помощью сухого запуска.

Разрешение сценария 1

1. Остановите экземпляр виртуальной машины, прежде чем изменять для него параметры PV.


2. Нажмите виртуальную машину и переключитесь на вкладку YAML.



3. Измените accessModes с "ReadWriteOnce" на "ReadWriteMany".


4. Если PV не может быть установлено в ReadWriteMany (виртуальная машина не может начать использовать ReadWriteMany), задайте для evictionStrategy значение «LiveMigrate» в «None».

Примечание: Выполните шаг 3 или 4 применительно к вашей среде; не обязательно выполнять оба шага.

5. Нажмите Save и перезапустите виртуальную машину.


6. Повторите предварительную проверку LCM и продолжите модернизацию.
 

Сценарий 2: разрешение

Выполните одну из следующих процедур, применимых к вашей среде.

Процедура 1. Вручную удалите один или несколько модулей pod, которые нельзя вытеснить.

• Выполните следующую команду, чтобы удалить модули/модули, которые не могут быть вытеснены, и позволить им повторно создаться в других узлах.

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

• Повторите предварительную проверку LCM и продолжите модернизацию.

Процедура 2. Если модуль pod нельзя удалить вручную, исправьте модуль, у которого "PodDisruptionBudget" задан как "minAvailable: 1"

• Выполните следующую команду, чтобы проверить значение pod "PodDisruptionBudget"

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

 

• Если выходные данные команды показывают, что «MIN AVAILABLE» равно «1», измените значение PodDisruptionBudget minAvailable на «0» с помощью следующей команды.

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

• Повторите предварительную проверку LCM и продолжите модернизацию.
• Дождитесь завершения модернизации и доступности MCO, выполните следующую команду, чтобы убедиться, что все в порядке.

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

 

• После завершения модернизации OCP восстановите для параметра PodDisruptionBudget minAvailable значение «1».

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

Процедура 3: Если исправление ошибки попадания в pod "PodDisruptionBudget.policy "<pdb_name>" недействительно: spec: Запрещено: обновления спецификации poddisruptionbudget запрещены.", выполните следующие действия, чтобы обойти проблему.

• Создайте резервную копию PodDisruptionBudget, для которого задано значение «minAvailable: 1"

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

 

• Удалите PodDisruptionBudget, для которого задано значение «minAvailable: 1"

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

 

• Повторите предварительную проверку LCM и продолжите модернизацию.
• Дождитесь завершения модернизации и доступности MCO, выполните следующую команду, чтобы убедиться, что все в порядке.

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

 

• После завершения модернизации OCP восстановите файл yaml резервной копии.

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

 

Сценарий 3 Разрешение

Просто повторите предварительную проверку LCM, на этот раз она должна быть пройдена.

Дополнительные сведения об объемах хранения дисков виртуальных машин см. в приведенном ниже документе Openshift.

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