Обновление региона KeyStack ks2025.1.x → ks2026.2.1 вместе с ОС узлов¶
В этом разделе описаны шаги по обновлению версии KeyStack и ОС на узлах.
Здесь и далее вместо x в версии ks2025.1.x указывайте фактическую версию патча, установленную на узле.
Перед обновлением региона обязательно выполните обновление LCM до версии ks2026.2.1 (см. Обновление LCM ks2025.1.x → ks2026.2.1) — в его процессе пакет обновления upgrade-ks2026.2.1-{sberlinux|ubuntu}.tgz уже загружается на LCM-узел в папку /installer/update. Для регионов с Cloud SDS дополнительно требуется пакет upgrade-ks2026.2.1-sds1.4-sberlinux.tgz в той же папке.
Проверка работоспособности региона¶
Перед тем как приступать к обновлению, необходимо проверить состояние облачной инфраструктуры. Эта проверка необходима для минимизации рисков и поддержания стабильности системы. Проверка работоспособности региона позволяет убедиться, что виртуальные машины создаются и доступны по сети, что подтверждает работоспособность цепочки сервисов (MariaDB, HAProxy, Cinder, Nova, Neutron, Glance).
Подключитесь к интерфейсу OpenStack CLI.
Проверьте сетевую доступность всех узлов облака с помощью команды
ping.Выполните команду
openstack compute service listдля проверки состояния вычислительных сервисов. Убедитесь, что все сервисы находятся в состоянииup.Выполните команду
openstack volume service listдля проверки состояния службы томов. Убедитесь, что все сервисы находятся в состоянииup.Выполните команду
openstack server listдля проверки состояния виртуальных машин.Используя Портал администратора или OpenStack CLI, а при использовании Ubuntu — также портал самообслуживания Horizon, создайте несколько ВМ с различными флейворами и выполните их живую миграцию.
Очистка устаревшего параметра Neutron¶
Начиная с ks2026.1 параметр global_physnet_mtu из конфигурационного файла config/neutron/neutron.conf добавлен в шаблон по умолчанию для Neutron. Поэтому можно удалить устаревшую строку из файла региона:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий региона project_k / deployments / <имя региона>.
Откройте файл
config/neutron/neutron.confи удалите строку:global_physnet_mtu = {{ global_physnet_mtu }}Сохраните изменения.
Отключение сервисов DRS и HA¶
Перед началом обновления необходимо отключить сервисы DRS и HA.
Для деактивации DRS:
Войдите в Портал администратора.
Перейдите в раздел .
Деактивируйте все задания сервиса DRS.
Для деактивации HA:
Зайдите на каждый Control-узел по SSH и выполните команду:
# systemctl stop kolla-consul-container.service
Настройка и обновление RabbitMQ¶
Перед обновлением региона необходимо выполнить обновление конфигурации RabbitMQ.
Настройка параметров RabbitMQ:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Откройте на редактирование файл
globals.d/rmq-tmp.yml, а если он отсутствует — создайте его. Исправьте или внесите новые строки:om_enable_queue_manager: true om_enable_rabbitmq_quorum_queues: true om_enable_rabbitmq_transient_quorum_queue: true om_enable_rabbitmq_stream_fanout: true om_enable_rabbitmq_high_availability: falseСоздайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение--skip-tags loadbalancer,prometheus,victoriametrics,mariadb,rabbitmq,opensearch,memcache,grafana,drs,consul.В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеgenconfig.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Остановите все службы OpenStack, использующие RabbitMQ, чтобы они пока не пытались пересоздать очереди.
Создайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение--tags common,keystone,cinder,nova,placement,glance,neutron,octavia,barbican,heat,adminui,hostmgmt,designate,ironic -e 'skip_stop_containers=["vhost"]' --yes-i-really-really-mean-it.В значение пустой переменной укажите
stop, в имя переменной —KOLLA_ANSIBLE_DEPLOY_ACTION, оригинальную строкуKOLLA_ANSIBLE_DEPLOY_ACTIONудалите.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Сброс состояния RabbitMQ:
Зайдите на каждый Control-узел по SSH и выполните команду:
# systemctl stop kolla-rabbitmq-container.service ; podman rm rabbitmq ; podman volume rm rabbitmqСоздайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение-e container_network_mode='host' -t rabbitmq.В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеdeploy.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Создайте новый пайплайн: .
В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеrabbitmq-reset-state.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Запустите все службы OpenStack, использующие RabbitMQ, чтобы они заново создали соответствующие очереди:
Создайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение--tags common,keystone,cinder,nova,placement,glance,neutron,octavia,barbican,heat,adminui,hostmgmt,designate,ironic.В значение пустой переменной укажите
deploy-containers, в имя переменной —KOLLA_ANSIBLE_DEPLOY_ACTION, оригинальную строкуKOLLA_ANSIBLE_DEPLOY_ACTIONудалите.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Зайдите на каждый узел по SSH и выполните команду:
$ podman ps -a | grep -v Up$ docker ps -a | grep -v UpУбедитесь, что вывод команды пустой либо содержит только пользовательские контейнеры. Все остальные контейнеры должны быть в запущенном состоянии (
Up).
Перевод MariaDB в режим host network:
Примечание
Выполните этот шаг только если обновление производится на ОС SberLinux
Зайдите на каждый Control-узел по SSH и проверьте, загружен ли модуль
br_netfilter:$ lsmod | grep br_netfilterЕсли модуль отсутствует в выводе команды, загрузите его:
$ sudo modprobe br_netfilterВыполните команду:
# sysctl -w net.bridge.bridge-nf-call-iptables=0Создайте новый пайплайн: .
В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеmariadb_recovery.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Переведите MariaDB в режим работы с host network:
Создайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение-e container_network_mode='host' -t mariadb.В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеdeploy.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Если обновление региона выполняется в рамках миграции на новый LCM, перед переключением региона на новый LCM (см. Руководство по обновлению) добавьте новые CA-сертификаты нового LCM в конфигурацию региона на старом LCM и запустите полное развёртывание региона — это необходимо, чтобы во время переключения на новый LCM сервисы региона уже доверяли новым сертификатам:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Добавьте новые CA-сертификаты нового LCM в файл
certificates/ca/ca-bundle.crtв репозитории региона на старом LCM.Создайте новый пайплайн: .
В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеdeploy.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Добавьте те же новые CA-сертификаты также в файл certificates/ca/ca-bundle.crt в репозитории региона на новом LCM.
Настройка GitLab¶
Измените конфигурацию пайплайна:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Откройте файл
.gitlab-ci.ymlв репозитории региона.В переменной
KEYSTACK_RELEASEукажите версию релиза, на которую производится обновление —ks2026.2.1:KEYSTACK_RELEASE: value: &KEYSTACK_RELEASE ks2026.2.1
Настройте таймаут для пайплайнов:
Перейдите в раздел .
Установите значение Timeout —
5h.
Обновление KeyStack на Control-узлах¶
Отредактируйте конфигурацию региона:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Откройте на редактирование файл
inventoryи измените группы:[tls-backend:children] control network compute storage monitoring [octavia:children] control [octavia-health-manager:children] network [octavia-worker:children] network [designate-mdns:children] designate [adminui-backend:children] control [adminui-frontend:children] controlДобавьте группы:
[nova-metadata:children] nova [prometheus-redfish-exporter:children] monitoring [prometheus-smartctl-exporter:children] monitoring control compute network storage [prometheus-pushgateway:children] monitoring [ovn-sb-db-relay:children] ovn-database [hostmgmt:children] control compute [vector:children] monitoring [adminui-hypervisor-exporter:children] compute [firewall:children] control network compute storage monitoring [temporal:children] control [patroni:children] control [keyvrm:children] control [keyvrm-server:children] keyvrm [keyvrm-worker:children] keyvrm [mcrouter:children] memcachedУдалите группы:
[adminui:children] control [swift:children] control # Swift [swift-proxy-server:children] swift [swift-account-server:children] storage [swift-container-server:children] storage [swift-object-server:children] storage [prometheus-hypervisor-exporter:children] computeОткройте на редактирование файл
globals.d/REGION.yml, удалите параметрkolla_internal_fqdn_cert.Если в репозитории региона присутствует файл
config/multipath.conf, удалите его.Обновите в Vault секрет
adminui_gitlab_password(secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml), указав в качестве значения текущий пароль технологической учётной записиks-admin(secret_v2 / deployments / <LCM FQDN> / secrets / accounts).Откройте на редактирование файл
globals.d/2526-tmp.ymlи добавьте следующие параметры для выключения TLS на время проведения процесса обновления:Примечание
Файл
globals.d/2526-tmp.ymlнеобходим только на время обновления. Если данные параметры уже включены в конфигурации ks2025.1.x, в любых конфигурационных файлахglobals.d/*.yml, оставьте их без изменений. После завершения процесса обновления данные параметры можно убрать для включения функций безопасности.libvirt_tls: "no" rabbitmq_enable_tls: "no" opensearch_enable_tls_backend: "no" kolla_enable_mtls_backend: "no" nova_qemu_vnc_tls: "no" kolla_enable_tls_external: "yes" kolla_enable_tls_internal: "yes" kolla_enable_tls_backend: "no" kolla_enable_mtls_external: "no" kolla_enable_mtls_internal: "no" enable_selinux_profiles: "no" selinux_state: "permissive" enable_podman_ro: "no"Если в конфигурационных файлах
globals.d/*.ymlвключены опцииenable_keyvrmилиenable_rbac_model, выключите их на время обновления, указав значения:enable_keyvrm: "no" enable_rbac_model: "no"В продукте по умолчанию выключены сервисы Octavia, Heat, Barbican и Designate. Если вы их используете, добавьте опции их включения:
enable_octavia: "yes" enable_barbican: "yes" enable_designate: "yes" enable_heat: "yes"Откройте на редактирование файл
globals.d/sds14-tmp.ymlи добавьте следующие временные теги:Примечание
Данный пункт предназначен только для обновления регионов, использующих Cloud SDS в качестве Storage.
В этом файле фиксируются промежуточные версии компонентов nova-compute, cinder-volume и glance-api, необходимых для возможности обновления Cloud SDS 1.3 → 1.4 → 1.5.
sds_14_tag: "ks2026.2.1-sds14-sberlinux" nova_compute_tag: "{{ sds_14_tag }}" cinder_volume_tag: "{{ sds_14_tag }}" glance_api_tag: "{{ sds_14_tag }}"
По умолчанию в ks2026.2.1 Prometheus Server выключен, включён VictoriaMetrics. Для продолжения работы с Prometheus Server добавьте в файл globals.d/REGION.yml параметр:
enable_prometheus_server: "yes"
Примечание
Если планируется использовать VictoriaMetrics, проверьте файлы globals.d/*.yml в репозитории региона на наличие параметра enable_victoriametrics: "no", оставшегося от предыдущих итераций конфигурации региона. Если такой параметр присутствует, удалите его или измените значение на "yes", иначе VictoriaMetrics не будет включён.
Запущенный сервис Prometheus Alertmanager заранее создаёт каталог данных Prometheus, что может приводить к ошибке переноса данных при выполнении пайплайна обновления региона на Control-узлах. Поэтому перед обновлением необходимо остановить сервис Prometheus Alertmanager, а также удалить автоматически созданную директорию prometheus/_data и всё её содержимое. Для этого перед запуском пайплайна обновления выполните следующие действия для каждого Control-узла по отдельности:
Зайдите на каждый Control-узел по SSH и выполните команду:
# systemctl stop kolla-prometheus_alertmanager-container.serviceКоманда остановит запущенный на узле Prometheus Alertmanager.
Выполните команду:
# rm -rf /var/lib/docker/volumes/prometheus/_data/*Команда удалит соответствующую директорию.
В случае использования Podman команда будет иметь следующий вид:
# rm -rf /var/lib/containers/storage/volumes/prometheus/_data/*
По умолчанию в ks2026.2.1 выключена поддержка serial console. Для её дальнейшего использования добавьте в файл globals.d/REGION.yml параметр:
enable_nova_serialconsole_proxy: "yes"
Для загрузки образов KeyStack в кеш узлов выполните следующие действия:
Примечание
Данный шаг опциональный и нужен для ускорения выполнения основного пайплайна обновления. Процедура загрузки образов может идти в фоновом режиме. НЕ нужно дожидаться её завершения для перехода к следующим шагам.
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Создайте новый пайплайн: .
В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеpull.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy.
Перед обновлением KeyStack на Control-узлах назначьте владельца директории логов ExaBGP:
Зайдите на каждый Control-узел по SSH и выполните команду:
# chown -R 43002 /var/log/kolla/exabgp
Для обновления KeyStack на Control-узлах выполните следующие действия:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Создайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение--limit control,storage. Это обеспечит выполнение пайплайна только для Control- и Storage-узлов.В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеupgrade.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Для установки служб Портала администратора и hostmgmt-агента выполните следующие действия:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Создайте новый пайплайн: .
Оставьте ветку по умолчанию, соответствующую установленному релизу.
В переменной
KOLLA_ARGSукажите значение--tags hostmgmt,adminui.В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеdeploy.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Для удаления более неиспользуемых сервисов KeyStack выполните следующие действия:
Убедитесь, что в файлах
globals.d/*.ymlотсутствуют параметры, удалите если есть:enable_drs: "yes" enable_consul: "yes"Зайдите на каждый Control-узел по SSH и выполните команду:
# systemctl disable --now kolla-drs-container.service kolla-consul-container.service kolla-prometheus_consul_exporter-container.service ; rm -f /etc/systemd/system/kolla-{consul,drs,prometheus_consul_exporter}-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm consul drs prometheus_consul_exporter ; podman volume rm consulКоманда остановит и удалит запущенные на узле службы consul (VMHA) и DRS.
Для удаления Horizon (в версии на SberLinux больше не поставляется) зайдите на каждый Control-узел по SSH и выполните команду:
# systemctl disable --now kolla-horizon-container.service ; rm -f /etc/systemd/system/kolla-horizon-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm horizonКоманда остановит и удалит запущенную на узле службу Horizon.
Зайдите на каждый Compute-узел по SSH и выполните команду:
# systemctl disable --now kolla-consul-container.service ; rm -f /etc/systemd/system/kolla-consul-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm consul ; podman volume rm consulКоманда остановит и удалит запущенную на узле службу consul (VMHA).
Обновление KeyStack на Network-узлах¶
Для обновления KeyStack на Network-узлах выполните следующие действия:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Создайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение--limit network. Это обеспечит выполнение пайплайна только для Network-узлов.В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеupgrade.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Обновление ОС на Control-узлах¶
Для настройки репозитория ОС выполните следующие действия:
Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Создайте новый пайплайн: .
Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу bootstrap-servers на этапе deploy и дождитесь её завершения.
Перед обновлением ОС на Control-узлах проверьте возможность обновления выбранных узлов, как описано в разделе Проверка возможности обновления.
Для обновления ОС на Control-узлах выполните действия, описанные в разделе Обновление контроллеров, выбрав компонент обновления ОС.
Обновление ОС и KeyStack на Compute-узлах¶
Для возможности обновления Compute-узлов через Портал администратора укажите на каждом Compute-узле текущую версию релиза:
Зайдите на Compute-узел по SSH.
Выполните команду:
# echo ks2025.1.x > /etc/keystack/ks_releaseгде
x— версия релиза, с которой выполняется обновление.Повторите действия для каждого Compute-узла.
Перед обновлением ОС на Compute-узлах проверьте возможность обновления выбранных узлов, как описано в разделе Проверка возможности обновления.
Для обновления KeyStack на Compute-узлах выполните действия, описанные в разделе Обновление гипервизоров, выбрав компонент обновления ОС+KeyStack.
Завершение обновления KeyStack¶
Примечание
Данный этап можно выполнять только после успешного обновления всех Compute-узлов
Для завершения обновления KeyStack и включения всех функций безопасности выполните следующие шаги:
Удалите временные файлы из конфигурационного репозитория региона:
globals.d/2526-tmp.ymlиglobals.d/rmq-tmp.yml.Включите опции
enable_keyvrmиenable_rbac_model, указав в соответствующих файлахglobals.d/*.ymlзначения:enable_keyvrm: "yes" enable_rbac_model: "yes"Включите опцию
enable_vector_webhook_alertmanager, указав в файлеglobals.d/hpsm.ymlзначения:enable_vector_webhook_alertmanager: "yes"Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Создайте новый пайплайн: .
В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеdeploy.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу bootstrap-servers на этапе deploy и дождитесь её завершения.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Остановите и удалите сервисы контейнеров kolla-prometheus_hypervisor_exporter-container.service и kolla-prometheus_rabbitmq_exporter-container.service:
Зайдите на каждый Compute-узел по SSH.
Выполните команды:
# systemctl disable --now kolla-prometheus_hypervisor_exporter-container.service ; rm -f /etc/systemd/system/kolla-prometheus_hypervisor_exporter-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm -f prometheus_hypervisor_exporter ; podman volume rm --force prometheus_hypervisor_exporterЗайдите на каждый Control-узел по SSH.
Выполните команды:
# systemctl disable --now kolla-prometheus_rabbitmq_exporter-container.service ; rm -f /etc/systemd/system/kolla-prometheus_rabbitmq_exporter-container.service ; systemctl daemon-reload ; systemctl reset-failed ; podman rm -f prometheus_rabbitmq_exporter ; podman volume rm --force prometheus_rabbitmq_exporter
Примечание
Данный этап можно выполнять только после успешного обновления кластера Cloud SDS до версии 1.4.х
Для завершения обновления драйверов Cloud SDS выполните следующие шаги:
Удалите временный файл из конфигурационного репозитория региона
globals.d/sds14-tmp.yml.Зайдите в веб-интерфейс GitLab.
Перейдите в репозиторий project_k / deployments / <имя региона>.
Создайте новый пайплайн: .
В переменной
KOLLA_ARGSукажите значение-t nova-cell,cinder,glance.В переменной
KOLLA_ANSIBLE_DEPLOY_ACTIONукажите значениеdeploy.Запустите пайплайн New pipeline.
Дождитесь завершения задач на этапе setup.
Запустите задачу host-config на этапе postconfig и дождитесь её завершения.
Запустите задачу deploy на этапе deploy и дождитесь её завершения.
Каталог конфигурации Kolla автоматически перенесён с /etc/kolla на /opt/kolla. Удалите оставшиеся в /etc/kolla устаревшие файлы. Для этого зайдите на каждый узел по SSH и выполните команду:
# rm -rf /etc/kolla