Постепенно эволюционируя, каждая организация переходит от ручного grep логов к более современным инструментам для сбора, анализа логов. Если вы работаете с kubernetes, где приложение может масштабироваться горизонтально и вертикально, вас просто вынуждают отказаться от старой парадигмы сбора логов.  В  текущее время существует большое количество вариантов систем централизованного логирования, причем каждый выбирает наиболее приемлемый вариант для себя. В данной статье пойдет речь о наиболее популярном и зарекомендовавшем себя стэке Elasticsearch + Kibana + Fluentd в связке с плагином OpenDistro Security. Данный стэк полностью open source, что придает ему особую популярность. Нам необходимо было наладить сборку логов с кластера kubernetes.  Требования: Использование только открытых решений Сделать очистку логов. Аутентификация на базе LDAP  Данный материал предполагает:  Имеется установленный kuberenetes 1.18 или выше (ниже версию не проверяли) Установленный пакетный менеджер helm версии 3  Наиболее популярным способом установки приложения в kubernetes является helm. Helm это пакетный менеджер, с помощью которого можно подготовить набор компонентов для установки и связать их вместe, дополнив необходимыми метриками и конфигурацией. В своей практике мы используем helm chart от компании bitnami(подразделение vmware)   Преимущества такого решения: собраны open source продукты. стандарты по разработке чатов и докер образов красивая документация проект живой и активно поддерживается сообществом Во многом выбор стека технологий определило время.  С большой долей вероятностью два года назад мы бы деплоили ELK стек вместо EFK и не использовали helm chart.  Fluentd часто упоминается в документации, широко распространен, имеет большое количество плагинов, на все случаи жизни. К тому же у нас есть человек, который после обучение в rebrain и очень хотел внедрить fluentd.  Elasticsearch и kibana поставляются под открытой лицензией, однако плагины безопасности и другие "вкусности" идут под иной лицензией. Компания Amazon выпустила набор плагинов Open Distro, которые покрывают оставшийся функционал под открытой лицензией. Схема выглядит примерно так Хорошим тоном является вынесение инфраструктурных компонентов в отдельный кластер, поэтому зеленым прямоугольником выделена та часть, которая должна быть установлена на все кластера в которых должны собираться логи. Сборка EFK стека была произведена по статье Collect and Analyze Log Data for a Kubernetes Cluster with Bitnami's Elasticsearch, Fluentd and Kibana Charts. Компоменты упакованы в отдельный чат. Исходники можно взять здесь и произвести командой Из исходников values-minimal.yaml  Кибана будет доступна по адресу http://$(minikube ip):30010/, либо http://kibana.local.  Как видим компонент fluentd forwarder не включен. Перед включением парсинга, я рекомендовал бы настроить на определенные логи, иначе еластику может быть послано слишком большое количество логов.  Правила для парсинга описаны в файле apache-log-parser.yaml. Существует много способов, для начала предлагаем либо включить fluentd forwarder, либо воспользоваться простейшим приложением на python. Ниже пример для bare metal. Исправьте FLUENT_HOST FLUENT_PORT на ваши значения. По ссылке http://$(minikube ip):30011/ Будет выведено "Hello, world!"  И лог уйдет в elastic  Пример Включить fluentd forwarder, он создаст daemon set, т.е. запустится на каждой ноде вашего кубернетеса и будет читать логи docker container-ов.   Добавить в ваш докер контейнер драйвер fluentd, тем более можно добавлять более одного драйвера Добавить в ваше приложение библиотеку, которая будет напрямую логировать. Пример приложения на python. Используйте его, как отладочное средство при установке EFK.  И как показывает практика, логировать напрямую эффективный, но далеко не самый надежный способ. Даже если вы логируете сразу в fluentd и в консоль. В случае потери конекта, во fluentd часть логов просто не смогут попасть и будут потеряны для него навсегда. Поэтому наиболее надежный способ, это считывать логи с диска для отправки в EFK.     Для очистки логов используется curator. Его можно включить, добавив в values-minimal.yaml : По умолчанию его конфигурация уже предусматривает удаление индекса старше 90 дней, это можно увидеть в конфигурации внутри подчата efk/charts/elasticsearch-12.6.1.tgz!/elasticsearch/values.yaml  Как обычно security доставляет основную боль при настройке и использовании. Но если ваша организация чуть подросла, это необходимый шаг. Стандартом де факто при настройке безопасности является интеграция с LDAP.  Официальные плагины от еластика выходят не под открытой лицензией, поэтому приходится использовать плагин Open Distro. Далее продемонстрируем, как его можно запустить.  Сборка elasticsearch c плагином opendistro Вот проект в котором собирали docker images. Для установки плагина, необходимо, чтобы версия elasticsearch соответствовала  версии плагина. В quickstart плагина рекомендуется установить install_demo_configuration.sh с демо сертификатами.  Есть небольшая магия, ввиду, того что плагин дополняет elasticsearch.yml, а контейнеры bitnami только при старте генерируют этот файл. Дополнительные же настройки они просят передавать через my_elasticsearch.yml  В my_elasticsearch.yml  мы изменили настройку, это позволит нам обращаться к рестам elasticsearch по http.  Сделано это в демонстрационных целях, для облегчения запуска плагина. Если вы захотите включить Rest Layer tls придется добавлять соответствующие настройки во все компоненты, которые общаются с elasticsearch. Запуск docker-compose с LDAP интеграцией Запустим проект с помощью docker-compose up , и залогинимся на http://0:5601 под admin/admin Теперь у нас есть вкладка Security Можно посмотреть настройку LDAP через интерфейс кибаны Настройки должны совпадать с файлами конфигурации. Стоит обратить внимание, что плагин хранит свои данные в индексе еластика, и файлы конфигурации применяет при инициализации, т.е. если индекс не создан. Если вы измените файлы позже то вам придется воспользоваться утилитой securityadmin.sh настройка Ldap Для настройки интеграции с  LDAP необходимо заполнить соответствующие секции в elastisearch-opendistro-sec/config.yml, ссылка на официальную документацию по authentication В случае с Active Directory, необходимо будет изменить конфигурационный файл примерно так: Не забудьте воспользоваться securityadmin.sh после изменения конфигурации. Процедура была описана в предыдущем параграфе.   Вернемся к проекту с kubernetes, установим проект командой Нам необходимо будет  Для настройка OpenDistro Security plugin мы скопировали файл конфигурации, которые поместим в секреты kubernetes, в values.yaml добавился блок: Чтобы настройки применялись при команде helm upgrade, мы сделали job, который будет запускаться при каждой команде helm upgrade  Если вы собираетесь организовать централизованную сборку логов для приложений под управление kubernetes, данный вариант мог бы стать вполне обоснованным решением. Все продукты поставляются под открытыми лицензиями. В статье приведена заготовка из которой можно создать production ready решение.  Спасибо за внимание!  Senior Java developer, devops