Kubernetes Observability: sidecar logging14.06.2023 11:16

0138be221351598f183938835a78e7ce.png

5426c1005086c2c0b9dbf3558396cb78.jpgАвтор статьи: Рустем Галиев

IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM

Привет Хабр!

Реальный кластер Kubernetes управляет сотнями или даже тысячами подов. Для каждого пода есть как минимум один контейнер, в котором запущен процесс. Каждый процесс может производить вывод журнала в стандартный поток вывода или стандартные потоки ошибок. Крайне важно записывать выходные данные журнала, чтобы точно определить основную причину ошибки приложения. Кроме того, компоненты кластера создают журналы (логи и далее будут логи) для диагностических целей.

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

Ведение логов кластера

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

  • Создание экземпляра агента ведения логов на уровне каждой ноды кластера.

  • Настройка sidecar-контейнера, отвечающего за обработку логов приложений.

  • Отправка логов непосредственно в серверную часть ведения логов из логики приложения.

Давайте займемся sidecar опцией

Pod можно настроить для запуска другого контейнера sidecar вместе с контейнером основного приложения. Контейнер sidecar передает стандартный вывод и ошибки, создаваемые приложением, и перенаправляет потоки в другое место (например, в серверную часть ведения журнала или том, подключенный к контейнеру).

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

Для этого нам необходимо:

  1. Настроить под с сайдкаром,

  2. Примонтировать том (Volume) для обмена данными между контейнерами,

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

  4. Запуск лог комманды для сайдкар контейнера.

Шаг первый

Мы должны реализовать ведение журнала на уровне кластера с помощью sidecar-контейнера.

Определяем многоконтейнерный под с именем multi в файле multi-container.yaml. Основной контейнер приложения с именем nginx должен использовать образ nginx:1.21.6. Контейнер sidecar с именем streaming использует образ busybox:1.35.0 и аргументы /bin/sh, -c, 'tail -n+1 -f /var/log/nginx/access.log'. Пока не создавайте Pod.

Начнем с создания начальной точки YAML для пода в файле с именем multi-container.yaml. Следующая команда создает файл:

64d8d3aa86e10dcc3bf7821bd65389a7.png

Редактируем манифест YAML. Мы добавляем контейнер sidecar в spec.containers[]. Содержимое файла YAML будет выглядеть следующим образом: 

apiVersion: v1
kind: Pod
metadata:
  name: multi
  namespace: log
spec:
  containers:
  - image: nginx:1.21.6
	name: nginx
  - image: busybox:1.35.0
	name: streaming
	args: [/bin/sh, -c, 'tail -n+1 -f /var/log/nginx/access.log']

Пока не создавайте Pod, так как нам потребуется дополнительно отредактировать манифест YAML.

Шаг два: Установка тома в оба контейнера

Мы определяем том типа emptyDir для пода и монтируем его по пути /var/log/nginx для обоих контейнеров.

Редактируем наш манифест yaml

apiVersion: v1
kind: Pod
metadata:
  name: multi
  namespace: log
spec:
  containers:
  - image: nginx:1.21.6
    name: nginx
    volumeMounts:
    - name: accesslog
      mountPath: /var/log/nginx
  - image: busybox:1.35.0
    name: streaming
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/nginx/access.log']
    volumeMounts:
    - name: accesslog
      mountPath: /var/log/nginx
  volumes:
  - name: accesslog
    emptyDir: {}


Создаем

f425fba42fe46074a9408ff2877e161c.png

Шаг 3. Доступ к конечной точке и журналам

Мы обращаемся к конечной точке службы nginx пару раз, используя команду wget или curl. Осматриваем логи сайдкара.

Определяем IP-адрес Pod. В приведенном ниже примере IP-адрес 10.244.1.2:

d36c0224ea58bf91b07d521610cd99e2.png

Делаем три вызова nginx с помощью временного пода:

kubectl run tmp --image=busybox -n log --restart=Never -it --rm -- wget 10.244.1.2

a2d0c7ad9ca1bbce04199623b65e4c1c.png

В журналах потокового контейнера есть три записи:

b5e2f24899569249015002ca33f50cb8.png

Все отлично работает и Вы восхитительны.

Завершить статью хочу полезной рекомендацией. Уже скоро у моих коллег из OTUS пройдет бесплатный вебинар, на котором будет рассмотрено построение графиков из различных источников данных при помощи Grafana. Лекторы расскажут про историю проекта, использование различных источников, хранилище дашбордов, формирование и версионирование собственных дашбордов. Регистрация на вебинар доступна по ссылке ниже.

© Habrahabr.ru