파드가 수십 개로 늘어나면 kubectl logs 로 하나하나 보는 건 한계가 있습니다. 로그를 한곳에 모아 검색·시각화하려면 로깅 스택이 필요한데, 대표적인 게 EFK(Elasticsearch + Fluentd + Kibana) 입니다.
구성 요소
- Fluentd: 각 노드에서 로그를 수집하는 수집기입니다. DaemonSet으로 모든 노드에 하나씩 떠서,
/var/log/containers/*.log를 읽어 Elasticsearch로 보냅니다. - Elasticsearch: 로그를 색인·저장하고 검색을 제공하는 저장소입니다.
- Kibana: Elasticsearch의 데이터를 검색·시각화하는 웹 UI입니다.
Fluentd 수집 설정의 핵심
Fluentd는 ConfigMap으로 동작을 정의합니다. 두 가지가 특히 중요해요.
1. 컨테이너 런타임 로그 포맷 — containerd/CRI-O 환경에서는 로그 파서를 cri 로 맞춰야 정상 파싱됩니다. (예전 Docker 시절 포맷과 다릅니다.)
<source>
@type tail
@id in_tail_container_logs
path /var/log/containers/*.log
pos_file /var/log/fluentd-containers.log.pos
tag kubernetes.*
read_from_head true
format cri
</source>
2. 인덱스 분리 — 네임스페이스별로 인덱스를 나누면 나중에 검색·보존 정책 관리가 편합니다.
logstash_prefix logstash-${$.kubernetes.namespace_name}
logstash_format true
kubernetes_metadata 필터를 붙이면 각 로그에 네임스페이스·파드·라벨 같은 메타데이터가 자동으로 붙어, Kibana에서 필터링하기 좋아집니다.
배포 순서
Elasticsearch(StatefulSet + PVC + Service) — 저장소가 먼저 떠 있어야 합니다.Fluentd(ConfigMap + DaemonSet) — Elasticsearch 호스트/포트를 환경 변수로 지정합니다.Kibana(Deployment + Service) — Elasticsearch에 연결해 시각화합니다.
Elasticsearch는 메모리를 꽤 먹으니 PVC 용량과 리소스 요청·제한을 넉넉히 잡아두는 게 좋아요.
가벼운 대안: Loki
EFK는 강력하지만 Elasticsearch가 무겁습니다. 리소스가 부담된다면 Grafana Loki 가 좋은 대안입니다. 로그 본문 전체를 색인하지 않고 라벨만 색인해서 훨씬 가볍고, 이미 Grafana를 쓰고 있다면 대시보드를 그대로 활용할 수 있어요.
Loki는 StatefulSet으로 띄우고 filesystem 스토리지에 보존 기간(예: retention_period: 168h, 7일)을 설정하는 식으로 구성합니다. 수집기는 Fluentd 대신 Promtail을 흔히 씁니다.
정리하면, 로그를 깊게 검색·분석하고 싶으면 EFK, 가볍게 모아 보고 Grafana와 통합하고 싶으면 Loki를 고르면 됩니다.