Руководство оператора#

Термины и определения#

Термин/аббревиатура

Определение

Граничный прокси / IGEG

Компонент Граничный прокси Platform V Synapse Service Mesh

Platform V Synapse Service Mesh

Программный продукт на базе Istio SE, обеспечивающий возможность создания сервисной сети поверх Платформенной в Kubernetes

Istio SE

Настраиваемая сервисная сетка с открытым исходным кодом, служащая для взаимодействия, мониторинга и обеспечения безопасности контейнеров в кластере Kubernetes

Доступ к приложению#

Компонент Граничный прокси не имеет пользовательского интерфейса. В процессе эксплуатации оператор с правами на чтение не имеет доступа к управлению и настройке граничного прокси. Оператор c правами на просмотр имеет доступ к записям системного журнала граничного прокси. Доступ определяется ролями, определенными для пользователя настройками RoleBindings в кластере Kubernetes.

Использование приложения оператором#

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

К типовым действиям пользователя можно отнести:

  1. Увеличение или уменьшение количества Pods.

  2. Просмотр логов приложения для проверки успешности запроса.

Для выполнения данных действий пользователь должен иметь права администратора в namespace, определенные ролями k8s.

Сценарий 1. Изменение количества Pods#

Через пользовательский интерфейс кластера k8s

  1. Выбрать нужный проект.

  2. В меню выбрать пункт Workload/Deployments.

  3. На странице найти нужный Deployment (при необходимости воспользоваться поиском по имени).

  4. Нажать ⋮ и выбрать Scale.

  5. Задать нужно количество Pods и нажать Scale.

Auth

Auth

Сценарий 2. Проверка логов в Pod#

  1. Зайти в нужный проект.

  2. В меню выбрать пункт Workload/Pods.

  3. На странице найти нужный Pod.

  4. Перейти по сcылке в этот Pod.

  5. Перейти на вкладку ≡ (Logs). В консоли не должно быть ошибок.

Auth

  1. Корректным условием является отсутствие логов с ошибками и запись: Info Envoy proxy is ready:

Auth

Также можно сделать это через консоль.

Для этого достаточно выполнить команду kubectl --kubeconfig=<путь_к_kubeconfig> -n <имя_проекта> logs <имя Pod>

Пример:

Auth

Часто встречающиеся проблемы и пути их устранения#

Проблема

Пути решения

Граничный прокси не может подключиться к компоненту POLM, в системном журнале видно сообщение Envoy proxy is NOT ready

Проверьте корректность подключения к контрольной панели Synapse Service Mesh.
Проверьте значения переменных окружения PROXY_CONFIG и CA_ADDR — в них должен быть указан корректный адрес сервиса istiod (из состава POLM)
Обратитесь к системным администраторам контрольной панели Synapse Service Mesh

До прикладного приложения не доходят запросы

Проверьте access-логи граничного прокси. Возможные варианты сообщений описаны ниже

В access-логе граничного прокси видно сообщение:
NR (No route configured):
В конфигурации граничного прокси отсутствует требуемый маршрут

Авторизуйтесь в прикладном проекте. Если вызов направлен на внутренний сервис, проверьте наличие сервиса с таким именем, проверьте корректность параметров host/порт в конфигурационных файлах прикладного проекта — Gateway, DestinationRule и VirtualService. Если вызов направлен на внешний host, проверьте наличие конфигурационного файла ServiceEntry для данного сочетания host/порт

В access-логе граничного прокси видно сообщение:
UO (Upstream overflow with circuit breaking):
Поставщик перегружен запросами

Авторизуйтесь в прикладном проекте. Проверьте корректность конфигурации раздела connectionPoolSettings в DestinationRule

В access-логе граничного прокси видно сообщение:
UF (Failed to connect to upstream):
Поставщик сбросил соединение

