Логирование — это один из трех столпов мониторинга в распределенных системах. Мы можем видеть бурное развитие популярных продуктов с открытым исходным кодом типа ELK stack и полноценных коммерческих продуктов, которые помогают с проблемами протоколирования в больших масштабах — Splunk, к примеру. Однако в таких сложных системах как Kubernetes протоколирование остается сложной проблемой. Она усугубляется постоянным ростом объема данных из–за всё большего внедрения контейнеризации.  

В этой статье мы рассмотрим различные виды логов Kubernetes, необходимых для улучшения системы мониторинга, уделим внимание подходам к сбору, агрегации и анализу логов. Также мы приведем решение с использованием open source-сервисов Fluentd и Fluent Bit .

Типы логов Kubernetes 

Логи приложений 

Они интересны нам для дебага проблем и мониторинга активности приложений. Все контейнерные платформы (Docker, containerd, cri-o) поддерживают механизм ведения логов типа stdout/stderr, сюда же можно отнести контроллер ingress, кластерные автоскалеры или cert-manager.

Логи компонентов K8s

Помимо оркестрации приложений, Kubernetes также ведет журналы используемых компонентов, таких как etcd, kube-apiserver, kube-scheduler, kube-proxy и kubelet. Если узел поддерживает Systemd, то kubelet и контейнерные runtimes пишутся в journald.  В ином случае системные компоненты пишут файлы .log в каталог /var/log ноды.

События Kubernetes

Каждое событие Kubernetes регистрируется сервером API и является его объектом. Эти логи содержат важную информацию об изменениях в состоянии ресурсов Kubernetes.

Журналы аудита Kubernetes

K8s также ведет журналы аудита для каждого запроса к серверу API во время его работы. Каждый запрос связан с заданным этапом: RequestReceived, ResponseStarted, ResponseComplete, Panic. Затем это событие обрабатывается в соответствии с политикой аудита, которая подробно описывает его уровни, включая None, Metadata, Request и RequestResponse.

Подходы к ведению журналов в Kubernetes

 Существует два основных способа логирования:

• Логирование в stdout/stderr и использование специальных приложений для сбора и передачи информации во внешнюю систему.

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

В первом случае kubelet отвечает за запись логов контейнеров в /var/log/containers на основной ноде. Kubernetes не предоставляет встроенного механизма для ротации журналов, но файлы журналов удаляются с ноды, когда контейнер с неё удаляют. Сервисы для протоколирования собирают логи и отправляют их на платформы типа Splunk, Sumo Logic или ELK.

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

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

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

Поскольку Kubernetes не предоставляет по умолчанию возможности агрегации логов, агенты часто развертываются на уровне кластера для сбора, агрегации и отправки журналов на центральный бэкэнд.

Fluentd и Fluent Bit

Fluentd и Fluent Bit — это агрегаторы и навигаторы логов, они созданы Cloud Native Computing Foundation (CNCF). Fluentd был первоначальным проектом, нацеленным на решение проблемы агрегации и пересылки логов в масштабе, а Fluent Bit был добавлен позже как облегченная версия Fluentd с аналогичными целями. Каждый проект может использоваться отдельно в роли агрегатора или навигатора. Также возможно объединить оба развертывания.

ELK/EFK

Еще одним популярным инструментом с открытым исходным кодом является стек ELK (Elasticsearch, Logstash и Kibana):

Elasticsearch: индексирует файлы журналов для анализа

Kibana: инструмент визуализации

Logstash: агрегатор журналов

Beats: форвардер логов

Иногда Logstash/Beats заменяется на Fluentd или Fluent Bit для создания стека EFK.

Stackdriver / CloudWatch

При работе в облачной системе (например, GKE, EKS) для логирования можно также использовать родное решение конкретного провайдера. GKE по умолчанию поставляется с поддержкой Stackdriver. На EKS развернуты наборы демонов fluentd, настроенный на передачу логов в Cloudwatch.

Коммерческие инструменты

Также существуют платные программы от Splunk, Sumo Logic, Datadog и других компаний. 

Основы Fluent Operator

Fluent Bit Operator (будет называть Fluent Operator) — это оператор логирования Kubernetes, разработанный командой KubeSphere и переданный в сообщество Fluent. Fluent Operator объединяет преимущества fluentbit (легкий вес) и fluentd (богатая экосистема плагинов) для сбора логов с каждого узла через демонсет fluentbit, которые затем передаются в fluentd для агрегации и пересылки в инструменты анализа логов: elasticsearch, kafka, loki, s3, splunk и другие.

Fluent Operator состоит из: 

FluentBit: Задает Fluent Bit DaemonSet и его конфигурации.

FluentBitConfig: Задает плагины ввода/фильтра/вывода и генерирует окончательную конфигурацию в Secret.

Input: Задает секции конфигурации ввода.

Parser: Задает секции конфигурации парсера.

Filter: Задает секции конфигурации фильтра.

Output: Задает секции конфигурации вывода.

Какие преимущества есть при использовании оператора:

• Пользовательский образ Fluent Bit в KubeSphere поддерживает динамическую перезагрузку конфигурации без перезагрузки подов Fluent Bit.

• Связь между Fluent Bit и Fluentd управляется удобными для пользователя входными и выходными CRD вместо конфигурационных файлов внутри каждого компонента.

• Проще выбирать плагины input/filter/output с помощью меток Kubernetes.

Как обрабатываются логи Kubernetes в KubeSphere

KubeSphere использует Fluent Operator под капотом для сбора и обработки логов. Чтобы включить ведение журналов, введите значение true в параметре logging:

logging:
  enabled: true

Затем на Dashboard вы сможете увидеть компоненты журнала:

Для организации событий Kubernetes введите в параметре events значение true

events:
 enabled: true

Затем вы можете использовать функцию поиска событий из панели инструментов: она поможет вывести журнал событий. 

Для журналов аудита установите в параметре auditing значение true:

auditing:
 enabled: true

Затем вы можете использовать функцию Auditing Operating с помощью панели инструментов: