Обновление системы

В данном разделе описаны действия по обновлению системы или сателлита.

Обновление состоит из следующих этапов:

Если к основному экземпляру системы подключены сателлиты, нужно обновить их после обновления основного экземпляра системы. Инструкция по обновлению сателлитов приведена в разделе Обновление сателлитов.

Подготовка к обновлению

Перед обновлением системы до новой версии выполните подготовительные действия:

  1. Проверьте соответствие программных и аппаратных требований для работы установщика новой версии системы.

  2. Скачайте архив с файлами для установки новой версии системы и проверьте его целостность.

При обновлении системы с определенных версий имеется ряд особенностей:

Особенности обновления системы с версии ниже 2.0.0

В системе версии ниже 2.0.0 может возникать ошибка при просмотре логов коллектора в интерфейсе:

Не удалось получить логи коллектора.
connect ECONNREFUSED <...>

В логах пода loki-gateway отображается ошибка:

host not found in resolver "coredns.kube-system.svc.cluster.local." in /etc/nginx/nginx.conf:33

Причина: чарт Loki по умолчанию использует имя coredns для конфигурации разрешения имен пода loki-gateway, однако в кластере может использоваться другое имя для сервиса DNS — например, kube-dns.

В системе версии 2.0.0 и выше данный параметр определяется автоматически, но при обновлении с более старой версии проблема может воспроизводиться, поэтому перед обновлением следует ее устранить.

Решение: нужно исправить конфигурацию сервиса loki-gateway. Для этого:

  1. Получите фактическое имя DNS-сервиса:

    K8S_DNS_SERVICE="$(kubectl get service -n kube-system -l k8s-app=kube-dns -o 'jsonpath={.items..metadata.name}')"
  2. Получите конфигурацию loki-gateway:

    LOKI_CONFIG="$(get cm loki-gateway -n kube-prometheus-stack -o 'jsonpath={.data.nginx\.conf}')"
  3. Сравните имена DNS-сервисов:

    echo "K8s DNS: $K8S_DNS_SERVICE"
    echo "Loki DNS: $(echo "$LOKI_CONFIG" | grep resolver)"
    Пример вывода имен DNS-сервисов
    K8s DNS: kube-dns
    Loki DNS: resolver coredns.kube-system.svc.cluster.local.;

    Если в выводе имена сервисов разные, перейдите к шагу 4.

  4. Откройте ConfigMap loki-gateway:

    KUBE_EDITOR=nano kubectl edit configmap/loki-gateway -n kube-prometheus-stack

    Замените имя DNS-сервиса coredns после resolver на значение переменной K8S_DNS_SERVICE. После исправления строка ConfigMap должна принять вид:

    resolver <dns_name>.kube-system.svc.cluster.local.;

    Здесь:

    • <dns_name> — имя DNS-сервиса Kubernetes, полученное на шаге 3, например, kube-dns.

  5. Сохраните файл и перезапустите loki-gateway:

    kubectl rollout restart deployment/loki-gateway -n kube-prometheus-stack
Особенности обновления системы с версии ниже 2.3.0

Начиная с версии 2.3.0 система поставляется на базе платформы R-Vision EVO.

Обновление системы с версий ниже 2.3.0 требует ручных действий.

Выключение коллекторов

Перед обновлением системы с версии ниже 2.3.0 необходимо выключить все работающие коллекторы.

После обновления все необходимые коллекторы и конвейеры нужно будет включить вручную.

Создание общей БД PostgreSQL

Сервисы платформы могут использовать как общую БД, так и собственные. В установщиках системы версий ниже 2.3.0 общая БД отсутствует. Необходимо создать ее вручную с помощью команды:

kubectl exec -n <namespace> sts/postgresql -- psql -U <username> -d postgres -c 'CREATE DATABASE evo;'

Здесь:

  • <namespace> — название пространства имен, в котором установлена система.

  • <username> — имя пользователя PostgreSQL, которое было указано при установке системы.

Имя пользователя PostgreSQL можно получить из секрета evo.siem.global, выполнив следующую команду:

kubectl -n <namespace> get secrets evo.siem.global -o jsonpath='{.data.POSTGRES_USER}' | base64 -d

Здесь:

  • <namespace> — название пространства имен, в котором установлена система.

Обновление NATS

Начиная с версии 2.2.0 в поставку системы входит NATS. При обновлении с 2.2.x необходимо предварительно удалить предыдущие helm-релизы NATS, чтобы избежать ошибок. Для этого:

  1. Удостоверьтесь, что NATS развернут в необходимом пространстве имен:

    helm list -n <namespace> | grep nats-
  2. Удалите nats-main и nats-bridge при их наличии:

    helm uninstall -n <namespace> nats-bridge
    helm uninstall -n <namespace> nats-main

Здесь:

  • <namespace> — название пространства имен, в котором установлена система.

Устранение проблем при обновлении

При обновлении системы установщик выполняет ряд специфичных действий по переносу конфигурационных параметров в платформу.

