DaemonSet (Рекомендуем)
Агент LogKit запускается на каждом узле кластера. Он собирает логи со всех контейнеров, используя Docker API или CRI. Это обеспечивает низкую задержку (p99 < 20ms) и не увеличивает количество подов.
Блог / Kubernetes
Как настроить сбор логов
Как настроить сбор логов
в Kubernetes
Полное руководство по внедрению LogKit в кластер. DaemonSet, Sidecar, конфигурация Helm и фильтрация по namespace.
Введение
Зачем логи в K8s — это отдельная история
Kubernetes меняет подход к логированию. Эфемерные поды, множество контейнеров на одном узле и динамическая природа кластера делают классический подход «логгировать всё на диск» неэффективным.
LogKit решает эту задачу, предлагая гибкую архитектуру, которая интегрируется с жизненным циклом вашего кластера. Мы поддерживаем три основных паттерна интеграции, позволяя выбрать оптимальный для вашего стека.
Архитектура
DaemonSet vs Sidecar vs Node-level
Выбор правильного паттерна интеграции критичен для производительности и удобства отладки.
Sidecar
Отдельный контейнер с агентом в том же поде, что и ваше приложение. Идеально для изоляции логов приложения от системных, но увеличивает нагрузку на ресурсы узла (CPU/RAM).
Node-level
Агент работает на хост-системе (hostNetwork: true). Позволяет собирать системные логи (kubelet, journald) и логи контейнеров без использования Docker API. Требует прав root.
Установка
Пошаговая инструкция
Установка LogKit в кластер Kubernetes занимает менее 5 минут.
-
Добавьте репозиторий Helm:
helm repo add logkit https://charts.logkit.io -
Установите чарт:
helm install logkit logkit/logkit --namespace logkit --create-namespace -
Проверьте статус:
kubectl get pods -n logkit
По умолчанию LogKit автоматически обнаруживает все поды в кластере и начинает отправлять логи в ваш инстанс платформы. Для настройки фильтров используйте ConfigMap.
Конфигурация
Примеры YAML-конфигураций
Настройте сбор логов для конкретных сервисов, используя фильтры.
// configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: logkit-agent-config
namespace: logkit
data:
config.yaml: |
filters:
- name: filter-namespace
type: namespace
value: production
outputs:
- name: logkit-api
type: http
endpoint: https://ingest.logkit.io/v1/logs
// deployment.yaml (DaemonSet)
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: logkit-agent
namespace: logkit
spec:
selector:
matchLabels:
app: logkit-agent
template:
metadata:
labels:
app: logkit-agent
spec:
containers:
- name: agent
image: logkit/agent:latest
volumeMounts:
- name: config
mountPath: /etc/logkit/config
volumes:
- name: config
configMap:
name: logkit-agent-config
Фильтрация
Фильтрация по namespace и label
Часто нужно собирать логи только для критических сервисов или исключить системные поды из общего потока. LogKit позволяет это сделать на уровне агента.
Используйте директиву exclude_labels или include_namespaces в конфигурационном файле YAML. Это снижает нагрузку на сеть и ускоряет индексацию.
// Пример исключения системных подов
filters:
- name: exclude-system
type: label
key: k8s-app
value: kube-dns
Troubleshooting
Типичные ошибки и как их избежать
Самые частые проблемы при внедрении LogKit в Kubernetes.
Permission Denied
Агент не может читать логи контейнеров из-за ограничений безопасности (Pod Security Policies). Решение: использовать fsGroup или securityContext с нужными правами.
CrashLoopBackOff
Агент падает при старте. Проверьте конфигурацию ConfigMap — синтаксис YAML должен быть валидным. Также убедитесь, что агент имеет доступ к API сервера K8s.
Disk Space Full
Логи пишутся на диск узла, а не сразу в LogKit. Настройте max_size_mb и flush_interval в конфиге агента, чтобы буфер не переполнялся.
Готовы улучшить наблюдаемость?
Прочитайте полную документацию по интеграции с Kubernetes или свяжитесь с инженерами для настройки Enterprise-решения.