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

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

Что такое паттерн Sidecar-контейнера и почему его следует использовать для управления логами?

Паттерн Sidecar относится к вспомогательному контейнеру, который работает рядом с контейнером основного приложения в Pod'е. Поскольку этот вспомогательный контейнер работает в том же Pod'е, что и основной контейнер, он разделяет те же сетевые и дисковые ресурсы. Эта функция позволяет Sidecar легко захватывать вывод основного приложения или взаимодействовать с ним.

Специально для управления логами контейнер Sidecar предлагает следующие преимущества:

• Разделение обязанностей (Separation of Concerns): Единственной ответственностью основного приложения становится выполнение бизнес-логики, в то время как задача сбора и пересылки логов делегируется Sidecar.
• Гибкость и независимые обновления: Агент сбора логов (Sidecar) может быть обновлен или заменен независимо от основного приложения. Это позволяет изменять стратегии логирования без необходимости перекомпиляции или повторного развертывания самого приложения.
• Стандартизация: Вы можете стандартизировать процесс сбора логов для всех приложений, используя один и тот же образ Sidecar.
• Централизованная интеграция управления логами: Sidecar может быть настроен для отправки собранных логов в централизованную систему управления логами (например, Elasticsearch, Loki, Splunk и т. д.).

Практическое применение: Sidecar для сбора логов с Fluent Bit в Kubernetes

Теперь перейдем к практическому примеру, демонстрирующему, как собирать и обрабатывать логи из простого приложения Nginx с использованием Sidecar-контейнера на базе Fluent Bit. В этом примере Nginx будет записывать свои логи в общий том, а Fluent Bit Sidecar будет читать эти логи и направлять их в свой стандартный вывод (stdout). В реальном сценарии Fluent Bit будет отправлять логи в Kafka, Elasticsearch или другую приемник логов.

1. Создание тома EmptyDir для совместного использования логов

Основному приложению (Nginx) нужен каталог для записи логов, и Sidecar будет читать эти логи из того же каталога. Для этой цели мы можем использовать том emptyDir.

2. Определение приложения Nginx и контейнера Fluent Bit Sidecar

Приведенное ниже определение развертывания Kubernetes включает контейнер основного приложения Nginx и контейнер Fluent Bit Sidecar для сбора логов. Fluent Bit настроен для чтения логов, которые Nginx записывает в каталог /var/log/nginx.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-with-log-sidecar
  labels:
    app: nginx-logging
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-logging
  template:
    metadata:
      labels:
        app: nginx-logging
    spec:
      volumes:
        - name: nginx-logs
          emptyDir: {}
        - name: fluentbit-config
          configMap:
            name: fluentbit-log-sidecar-config
      containers:
        - name: nginx-app
          image: nginx:latest
          ports:
            - containerPort: 80
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx # Nginx будет записывать логи сюда
          lifecycle:
            postStart:
              exec:
                command: ["/bin/sh", "-c", "while true; do echo \"$(date) Nginx access log entry\" >> /var/log/nginx/access.log; sleep 5; done"]
        - name: fluentbit-sidecar
          image: fluent/fluent-bit:latest
          command: ["fluent-bit", "-c", "/fluent-bit/etc/fluent-bit.conf"]
          volumeMounts:
            - name: nginx-logs
              mountPath: /var/log/nginx
            - name: fluentbit-config
              mountPath: /fluent-bit/etc/fluent-bit.conf
              subPath: fluent-bit.conf
          resources:
            limits:
              memory: "64Mi"
              cpu: "100m"
            requests:
              memory: "32Mi"
              cpu: "50m"

3. Конфигурация Fluent Bit (ConfigMap)

Нам необходимо создать ConfigMap для файла конфигурации Fluent Bit, который определяет, как Fluent Bit будет читать и обрабатывать логи. Этот ConfigMap будет использоваться томом fluentbit-config в приведенном выше развертывании.

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-log-sidecar-config
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush        1
        Log_Level    info
        Daemon       off
        Parsers_File parsers.conf

    [INPUT]
        Name        tail
        Path        /var/log/nginx/access.log # Путь к файлу логов Nginx
        Tag         nginx_access_log
        Read_from_Head true

    [OUTPUT]
        Name   stdout
        Match  *

Приведенная выше конфигурация Fluent Bit:

• Раздел [INPUT] постоянно отслеживает (tail) файл /var/log/nginx/access.log.
• Раздел [OUTPUT] направляет прочитанные логи на стандартный вывод контейнера Fluent Bit. Это позволяет просматривать логи с помощью команды kubectl logs <pod-name> -c fluentbit-sidecar.

Как это работает

Когда вы примените эту конфигурацию к своему кластеру Kubernetes:

1. Будет создан Pod.
2. В этом Pod'е запустятся контейнер Nginx и Sidecar-контейнер Fluent Bit.
3. Контейнер Nginx начнет записывать логи в файл /var/log/nginx/access.log.
4. Fluent Bit Sidecar будет отслеживать файл /var/log/nginx/access.log в том же общем томе.
5. Он будет читать новые записи логов и направлять их на свой стандартный вывод.

Чтобы убедиться в этом, вы можете выполнить следующую команду с именем Pod'а:

kubectl logs <nginx-with-log-sidecar-POD_ID> -c fluentbit-sidecar

В выводе вы увидите записи логов, сгенерированные Nginx. Это указывает на то, что Sidecar успешно собрал и обработал логи.

Расширенные сценарии и лучшие практики

• Управление ресурсами: Установка ограничений CPU и памяти для Sidecar-контейнеров важна для того, чтобы не влиять на потребление ресурсов основным приложением. Легкие агенты, такие как Fluent Bit, обычно потребляют мало ресурсов.
• Устойчивость: Убедитесь, что основное приложение продолжает работать, если Sidecar столкнулся с ошибкой. Как правило, проблемы Sidecar не должны останавливать основное приложение.
• Горячая перезагрузка (Hot Reload): Некоторые агенты Sidecar поддерживают «горячую» перезагрузку без необходимости перезапуска контейнера при изменении конфигурации.
• Сжатие и шифрование: Логи могут содержать конфиденциальную информацию. Применение сжатия и шифрования перед отправкой их в центральную систему сохраняет пропускную способность и повышает безопасность.

Заключение

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