Если во время обновления системы произошел сбой, выполните следующие действия:

  1. Удалите метаданные модулей, которые успели развернуться до сбоя:

    kubectl get cm -n <namespace> -o name | grep release-info | xargs -n1 -t kubectl delete -n <namespace>
  2. Запустите обновление повторно без распаковки дистрибутива:

    export PATH=$PATH:/opt/r-vision/common/bin
    evoctl instance update -v

Добавление разрешений

При обновлении системы с версии ниже 2.3.0 в пользовательских ролях сбрасываются все разрешения. После обновления необходимо заново настроить разрешения ролей.

Особенности обновления системы с версии ниже 2.3.3

Начиная с версии 2.3.3 названия схем активных списков и таблиц обогащения не могут содержать точки.

Перед обновлением системы с версии ниже 2.3.3 удостоверьтесь, что ни одна схема активного списка или таблица обогащения не содержит точки в названии. Если такие схемы или таблицы имеются, необходимо создать их новые версии без точек в названии, а старые версии удалить.

Особенности обновления системы с версии ниже 2.4.0

После обновления системы с версии ниже 2.4.0 тип существующих точек входа HTTP Client изменится на HTTP Client_deprecated в связи с их функциональными обновлениями.

Для обновления точек входа HTTP Client:

  1. Измените тип существующих точек входа HTTP Client_deprecated в конвейерах на обновленный тип без суффикса _deprecated.

  2. Удалите устаревший тип точки входа из таблицы entry_point_type в базе данных коллекторов PostgreSQL. Для этого:

    1. Подключитесь к терминалу master-узла кластера.

    2. Подключитесь к PostgreSQL, выполнив следующую команду:

      kubectl exec -it -n <namespace> postgresql-0 sh

      Здесь:

      • <namespace> — название пространства имен, в котором установлена система.

    3. Подключитесь к базе данных коллекторов:

      psql -U postgres -d collector
    4. Удалите из таблицы entry_point_type устаревший тип точки входа:

      delete from "entry_point_type" where "name" like '%_deprecated';
Особенности обновления системы с версии ниже 2.5.0

При обновлении системы с версии ниже 2.5.0 необходимо обновить ClickHouse до поддерживаемой версии.

Особенности обновления системы с версии ниже 2.6.0

Обновление системы с версий ниже 2.6.0 требует ручных действий.

Сохранение настроек стримов в менеджере пространств

При обновлении системы с версии ниже 2.6.0 настройки стримов в менеджере пространств автоматически принимают значения по умолчанию.

Чтобы не потерять изменения, внесенные в настройки стримов, перед обновлением системы сохраните их в секрет evo.space.global. Для этого выполните следующую команду для каждой измененной переменной окружения:

kubectl patch secret evo.space.global -n evo-namespace -p='{"stringData":{"<env_var>": "<value>"}}'

Здесь:

  • <env_var> — переменная окружения, новое значение которой необходимо сохранить. Например: NATS_CONFIGURATOR_GLOBAL_OBJECTS_OS_MAX_SIZE.

  • <value> — новое значение переменной окружения. Например: 512MB.

Список переменных окружения с настройками стримов и их значения по умолчанию приведены в разделе Настройка стримов в менеджере пространств.

Обновление Microsoft Visual C++

Начиная с версии 2.6.0 агенты в ОС Windows совместимы с Microsoft Visual C++ 14.29 и выше. Если ваши агенты работают на хостах с ОС Windows, при обновлении системы с версии ниже 2.6.0 обновите Microsoft Visual C++ до версии не ниже 14.29.

Создание таблиц асинхроннных метрик в вынесенном ClickHouse

Если вы используете вынесенный ClickHouse, после обновления системы выполните следующие запросы в терминале ClickHouse:

GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'reader';
CREATE TABLE IF NOT EXISTS default.asynchronous_metrics ON CLUSTER '{cluster}' AS system.asynchronous_metrics ENGINE = Distributed('{cluster}', system, asynchronous_metrics);

Переход на новые точки входа R-Vision Endpoint

Начиная с версии 2.6.0 тип точек входа R-Vision Endpoint заменен на R-Vision Endpoint_deprecated в силу функционального устаревания, а R-Vision EVO Endpoint — на R-Vision Endpoint.

После обновления системы с версии ниже 2.6.0 рекомендуется перейти со старых точек входа R-Vision Endpoint_deprecated на новые — R-Vision Endpoint. Для этого:

  1. Удалите агенты R-Vision Endpoint и установите системные агенты согласно инструкции в разделе Переход с агентов R-Vision Endpoint на системные агенты.

  2. Измените тип существующих точек входа R-Vision Endpoint_deprecated в конвейерах на обновленный тип без суффикса _deprecated и укажите домен для подключения к шлюзу. Подробности приведены в описании точки входа R-Vision Endpoint.

  3. Удалите устаревший тип точки входа из таблицы entry_point_type в базе данных коллекторов PostgreSQL. Для этого:

    1. Подключитесь к терминалу master-узла кластера.

    2. Подключитесь к PostgreSQL, выполнив следующую команду:

      kubectl exec -it -n <namespace> postgresql-0 sh

      Здесь:

      • <namespace> — название пространства имен, в котором установлена система.

    3. Подключитесь к базе данных коллекторов:

      psql -U postgres -d collector
    4. Удалите из таблицы entry_point_type устаревший тип точки входа:

      delete from "entry_point_type" where id = 'f7183617-e756-4fa9-9f59-bd2c2529625c';

