Логирование в Kubernetes

Материал подготовлен командой Simple-Server для администраторов VPS и выделенных серверов. Команды и пути проверяйте на тестовой машине перед production.

Архитектура логирования в Kubernetes

В данном разделе инструкции разберём архитектуру сбора**** логов в Kubernetes.

Ниже будут приведены основные уровни сбора логов:

• Сбор логов на уровне подов.

Каждый под фиксирует логи своих контейнеров, сгенерированные приложением. Вы можете изучить их сразу после создания и настройки пода, используя для этого командную строку.

На картинке выше изображен процесс логирования на уровне контейнеров пода. Здесь некоторый контейнер app-container __ пода __ my-pod __ отправляет логи в стандартные потоки stdout и stderr контейнеризированного приложения, где stdout – это поток вывода, а stderr – ошибок. Агент kubelet, подключенный к среде выполнения контейнера с помощью CRI, отвечает за обработку и контроль логов, собранных контейнером.

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

Кроме того, вы можете столкнуться с ситуацией, когда внутри вашего пода развернуто несколько контейнеров, а логи нужны только от одного из них. Для этого к предыдущей команде необходимо добавить специальный флаг и имя контейнера:

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

Если на рабочих узлах установлена systemd, то kubelet записывает системные логи в journald, а для их чтения используется команда:

Если на узле отсутствует systemd, то запись логов будет осуществляться в log-файлы в каталог /var/log.

• Сбор логов на уровне кластера.

В K8s отсутствует встроенная возможность ведения журнала на уровне кластера. Для ее реализации пользователи используют разные подходы. Ниже приведем два самых распространенных способа обработки логов:

• * Использование агента ведения журналов (`logging-agent`) на уровне узла.

• Использование агента ведения журналов (logging-agent) на уровне узла.

Один из способов сбора и обработки логов в Kubernetes на уровне кластера — это использование агента ведения журналов на уровне узла. Этот агент (например, Fluentd или Logstash) является компонентом, работающим на каждом узле кластера. Он отвечает за сбор, обработку и отправку логов агрегатору. Его интеграция происходит за счет объекта DaemonSet, который добавляет копию агента на каждый рабочий узел кластера.

• * Использование дополнительного контейнера `sidecar` на уровне пода или узла.

• Использование дополнительного контейнера sidecar на уровне пода или узла.

Sidecar — это дополнительный контейнер, который работает вместе с основным контейнером в одном поде или на одном узле. Правильно настроенный sidecar-контейнер собирает логи из файла, сокета или journald, а затем передает их в собственные потоки stdout или stderr.

Для сбора логов разных форматов рекомендуется настраивать несколько sidecar-контейнеров. В таком случае каждый из них будет перенаправлять логи из общего тома в свой поток stdout.

Чтобы посмотреть на собранные логи, можно воспользоваться уже знакомой командой:

Инструменты логирования Kubernetes

В данном разделе инструкции разберём некоторые популярные инструменты с открытым исходным кодом, которые подойдут для сбора логов в Kubernetes.

Fluentd, Fluent Bit и Fluent Operator

Fluentd и Fluent Bit – это два агента ведения логов, которые предназначены для сбора, фильтрации, агрегации и передачи логов в различных средах, в том числе и в Kubernetes. Fluentd больше подойдет для обработки собранных логов из-за наличия различных плагинов. Fluent Bit, в свою очередь, подойдет для сбора логов и их отправки конечным адресатам.

Fluent Operator – это инструмент, разработанный для управления и автоматического развертывания агентов Fluentd и Fluent Bit в среде Kubernetes. Он упрощает процесс их установки, настройки и масштабирования в кластере с помощью ресурсов Custom Resource Definitions (CRD). С помощью Fluent Operator пользователь может развернуть каждый из агентов по отдельности, либо Fluent Bit в сочетании с Fluentd.

Процесс работы с Fluent Operator изображен на следующей картинке:

Ниже перечислены пользовательские ресурсы Fluent Operator:

• Системные ресурсы:

• Input – модуль конфигурации для сбора логов;

• Parser – модуль конфигурации для анализа логов;

• Filter – модуль конфигурации для фильтрации логов;

• OutPut – модуль конфигурации для отправки логов на указанный носитель.

• FluentBit – используется для создания демонов Fluent Bit и его конфига;

• FluentBitConfig – используется для определения набора подключаемых модулей (ввод, вывод, фильтрация), которым будет управлять FluentBit, и генерации финальной конфигурации в виде секрета;

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

Elasticsearch, Logstash и Beats, Kibana (ELK Stack/Elastic Stack)

ELK Stack – это комбинация трех популярных инструментов для сбора, агрегации, обработки и визуализации данных логов: Elasticsearch, Logstash и Kibana. C 2015 года к ним был добавлен Beats для повышения производительности, а весь стек был переименован в Elastic Stack.

• Elasticsearch – это поисковый и аналитический движок, который используется для хранения и индексации структурированных и неструктурированных данных, включая логи.
• Logstash – это агент для сбора, обработки и доставки логов. Иногда вместо него пользователи ставят агент Fluentd, который считается более стандартным решением для среды K8s. В таком случае получается не ELK-стек, а EFK.
• Beats – это облегченные агенты, которые устанавливаются на периферийных хостах для сбора различных типов данных и последующей их пересылки в стек. Например, это может быть Filebeat, Metricbeat, Packetbeat, Winlogbeat и другие.
• Kibana – это инструмент для визуализации и анализа данных, интегрированный с Elasticsearch.

Рабочий процесс ELK Stack представлен на картинке ниже:

Здесь Beats и Logstash совместно выполняют сбор и обработку логов, Elasticsearch хранит их, а Kibana создает визуализацию.

Нужен сервер для практики? Арендуйте VPS/VDS в России — root-доступ, NVMe, DDoS-защита и поддержка 24/7.