[k8s] 44. Logging

Kubernetes Logging / Monitoring Architectures

• Logging: App의 로그 데이터
• Monitoring: 메모리나 CPU와 같은 자원
• 쿠버네티스 자체적으로 제공하는 Core Pipeline, 추가적으로 플러그인을 설치한 Service Pipeline이 있음

1. Core Pipeline

• Worker Node에는 Kubelet과 Container Runtime 영역이 있음
• 파드 생성요청을 받으면 kubelet은 파드를 만들고, 컨테이너 생성은 Container Runtime에 맡김
• 도커가 Worker Node의 Disk를 쓰면서 데이터를 생성하고 로그도 생성
• 서비스가 기동되면서 컨테이너는 CPU와 메모리도 사용
• 각 노드에 있는 kubelet은 별도로 설치된 Resource Estimator인 cAdvisor를 통해 도커로부터 CPU, 메모리 정보를 가져올 수 있음
• 각 노드의 모니터링 정보는 metrics-server로 모아지고 사용자는 kubectl top 명령어로 kube-apiserver를 통해 정보 조회
• kubectl log 명령어로 컨테이너 내 로그도 조회 가능

2. Service Pipeline

• kubelet처럼 모든 노드마다 설치되어 데이터를 가져오는 역할을 하는 Agent
• Agent는 Daemonset으로 설치됨
• Agent는 cAdvisor, Container Runtime, Worker Node를 통해 로그나 리소스를 수집
• Metric Aggregator/Analytics: 별도의 Worker Node에서 Metric Server와 같이 각각의 Metric을 수집하고 분석하는 서버영역
• 많은 Metric이 있어 별도의 Metric Store 필요
• Web UI: 수집서버로 쿼리를 하면서 필요한 정보를 사용자에게 보여줌
• Elastic, Logi, Prometheus 등의 제품이 있음

Logging Architectures

• Node-level, Cluster-level로 나뉨
• Node: 단일 노드 로그, Cluster: 모든 노드 로그 포괄

1. Node-level Logging

• 컨테이너의 로그 설정은 /etc/docker의 daemon.json에 있음
• max-size: 로그의 최대 사이즈
• max-files: 로그 파일의 최대 개수
• 파드의 컨테이너 수행 중 로그내용을 Container Runtime으로 stdout, stderr로 출력해야 함
• 이 로그들은 Container Runtime의 /var/lib/docker/containers/<Container-ID>.json.log로 만들어짐
• 이 파일을 쿠버네티스에서 Worker Node에 Link함
• 링크한 위치는 /var/log/pods/<Namespace>_<Pod-Name>_<Pod-ID>/<Container-Name>/0.log로 만들고 이걸 또
• /var/log/<Pod-Name>_<Container_Name>_<Container_ID>.log로 링크
• 이 상태에서 파드가 죽으면 Container Runtime의 로그 파일이 삭제됨
• 따라서 파드가 죽고 나서 로그를 보기 위해 Cluster-level Logging이 필요
• Termination Message Path: 컨테이너 안의 /dev/termination-log를 가리키는 경로
• Container가 죽거나 재시작될 때 왜 그런지 /dev/termination-log에 기록함
• 쿠버네티스가 다시 살아나면 /dev/termination-log를 바탕으로 파드의 상태 기록
• Event도 관련 로그가 있음

2. Cluster-level Logging

Node Logging Agent

• 위에 설명한 Node-level Logging이 있음
• 이 구조에 DaemonSet을 둬서 Worker Node에 만들어지는 각 경로의 로그들을 읽는 형태
• Container Runtime에 있는 Log Driver를 수정해서 Worker Node에 로그를 기록하는게 아니라 바로 DaemonSet의 파드에 기록 가능
• 이렇게 수집한 로그를 수집 서버로 전송하는 패턴

Sidecar Container Streaming

• 한 컨테이너에서 access.log, app.log가 쌓인다고 가정
• 이 로그를 stdout으로 Worker Node에 기록하면 파일이 하나로 기록되니 복잡
• 따라서 access, app별로 컨테이너를 둬서 각 컨테이너가 Worker Node로 stdout으로 출력하게 함

Sidecar Container with a logging agent

• Logging Agent를 Sidecar 형태로 파드 안에 집어 넣음
• app 컨테이너는 stdout으로 Worker Node에 출력하지 않아도 Logging Agent Container에 의해서 로그가 수집이 되고 서버로 전송

Logging / Monitoring Plugin

1. Logging/Monitoring Stack

• 대부분의 로깅과 모니터링 플러그인은 Web UI, Aggregator/Analytics, Agent 구조를 가지고 있음
• 대표적인 오픈소스는 Elastic 솔루션
• Agent를 Fluentd를 사용하는 경우도 있음
• Prometheus도 있고 Grafana UI를 사용하는 경우도 있음
• Loki도 있음
• 여기선 PLG Stack을 할 예정

2. PLG Stack(Promtail + Loki + Grafana)

• 마스터 노드와 워커 노드에 로그파일이 있음
• PLG 스택을 설치하면 Daemonset으로 Promtail이 모든 노드에 설치
• StatefulSet으로 Loki가 설치되고, Loki로 들어오는 서비스를 통해 모든 promtail에서 이 서비스로 로그 푸쉬
• Deployment로 Grafana 설치, 외부에 접속할 수 있게 30000번 NodePort 서비스 연결해서 외부에서 UI로 log 조회 가능

출처

인프런 - 대세는 쿠버네티스 여기서 끝!