Включение поиска по нескольким хранилищам событий

Для работы поиска по нескольким хранилищам событий выполните процедуру пересоздания таблиц хранилищ:

  1. Подключитесь к терминалу master-узла кластера.

  2. Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:

    kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env

    Здесь:

    • <namespace> — название пространства имен, в котором установлена система.

  3. Измените значение переменной EVO_STREAMS_EVENT_STORAGE_MANAGER_RECREATE_EVENT_STORAGES на "true".

    Пересоздание таблиц хранилищ событий занимает некоторое время. В процессе пересоздания liveness-пробы сервиса evo.streams.event-storage-manager могут завершиться с ошибкой, что приведет к циклическому перезапуску этого сервиса. Во избежание такого поведения рекомендуется увеличить интервал между liveness-пробами, выполнив следующие действия:

    1. Откройте конфигурацию контроллера Deployment evo.streams.event-storage-manager, выполнив следующую команду:

      kubectl -n <namespace> edit deployment evo.streams.event-storage-manager

      Здесь:

      • <namespace> — название пространства имен, в котором установлена система.

    2. Скопируйте и сохраните текущие значения параметров в секции livenessProbe.

      Пример содержимого секции livenessProbe
      livenessProbe:
        grpc:
          port: 3000
          service: ''
        initialDelaySeconds: 10
        timeoutSeconds: 3
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 3
    3. Увеличьте значения параметров timeoutSeconds, periodSeconds и failureThreshold.

    4. Сохраните изменения.

    После перезапуска сервиса evo.streams.event-storage-manager рекомендуется восстановить настройки liveness-проб по умолчанию.

  4. Удалите под сервиса evo.streams.event-storage-manager, выполнив следующую команду:

    kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.streams.event-storage-manager

    Под будет пересоздан автоматически.

  5. Дождитесь, когда под evo.streams.event-storage-manager перейдет в статус Running. Инструкция по проверке статуса пода приведена в разделе Просмотр состояния подов кластера.

  6. Когда под перейдет в статус Running, перейдите в веб-интерфейс системы и убедитесь, что поиск по хранилищам событий выполняется успешно и события поступают в хранилища.

  7. Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:

    kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env

    Здесь:

    • <namespace> — название пространства имен, в котором установлена система.

  8. Измените значение переменной EVO_STREAMS_EVENT_STORAGE_MANAGER_RECREATE_EVENT_STORAGES обратно на "false".

  9. Если вы меняли интервал liveness-проб, восстановите интервал по умолчанию в конфигурации evo.streams.event-storage-manager. Ее можно открыть, выполнив следующую команду:

    kubectl -n <namespace> edit deployment evo.streams.event-storage-manager

    Здесь:

    • <namespace> — название пространства имен, в котором установлена система.

Обновление системы

Чтобы обновить систему до новой версии:

  1. Запустите установщик и выберите режим установки Updating previous version.

    install updating

    При выборе обновления выполняется распаковка пакетов в каталог продукта и управление передается скрипту установщика.

  2. Выберите пространство имен, в котором установлена система.

  3. Задайте параметры Ansible:

    1. Имя пользователя.

    2. Метод аутентификации: через ключ или по паролю.

    3. Пароль: задайте и подтвердите пароль пользователя.

В целевом пространстве имен будут обновлены все чарты модуля Streams.

После обновления системы убедитесь, что у вас установлена поддерживаемая версия ClickHouse. Если ваша версия ClickHouse отличается от поддерживаемой, обновите ClickHouse до требуемой версии.

После обновления на экран будет выведен URL-адрес для подключения к системе.

Обновление сателлитов

После обновления основного экземпляра системы необходимо обновить все подключенные к нему сателлиты. Чтобы обновить сателлиты, выполните следующие действия на каждом из них:

  1. Скопируйте архив TLS-сертификатов $SETUP_ROOT_DIR/r-vision/nats-tls.tar.gz из основного экземпляра системы в каталог $SETUP_ROOT_DIR/r-vision сателлита.

    Каталоги установки (значения переменной $SETUP_ROOT_DIR) основного экземпляра системы и сателлита могут отличаться.
  2. Обновите сателлит с помощью установщика аналогично основному экземпляру системы.

Авторизация в системе

Чтобы выполнить вход в систему:

  1. В адресной строке браузера введите URL-адрес, выведенный на экран после обновления системы. На экране отобразится страница авторизации.

  2. Укажите логин и пароль учетной записи пользователя и нажмите на кнопку Войти.

Если вы обновляли сателлиты, после обновления может потребоваться перезапуск выполняющихся на них коллекторов и сервисов из интерфейса основного экземпляра системы.

Была ли полезна эта страница?

Обратная связь