Обзор
В Nova Container Platfor есть возможность установить сервис OpenSearch, который автоматически начинает собирать логи кластера.
1. Архитектура
1.1. Компоненты модуля
Модуль OpenSearch в кластере Nova Container Platform включает компоненты, представленные в таблице ниже:
Компонент |
Категория |
Количество |
Opensearch |
Кластерный компонент |
1 |
Opensearch Dashboard |
Кластерный компонент |
1 |
Provisioner |
Кластерный компонент |
1 |
FluentbitAgent |
Хостовой компонент (агент) |
1 на узел |
HostTailer |
Хостовой компонент (агент) |
1 на узел |
Fluentd |
Кластерный компонент |
1 |
Компоненты OpenSearch являются контейнерами, которые взаимодействуют как между собой, так и с кластером Kubernetes и его узлами. Все компоненты OpenSearch запускаются и функционируют в среде Kubernetes.
-
Opensearch: основной компонент. В Nova Container Platform контроллер разворачивается в виде сущности StatefulSet. Также контроллер предоставляет REST API для управления сущностями OpenSearch.
-
Opensearch Dashboard: компонент предоставляет веб-интерфейс для управления сущностями Opensearch.
-
Provisioner: компонент, запускаемый однократно в виде сущности Job для первоначальной настройки Opensearch.
-
FluentbitAgent: хостовый компонент (агент), который разворачивается в виде сущности DaemonSet на каждом узле кластера Kubernetes. Предназначен для сбора логов с контейнеров.
-
HostTailer: аналог FluentbitAgent, но настроенный на сбор логов с узлов кластера.
-
Fluentd: компонент сервиса сборщика логов. Предназначен для сбора логов с Fluentd в соответствии с заданными правилами (в виде Custom Resources
FlowиOutput) и отправки их в Opensearch.
1.2. Предварительно настроенные параметры
При установке модуля OpenSearch происходит установка Fluentd, его агентов и правил для сбора логов кластера.
В таблице представлены настройки для сбора и отправки логов в OpenSearch с использованием Logging Operator.
Имя ресурса |
Тип ресурса |
Название индекса в OpenSearch |
|
Flow |
|
|
Output |
|
|
Flow |
|
|
Output |
|
|
Flow |
|
|
Output |
|
|
Flow |
|
|
Output |
|
|
ClusterFlow |
|
|
ClusterOutput |
|
Также устанавливается дашборд в Grafana в виде ConfigMap nova-grafana-dashboard-opensearch, который размещается в Namespace nova-monitoring, и используется для визуализации и мониторинга основных метрик OpenSearch.
1.3. Предварительно настроенные параметры внутри OpenSearch
После применения Kustomization необходимо дождаться его успешного завершения. В результате установки в кластер OpenSearch будут импортрованы следующие сущности:
-
Index pattern
-
nova-k8s-audit-apiserver-* - Аудит лог Kubernetes. Собирается с каждого мастер-узла;
-
nova-node-audit-* - Аудит лог системы. Собирается с каждого узла кластера;
-
nova-kubelet-* - Аудит лог kubelet. Собирается с каждого узла кластера;
-
nova-starvault-audit-logs* - Аудит лог StarVault.
-
-
Dashboards
-
[Nova] Kubernates API audit log
-
[Nova] StarVault audit logs
-
-
Policies
-
nova_policy_1
-
-
Templates
-
nova-base-template
-
|
Для доступа ко всем вышеперечисленным ресурсам, необходимо сменить Tenant с Private на Global. |
2. Высокая доступность и непрерывность работы
Для обеспечения высокой доступности и непрерывной работы компонентов OpenSearch рекомендуется увеличить количество реплик OpenSearch и Opensearch Dashboard. Это необходимо для предотвращения прерывания работы сервисов в случае недоступности отдельных узлов или при перезапуске сервисов.
Далее рассмотрены особенности работы каждого компонента OpenSearch в режиме высокой доступности.
Opensearch
Для повышения доступности Opensearch рекомендуется устанавливать модуль в рекомендуемой конфигурации.
Opensearch Dashboard
Веб-интерфейс управления сущностями Opensearch взаимодействует с контроллером через REST API и не влияет на работу ключевых сервисов Opensearch. Для повышения доступности рекомендуется устанавливать модуль в рекомендуемой конфигурации. Поддерживается постоянство пользовательских сессий с помощью настройки балансировки в Ingress Controller (nginx.ingress.kubernetes.io/upstream-hash-by: "$binary_remote_addr").
Provisioner
Компонент Provisioner является сущностью типа Job в Kubernetes и запускается только один раз при первоначальной установке, поэтому для него высокая доступность и большое количество реплик не требуются.
FluentbitAgent
Разворачивается в виде сущности DaemonSet на каждом узле кластера Kubernetes, поэтому сценарий с увеличением реплик здесь не применим.
HostTailer
Разворачивается в виде сущности DaemonSet на каждом узле кластера Kubernetes, поэтому сценарий с увеличением реплик здесь не применим.
Fluentd
Компонент требует обязательного увеличения количества реплик, если вы обрабатываете большой объем логов.