Авторизуйтесь в прикладном проекте. Если вы используете автоматическую аутентификацию ISTIO_MUTUAL, проверьте наличие конфликта в разделе trafficPolicy конфигурационного файла DestinationRule, относящегося к проблемному сервису, и раздела Spec/mtls конфигурационного файла peerAuthentication. В случае указания разных режимов работы в поле tls - возможны указанные ошибки

В access-логе граничного прокси видно сообщение:
UH (No healthy upstream):
Поставщик неработоспособен

Авторизуйтесь в прикладном проекте. Проверьте наличие вызываемого сервиса — в веб-интерфейсе Home/Networking/Services/Search_by_name найдите сервис. Проверьте наличие запущенного Pod, на который ссылается сервис — в веб-интерфейсе кликните правой кнопкой мыши на найденный сервис, выберите вкладку Pods на открывшейся странице, убедитесь, что статус Pods на данной странице имеет значение running

Если указанные пути решения не помогли, обратитесь к системным администраторам контрольной панели Synapse Service Mesh.

Ошибки TLS 1.2. Диагностика проблемы и обращение в поддержку#

В случае появления проблем с TLS 1.2 и при появлении ошибок в логах требуется выполнить проверки сертификатов. Перед обращением в поддержку требуется выполнить следующие команды проверки сертификатов в консоли, приложить отчет к тикету.

  1. От смежной системы получить: сертификат, цепочку корневых сертификатов.
  2. Установить консольное приложение openssl.
  3. Используя цепочку корневых сертификатов смежной системы провалидировать используемые сертификаты. 
    4. openssl verify -verbose -x509_strict -CAfile <CERT_CHAIN> <APP_CERT>

    где:

    • CERT_CHAIN — цепочка сертификатов смежной системы;

    • APP_CERT — сертификат, который прописан в Deployments Ingress/Egress.

    Пример корректного результата:

    $ openssl verify -verbose -x509_strict -CAfile cacert.pem clientcert.pem
clientcert.pem: OK

    Результат приложить скриншотом.

  4. Проверить сертификат смежной системы корневой цепочкой, которая используется на вашем Ingress/Egress.
  5. Проверить соответствие ключа сертификату: 
    openssl x509 -noout -modulus -in <APP_CERT> | openssl md5
openssl rsa -noout -modulus -in serverkey.pem | openssl md5

    где:

    • APP_CERT — сертификат, который прописан в deployments Ingress/Egress;

    • APP_KEY — ключ приложения, который прописан в deployments Ingress/Egress.

    Вывод данных команд должен совпадать. Вывод корректного результата:

    $ openssl rsa -noout -modulus -in serverkey.pem | openssl md5
f8570d29dfa7e9e59d018bd848c26420
$ openssl x509 -noout -modulus -in servercert.pem | openssl md5
f8570d29dfa7e9e59d018bd848c26420

    Результат приложить скриншотом.

  6. Приложить логи с Ingress/Egress
  7. Проверить настройки gateway, destinationRule, virtualService. Приложить Deployment
  8. Приложить версию образа, которая используется
  9. Предоставить информацию о смежной системе:
    • Какое поколение
    • Используется ли Ingress/Egress с настроенным mTLS 1.2
    Следующие два пункта опциональны, но ускорят диагностику:
    • Какой стек/библиотека какого языка используется
    • Предоставить ошибку на стороне смежной системы

Параметры настройки#

В процессе эксплуатации пользователь с правами на чтение (оператор) не имеет доступа к управлению и настройке граничного прокси.

Параметры настройки описаны в документации IGEG: «Руководство по системному администрированию», раздел «Сценарии администрирования».

Правила эксплуатации#

Компонент IGEG конфигурируется и эксплуатируется в соответствии с эксплуатационной документацией («Руководство по установке», «Руководство по системному администрированию», «Руководство оператора»).

Оператор имеет доступ к записям системного журнала граничного прокси в соответствии с предоставленными правами кластера Kubernetes.