Вот процесс, который я рекомендую использовать в качестве наилучшей практики для остановки и запуска вашего кластера(ов) OpenShift. Выполнение этого процесса даст вам наилучшие шансы на бесперебойное техническое обслуживание. Как и во всем, вы должны проявлять осторожность в этом процессе на ваших важных кластерах. Сначала попробуйте его в тестовой среде и посмотрите, подходит ли он вам.
!!! Важно: Этот процесс приведет к сбою любой рабочей нагрузки приложения, работающей в кластере, до тех пор, пока кластер не будет полностью запущен. Сам кластер будет недоступен, пока не будет запущен вручную. Следует соблюдать осторожность, чтобы запускать этот процесс только в соответствующих средах. Рекомендуется иметь резервные копии вашей среды.
Остановка вашего кластера
Остановка кластера — относительно простой процесс. Настоящая трудность всегда связана с рабочей нагрузкой на пике кластера. Вы также должны убедиться, что у вас есть возможность откатить все назад, если что-то пойдет не так. Это означает, что вы должны быть уверены в своей способности перестроить кластер; иметь отработанный, проверенный процесс резервного копирования (вы все равно делаете это, верно?) и иметь представление о рабочей нагрузке, с которой вы работаете.
Знайте состояние своего кластера
Первое, что я хотел бы сделать, это убедиться, что я знаю, в каком состоянии находится мой кластер, прежде чем выполнять отключение кластера. Я хочу знать, какие пространства имен у меня есть ( oc projects ), в каком состоянии находятся модули ( oc get pods --all-namespaces ) и в каком состоянии находятся мои узлы ( oc get nodes --show-labels ). Знание того, что работает, а что нет, важно, когда дело доходит до знания того, как выглядит «то же самое, что и раньше» после того, как вы снова запустили кластер.
Вы должны решить все проблемы в кластере, прежде чем продолжить — например oc get nodes должно показать, что все узлы готовы. Инструкции по более углубленным проверкам можно найти в документации .
Совет: Если конфигурации узлов настроены неправильно, метки не будут применяться правильно. Убедитесь, что конфигурации узлов применяются правильно, чтобы сохранить метки узлов во время перезапуска. Обратитесь к документации для получения дополнительной информации.
План отката
Далее вырезаем резервную копию вашего кластера. Вы, вероятно, делаете это на регулярной основе, но если вы этого не делаете, вам следует взглянуть на такие инструменты, как https://velero.io/ , которые помогают вам регулярно делать снимки состояния вашего кластера и постоянного хранилища и отправлять их в один из количество целей хранения, таких как S3. Если вы хотите создать свой собственный, вы можете обратиться к документации , в которой подробно описано, что вам нужно захватить в рамках резервного копирования среды.
Совет. Отключение узлов вместо корректного завершения работы работающего кластера — плохая идея, так как приложения и службы могут остаться в несогласованном состоянии. Убедитесь, что у вас есть соответствующие резервные копии в соответствии с документацией .
Если ответ на вопрос «могу ли я все вернуть, если нужно?» не да, то не продолжайте.
Остановите свои приложения
Теперь, когда мы знаем, как выглядит наш кластер, и знаем, что можем восстановить его в случае возникновения каких-либо проблем, мы можем остановить рабочую нагрузку нашего приложения. Контролируемая остановка рабочей нагрузки приложения помогает нам избежать потери данных.
Совет. Следует соблюдать осторожность при работе с рабочими нагрузками приложений, чтобы обеспечить их корректную остановку во избежание случайной потери данных. Согласованность данных важна!
◽️ Первый вариант — уменьшить масштаб всех конфигураций развертывания, чтобы ни один из модулей приложений не работал. Вы можете рассмотреть возможность бездействия модулей как способ динамической остановки рабочей нагрузки или создания плейбуков Ansible для перезапуска правильного количества реплик, когда мы позже запустим кластер. В любом случае вам нужно будет знать, сколько реплик вы возвращаете.
◽️ Второй вариант заключается в том, что вы можете сбросить рабочую нагрузку со всех рабочих узлов, а не останавливать все приложения по отдельности, чтобы обеспечить согласованность приложений. В этом случае вам потребуется:
1а)Отцепите все ваши рабочие узлы, чтобы предотвратить запуск или перемещение новых модулей oc adm cordon <node>. Обратитесь к документации по узлам планирования .
1б) Слейте все ваши рабочие узлы, используя что-то вроде: oc adm drain <node> --ignore-daemonsets --force --grace-period=30 --delete-local-data. Это заставляет модули останавливаться, игнорирует любые наборы демонов, запущенные на узлах, принудительно устанавливает период постепенного завершения в 30 секунд для корректной остановки модулей и удаляет все модули с локальными эфемерными данными.
Варианты слива узлов рекомендуется просмотреть в документации .
◽️ Третий вариант — изящно закрыть рабочие узлы, не снижая нагрузку на приложение. Этот подход хорошо работает, если у вас нет служб с отслеживанием состояния, таких как базы данных, или вы разработали свое приложение, допускающее сбой. Грамотное завершение работы приводит к остановке процессов вашего приложения как части завершения работы системы. В конце концов, любые процессы, которые не были остановлены корректно, будут принудительно завершены. Поды, которые были запущены во время остановки кластера, снова запустятся на том рабочем потоке, на котором он был запланирован в последний раз. Это позволяет быстро возобновить рабочую нагрузку на месте во время запуска кластера после такого события, как потеря питания.
Остановка кластера
Совет. Тома блочного хранилища, которые были динамически подготовлены через облачного провайдера, такого как AWS EBS или VMWare vSphere, останутся подключенными к любым узлам, где работают модули с постоянным хранилищем, если эта рабочая нагрузка не будет остановлена.
- Изящно отключите все рабочие узлы (worker nodes) — например:
shutdown -h now. Все workers nodes должны быть остановлены вместе или оцеплены, иначе OpenShift может попытаться перенести рабочую нагрузку. - Изящно отключите все узлы Infra (Infra nodes) — например:
shutdown -h now. - Изящно отключите все мастера (masters) — например:
shutdown -h now.
Запуск вашего кластера
Восстановление кластера намного проще, чем процедура выключения. Вам просто нужно запускать узлы в правильном порядке для достижения наилучших результатов.
Совет. Дополнительные рекомендации по проверке работоспособности кластера можно найти в руководстве по эксплуатации day2 .
Запустите свои мастер-ноды
После того, как они загрузятся, мы можем проверить их работоспособность oc get nodes — все узлы должны быть в ready состоянии, прежде чем переходить к вашим инфраструктурным узлам.
Запустите свои инфраузлы
После загрузки ваших инфраузлов вы можете убедиться, что инфраузлы отображаются в состоянии готовности, и это oc get pods –all-namespaces показывает, что ведение журнала, метрики, модули маршрутизатора и реестра запущены и работоспособны.
Запустите рабочие узлы
После загрузки ваших рабочих узлов вы можете убедиться, что все узлы отображаются в состоянии готовности с помощью oc get nodes. Более подробный набор проверок см . в документации по проверке работоспособности
Запустите свои приложения
Теперь, когда ваш кластер запущен и вы доказали его работоспособность, вы можете приступить к рабочей нагрузке приложения. Если вы решили просто отключить свои рабочие узлы без снижения рабочей нагрузки, то ваши приложения будут перезапущены на тех узлах, где они находились ранее, в противном случае вам потребуется увеличить количество реплик или некордонных узлов в зависимости от выбранного вами подхода.
Наконец, убедитесь, что ваши модули приложений запущены правильно, oc get pods --all-namespaces и выполните любые проверки, которые могут потребоваться для вашего приложения, чтобы убедиться, что оно доступно и работоспособно.
https://www.redhat.com/en/blog/how-stop-and-start-production-openshift-cluster
https://eti.io/how-to-stop-and-start-a-production-openshift-cluster/
Useful links:
- OpenShift Day 2 Operations guide: https://docs.openshift.com/container-platform/3.11/day_two_guide/environment_health_checks.html
- Red Hat verified solution for shutting down or restarting a cluster. https://access.redhat.com/solutions/3499881
- Documentation about scheduling nodes: https://docs.openshift.com/container-platform/3.11/admin_guide/manage_nodes.html#marking-nodes-as-unschedulable-or-schedulable
- Documentation about draining nodes https://docs.openshift.com/container-platform/3.11/admin_guide/manage_nodes.html#evacuating-pods-on-nodes
- Documentation about idling pods: https://docs.openshift.com/container-platform/3.11/admin_guide/idling_applications.html
- Documentation regarding cluster backups https://docs.openshift.com/container-platform/3.11/day_two_guide/environment_backup.html
- Documentation about how to label nodes https://docs.openshift.com/container-platform/3.11/admin_guide/manage_nodes.html#modifying-nodes
- Documentation covering cluster health checks https://docs.openshift.com/container-platform/3.11/day_two_guide/environment_health_checks.html
- Velero project website: https://velero.io/