Kubernetes — мощный инструмент, которым автоматизируются развертывание, масштабирование и управление контейнеризованными приложениями. Однако управлять логами этой экосистемы не всегда просто, особенно для разработчиков в крупномасштабных средах. Расскажем, как собирать и анализировать логи контейнеров Kubernetes, эффективно управлять ими.
Что такое «логи контейнеров Kubernetes»?
Благодаря логам контейнеров в Kubernetes мы получаем представление о поведении отдельных контейнеров, запускаемых в подах. Эти логи необходимы для отладки, мониторинга и получения сведений о производительности приложений. В отличие от традиционных журналов серверов, логи Kubernetes распределены по узлам и подам. Поэтому важно реализовать единое решение логирования.
Архитектура логирования Kubernetes
Сам Kubernetes не занимается хранением и анализом логов. Логи генерируются отдельными контейнерами и собираются агентами логирования, запускаемыми в каждом узле. Затем эти логи агрегируются централизованными решениями логирования.
Вот упрощенная архитектура логирования:
- Логи приложений: генерируются приложением внутри контейнера.
- Логи контейнерного движка: получаются из среды запуска контейнера, например Docker; по ним мониторятся проблемы на уровне контейнера.
- Логи узлов: генерируются самим узлом Kubernetes.
Обычно логи записываются в stdout и stderr, которые затем забираются на проверку в Kubernetes.
Как реализовать логирование в Kubernetes
1. Базовое логирование Kubernetes: kubectl logs
Проще всего логи из контейнеров извлекаются командой kubectl logs:
kubectl logs <pod-name> -c <container-name>
Так извлекаются логи для конкретного контейнера в поде. Если в поде один контейнер, аргумент -c опускается.
2. Сохранение логов драйверами логирования
Логи Kubernetes теряются, если работа пода завершается или узел закрывается. Для их сохранения конфигурируют драйверы логирования, такие как Fluentd из Docker, которыми логи пересылаются во внешнюю службу логирования.
Вот пример конфигурирования Fluentd как драйвера логирования:
apiVersion: v1
kind: Pod
metadata:
name: fluentd-example
spec:
containers:
- name: app
image: my-app:latest
volumeMounts:
- name: log-volume
mountPath: /var/log/app
volumes:
- name: log-volume
hostPath:
path: /var/log/app
3. Централизованное логирование со стеком EFK — Elasticsearch, Fluentd и Kibana
Более масштабируемое решение — реализация стека EFK для сбора, хранения и анализа логов со всех кластеров Kubernetes.
- Fluentd: сборщик данных Open Source, которым агрегируются логи из нескольких источников.
- Elasticsearch: распределенный поисково-аналитический движок.
- Kibana: инструмент визуализации данных для просмотра логов и создания дашбордов.
Вот как разворачивается EFK-стек в Kubernetes:
- Fluentd: логи из подов им собираются и отправляются в Elasticsearch.
- Elasticsearch: здесь логи сохраняются.
- Kibana: логи визуализируются в веб-интерфейсе.
Пример развертывания Fluentd в Kubernetes:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd
spec:
selector:
matchLabels:
name: fluentd
template:
metadata:
labels:
name: fluentd
spec:
containers:
- name: fluentd
image: fluent/fluentd:v1.11
resources:
limits:
memory: "200Mi"
cpu: "100m"
После того как Fluentd развернут, собираются логи из stdout и stderr и направляются для хранения в Elasticsearch и дальнейшего анализа в Kibana.
4. Облачные решения логирования
Для многих приложений производственного уровня управление логами и их анализ упрощаются облачными платформами логирования, такими как Google Cloud Logging, AWS CloudWatch и Azure Monitor.
Большинством облачных провайдеров предлагается бесшовная интеграция с Kubernetes для автоматического сбора, хранения логов и долгосрочного анализа.
Например, чтобы настроить Google Cloud Logging в Kubernetes, конфигурируется агент Stackdriver, которым с узлов Kubernetes логи собираются и отправляются в Google Cloud.
Рекомендации по логированию в Kubernetes
- Выделенное пространство имен для логирования: чтобы избежать конфликтов ресурсов с приложением, выделите инфраструктуру логирования — EFK или другие инструменты — в отдельное пространство имен.
- Ротация и срок хранения логов: чтобы предотвратить исчерпание дискового пространства, внедрите политики ротации логов. Управляйте размерами и сроками хранения логов на каждом узле при помощи инструмента
logrotate. - Избегайте логирования конфиденциальных данных: в логах не должно быть конфиденциальной информации вроде API-ключей, паролей или персональных данных. Проводите очистку логов, где это необходимо.
- Структурированное логирование: для логов используйте JSON или другой структурированный формат. Структурированные логи легче парсить, с ними значительно увеличиваются возможности поиска и фильтрации в инструментах логирования.
- Отслеживайте объем логов: логи быстро накапливаются, а ими расходуются ресурсы. При помощи инструмента Prometheus отслеживайте объем генерируемых логов и соответственно корректируйте политику хранения логов.
- Агрегирование логов в кластерах: при крупномасштабных развертываниях, чтобы агрегировать логи нескольких кластеров Kubernetes в единую систему для упрощения управления, используйте инструменты вроде Loki и Graylog.
Заключение
Логи контейнеров Kubernetes необходимы для понимания производительности и работоспособности контейнернеризованных приложений. Используете вы простые команды kubectl или развертываете полномасштабный стек EFK, благодаря надежной стратегии управления логами устраняются проблемы, отслеживается производительность приложений и обеспечивать стабильность системы.
Реализовав централизованное логирование и следуя рекомендациям, вы получите более полное представление о среде Kubernetes, повысите общую надежность и эффективность.
Читайте также:
- Руководство по устранению неполадок в Kubernetes
- Nelm — полноценная замена Helm
- Результаты тестов сетевых плагинов CNI Kubernetes по сети 40 Гбит/с [2024]
Читайте нас в Telegram, VK и Дзен
Перевод статьи Aman Saxena: Kubernetes Container Logs: How to Implement and Manage Them
