Обновление Ingress‑контроллера NGINX с сервисами Вебмониторэкс¶

Инструкция описывает способ обновления Ingress‑контроллера Вебмониторэкс версии 4.x до новой версии с нодой 4.6.

Требования¶

• Kubernetes версии 1.26-1.28

• Менеджер пакетов Helm

• Совместимость сервисов с Community Ingress‑контроллером NGINX версии 1.9.5 или ниже

• Доступ к аккаунту с ролью Администратор в Консоли управления Вебмониторэкс

• Доступ к https://api.wallarm.ru и https://api.webmonitorx.ru для работы с Вычислительным кластером Вебмониторэкс

• Доступ к https://charts.webmonitorx.ru для добавления Helm‑чартов Вебмониторэкс. Убедитесь, что доступ не ограничен настройками файервола

• Доступ к репозиториям Вебмониторэкс на Docker Hub https://wmx-public.gitlab.yandexcloud.net/wmx-public/container-images/container_registry. Убедитесь, что доступ не ограничен настройками файервола

• Доступ к хранилищу Яндекс S3 (https://storage.yandexcloud.net), чтобы обеспечить корректную блокировку IP‑адресов, зарегистрированных в странах, регионах или дата-центрах из белого, черного и серого списков IP

  Необходимо обеспечить доступ к https://storage.yandexcloud.net или нескольким диапазонам IP‑адресов: диапазон 1 и диапазон 2.

Шаг 1: Обновите репозиторий с Helm‑чартами Вебмониторэкс¶

helm repo update webmonitorx

Шаг 2: Проверьте все предстоящие изменения в манифестах Kubernetes¶

Чтобы избежать непредвиденных изменений в работе Ingress‑контроллера после обновления, проверьте все предстоящие изменения в манифестах Kubernetes.

Для этого мы рекомендуем использовать плагин Helm Diff Plugin. Плагин выведет разницу между манифестами Kubernetes в установленной версии контроллера и новой.

Чтобы установить и запустить плагин:

1. Установите плагин:

   helm plugin install https://github.com/databus23/helm-diff
   

2. Запустите плагин:

   helm diff upgrade <RELEASE_NAME> -n <NAMESPACE> webmonitorx/wallarm-ingress --version 4.6.0 -f <PATH_TO_VALUES>
   

   • <RELEASE_NAME>: название релиза с активным Ingress‑контроллером
   • <NAMESPACE>: пространство имен, в котором развернут Ingress‑контроллер
   • <PATH_TO_VALUES>: путь до файла values.yaml с настройками для Ingress‑контроллера 4.6, вы можете использовать файл, созданный для первичного деплоя Ingress-контроллера

3. Убедитесь, что никакие изменения не повлияют на стабильность запущенных сервисов, и внимательно изучите ошибки из stdout.

   Если stdout команды пустой, убедитесь в валидности values.yaml.

Шаг 3: Обновите Ingress-контроллер¶

Вы можете обновить Ingress‑контроллер одним из трех способов. Выбор зависит от того, используется ли в вашей инфраструктуре балансировщик нагрузки. Возможны следующие способы обновления:

• Установка временного Ingress‑контроллера

• Обычное пересоздание релиза Ingress‑контроллера

• Пересоздание релиза Ingress‑контроллера с сохранением балансировщика нагрузки

Способ 1: Установка временного Ingress‑контроллера¶

Вы можете развернуть Ingress‑контроллер 4.6 как дополнительную сущность в инфраструктуре и переключать на нее трафик постепенно. Это позволит избежать даже временной деградации сервисов и обеспечит безопасную миграцию.

1. Скопируйте конфигурацию IngressClass из values.yaml Ingress‑контроллера предыдущей версии в values.yaml для Ingress‑контроллера 4.6.

   Таким образом новый Ingress‑контроллер идентифицирует объекты Ingress, а трафик на новый Ingress‑контроллер поступать не будет.

2. Установите Ingress‑контроллер 4.6:

   helm install <RELEASE_NAME> -n <NAMESPACE> webmonitorx/wallarm-ingress --version 4.6.0 -f <PATH_TO_VALUES>
   

   • <RELEASE_NAME>: название релиза с Ingress‑контроллером 4.6, отличное от релиза с Ingress‑контроллером предыдущей версии.
   • <NAMESPACE>: пространство имен, в котором развернут Ingress‑контроллер предыдущей версии.
   • <PATH_TO_VALUES>: путь до файла values.yaml с настройками для Ingress‑контроллера 4.6 и настройкой IngressClass из пункта 1.

3. Убедитесь, что все сервисы работают корректно.

4. Постепенно переключите нагрузку на новый Ingress‑контроллер.

Способ 2: Обычное пересоздание релиза Ingress‑контроллера¶

Если балансировщик нагрузки и Ingress‑контроллер НЕ описаны в одном Helm‑чарте, для обновления достаточно пересоздать Helm‑релиз. Пересоздание релиза займет несколько минут, Ingress‑контроллер будет недоступен это время.

Для пересоздания релиза Ingress‑контроллера:

```

Способ 3: Пересоздание релиза Ingress‑контроллера с сохранением балансировщика нагрузки¶

Рекомендуем обновить модули этим способом, если вы используете балансировщик нагрузки, настроенный облачным провайдером. Этот способ не затрагивает обновление балансировщика нагрузки. Пересоздание релиза займет несколько минут, Ingress‑контроллер будет недоступен это время.

1. Получите список объектов, которые будут удалены (за исключением балансировщика нагрузки):

   helm get manifest <RELEASE_NAME> -n <NAMESPACE> | yq -r '. | select(.spec.type != "LoadBalancer") | .kind + "/" + .metadata.name' | tr 'A-Z' 'a-z' > objects-to-remove.txt
   

   Если утилита yq еще не установлена, установите ее по инструкции.

   Список объектов для удаления будет выведен в файл objects-to-remove.txt.

2. Удалите полученные объекты и обновите релиз:

   cat objects-to-remove.txt | xargs kubectl delete --wait=false -n <NAMESPACE>    && \
   helm upgrade <RELEASE_NAME> -n <NAMESPACE> webmonitorx/wallarm-ingress --version 4.6.0 -f `<PATH_TO_VALUES>`
   

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

3. Убедитесь, что все объекты созданы:

   helm get manifest <RELEASE_NAME> -n <NAMESPACE> | kubectl create -f -
   

   Выводом команды должно быть сообщение о том, что все объекты уже существуют.

В командах передаются следующие параметры:

• <RELEASE_NAME>: название релиза с Ingress‑контроллером

• <NAMESPACE>: пространство имен, в котором развернут Ingress‑контроллер

• <PATH_TO_VALUES>: путь до файла values.yaml с настройками для Ingress‑контроллера 4.4

Шаг 4: Протестируйте обновление¶

1. Убедитесь, что чарт обновлен:

   helm ls
   

   Версия чарта должна соответствовать wallarm-ingress-4.6.0.

2. Получите список pod'ов, передав в <INGRESS_CONTROLLER_NAME> название Ingress‑контроллера Вебмониторэкс:

   kubectl get pods -l release=<INGRESS_CONTROLLER_NAME>
   

   Все pod'ы должны быть в состоянии: STATUS: Running и READY: N/N. Например:

   NAME                                                              READY     STATUS    RESTARTS   AGE
   ingress-controller-nginx-ingress-controller-675c68d46d-cfck8      4/4       Running   0          5m
   ingress-controller-nginx-ingress-controller-wallarm-tarantljj8g   4/4       Running   0          5m
   

3. Отправьте тестовый запрос с атакой Path Traversal на адрес Ingress‑контроллера Вебмониторэкс:

   curl http://<INGRESS_CONTROLLER_IP>/etc/passwd
   

   Если нода находится в статусе block, в ответ на запрос вернется код 403 Forbidden и атака отобразится в Консоли управления Вебмониторэкс → секция События.