Заглянув в OpenShift, я заметил, что приложения стали дольше запускаться и работать медленнее. Дальнейшие изыскания показали, что одна из Node вывалилась из кластера OS. Попытался исправить проблему через ssh. Но вспомнил, что ключ от ssh остался на рабочем компьютере. Надпись Permission denied (publickey,gssapi-keyex,gssapi-with-mic) лишь подтвердила плачевность ситуации . Смотреть на экран виртуалки в консоли гипервизора, без возможности попасть внутрь… Эх! Ретроспектива восстановления работы Node будет описана ниже. Как говорится, все совпадения и имена героев случайны. Аварийная загрузка и вход в консоль в систему. Смена пароля пользователя core. Решаем проблему с входом по ssh. Разрешение входа по логину и паролю без ssh-ключей Настройка сетевых интерфейсов. Тюнинг ядра системы. А что дальше? Если ничего не помогло. Началось всё с аварийной загрузки. Для того чтобы нам получить shell после запуска системы, необходимо добавить определённый параметр ядра. Речь об rd.break. При старте системы отображается меню загрузки grub, нажимаем клавишу E и добавляем rd.break в строку linux: Нажимаю Ctrl+X и жду загрузки системы. Система загружается, но консоль не появилась. Что же здесь не так? Оказывается, необходимо было отключить интерактивную консоль. Для этого удалить строки console=tty0 console=ttyS0,115200n8: Финальный вариант будет такой: Нажимаем Ctrl+X, и система загружается. Нажимаем Enter, и становится доступен жизненно важный shell: Для того чтобы сменить пароль, временно меняю каталог корневой системы через команду chroot: OpenShift работает при включённом SELinux, и, следовательно, у файла, должны быть соответствующие метки: Ставлю необходимую метку: Проверяю: Теперь можно перезагрузить систему командой: Или нажать кнопку на перезапуск в панели управления для виртуальной машины или сервера. По умолчанию в системе разрешён вход только по ssh-ключам, информация о которых сохраняется в файле .ssh/authorized_keys. Если вы оставили ssh-ключ на работе или просто он где-то потерялся в рабочих буднях, а также при необходимости добавления ещё одного ssh-ключа будем работать с этим файлом. Нужно дописать новый ключ вашего / из вашего id_rsa.pub. Но перед этим стоит проверить, что у файла установлены соответствующие права и метки SELinux: или Внимание, данное действие снижает безопасность системы! Нужно использовать вход с помощью ssh-ключа и пользователя core. Кардинально решить проблему забытых ssh-ключей может разрешение на вход в систему по логину и паролю. Для этого есть два способа в зависимости от доступной функциональности системы: Получаю права администратора и доступ к файловой системе: Редактирую файл для активации входа по логину и паролю. Для этого меняю параметр PasswordAuthentication на yes. Выхожу из-под пользователя root и перезапускаю сервис: Дополнительно поверяю метку SElinux у файла. Это пригодится для второго варианта: Редактирую файл /etc/ssh/sshd_config, аналогично заменив в нём строку на PasswordAuthentication yes. Сохраняю и проверяю метки SElinux: Как видно, контекст-метки SElinux у файла потерялись. Восстановим их: Если необходимо восстановить или настроить сетевые интерфейсы у виртуальной машины, используем утилиту nmcli. Вывести настройки сетевых соединений можно простой командой: С помощью команды nmcli connection mod «имя соединения» можно отредактировать сетевые настройки и потом перезапустить сетевой интерфейс. Раз мы уж всё равно так активно используем командную строку, то можно подтюнить ядро. В системах, которые используют rpm-ostree, можно добавлять, удалять параметры ядра, которые задаются при загрузке системы. Например, можно увеличить быстродействие системы, отключив защиту от уязвимости Spectre v1 и v2. Для этого нужно добавить параметры: Делается это следующими командами: После перезагрузки системы можно проверить, что параметры ядра были применены, выполнив команду: И наоборот, если хотим удалить параметры ядра, тогда можно выполнить данную команду: Справку по данной команде можно посмотреть так: Дополнительные параметры, которые вам могут понадобиться: Режим quiet позволит удалить данные сообщения с виртуальной консоли первого экрана в системе: Дополнительно рассмотрим подключение второго жёсткого диска. Имя диска может отличаться от вида контроллера жёсткого диска в системе или виртуальной машине. В моём примере это были диски /dev/sd*. Для начала разобьём жёсткий диск на разделы: Чтобы подключить диск в папку /usr/local/1, необходимо создать такой Unit file systemd: Включаем автозагрузку и запускаем: Проверим, что подключился наш раздел (df -h): Обязательно обращаем внимание на метки SELinux, которые необходимы для systemd unit файла (system_u:object_r:systemd_unit_file_t:s0). Если подключаете новый диск в папку /var/lib/containers, посмотрите данную информацию: Bug 1692513 - unable to mount disk at `/var/lib/containers` via `systemd` unit when `container-selinux` policy installed После получения доступа в систему проводим стандартные процедуры по чтению логов служб сервисов. В завершение диагностики и после исправления сбоев, когда Node будет снова в кластере OpenShift, можно использовать стандартные средства для сбора и анализа логов со всех Nodes OpenShift: Если данные, сохранённые на данной Node в PV (Persistent Volume), подключённые в HostPath данной ноды, были сохранены и планируется установить снова систему на пустую виртуалку или сервер, тогда можно воспользоваться краткой шпаргалкой-подсказкой: Installing a cluster on bare metal. Если вышеописанные способы восстановления доступа к Node не помогли, то остаётся лишь одно — переустановка системы. Для установки OpenShift можно использовать один из двух популярных образов: RHCOS (Red Hat Enterprise Linux CoreOS) Fedora CoreOS Загрузившись с образа rhcos-4.6.8-x86_64-live.x86_64.iso, вы увидите экран приветствия и информацию-пример core-installer. В случае ручной установки и подготовки образа запускается установка с помощью coreos-installer, которому передаются параметры для установки, ссылка на url с файлами ignition (для bootstrap, compute node и worker node) и другие дополнительные параметры. Также могут потребоваться такие настройки: параметры для ядра с назначением необходимого айпи адреса для данной виртуальной машины или сервера, днс имён, адреса, где располагаются образы системы, и тому подобное. Вот один из моих примеров для KVM-виртуализации: P. S. Если вы захотите потренироваться на кошках, чтобы всегда быть готовым к ситуации, когда ssh-ключа не будет под рукой, тогда необходимо загрузиться с диска (iso) и провести установку на систему. Например, на VirtualBox: