Logging은 시스템(또는 어플리케이션)에서 필수적이다. (Debugging 및 Monitoring 등등의 목적으로)
일반 어플리케이션 환경처럼 Container 환경에서도 Logging이 사용되며 가장 일반적인 방식으로는 stdout, stderr과 같은 표준 입출력 스트림(Standard I/O Stream)을 활용하는 것이다. 하지만 해당 방식은 Container 환경에서는 부적절하다. 보통 Log가 컨테이너에 의존적이기 때문에 예를 들어 Pod, Node 등과 같은 Container 환경에 문제가 생겼을 때 Log에 접근하기가 쉽지 않다. (각 Container에 저장한 Log 파일이 손상되거나 사라질 수 있기 때문에)
그래서 k8s에서는 Cluster Level Logging 방식을 취하고 있다.
Cluster Level Logging
Cluster Level Logging (또는 중앙 집중 로깅 방식)은 Log를 Node, Pod 등과의 별개로 저장소를 가진다. (즉, 자체적인 lifecycle이 존재한다.)
그런데 k8s에서는 자체적으로 제공하는 Cluster Level Logging 방식은 없기 때문에 비슷하게 Logging Architecture를 구현해야한다.
(물론 k8s의 특징상 다양한 솔루션을 함께 사용 할 수 있다.)
k8s에서 고려해 볼만한 Architecture는 아래와 같이 3가지이며 하나씩 살펴보도록 하자.
1) 모든 Node에 Logging Agent 사용 (Logging Agent)
2) Sidecar Container 사용 (SideCar)
3) Backend로 직접 Log 전달 (Direct Logging)
1) Logging Agent
그림 1. Logging Agent
그림 1은 Logging Agent 활용한 Architecture이다. 각 Node에 Logging Agent를 포함하여 Logging Agent를 통해 Log를 Backend에 전달한다.
(즉, Node에서 쌓인 Log를 Backend에 쌓는다.)
이런 방식을 취하고 있는 솔루션은 stackdriver(GCP에서 사용하는 방식)과 Elasticsearch이며 모두다 Node에 fluentd라는 Agent를 사용한다.
2) SideCar
그림 2. SideCar
그림 2는 SideCar를 활용한 Architecture이다. 그림 1과 다른 점이 있다면 그림 2는 SideCar Container를 활용하여 app-container에서 직접 Log를 쓰는 것이 아닌 추가 Container에서 자체 Stream를 사용하여 Log를 쓴다.
특히 app-container에서 Stream을 사용하게 하지 않기 때문에 디스크를 2번 사용하는 것을 막는다. (내부 로컬 Log 파일, 외부 Log 파일) 반면에 SideCar는 단일 Log 파일만 사용하면 되기 때문에 디스크 사용량이 2배다 좋다. (Container 간의 데이터 전달 속도는 미비하다.) 때문에 SideCar를 통해 다양한 Log Stream을 생성할 수 있다. (즉, SideCar 구성에 따라 달라진다.) 이 방식은 kubectl의 logs에서 사용한다.
그림 3. SideCar With Logging Agent
각 Node의 Logging Agent를 사용하는 방식 외에도 그림 3처럼 SideCar를 Logging Agent로 사용할 수도 있다. 하지만 해당 방식은 Risk가 크게 발생 할 수도 있다. SideCar에서 직접 Backend에 Log를 쌓기 때문에 kubelet에 의해 관리되지 않는다. 다시 말해서 kubelet logs와 같이 kubelet에 연결된 작업은 수행 할 수 없다.
3) Direct Logging
그림 4. Direct Logging
그림 4와 같이 app-container의 Log를 직접적으로 Backend에 쌓을 수도 있다. 하지만 해당 architecture는 k8s의 범위에 속하는 부분이 아니다.
Reference
'IT > Kubernetes' 카테고리의 다른 글
[Kubernetes] Storage - PersistentVolume (0) | 2019.04.21 |
---|---|
[Kubernetes] Storage - Volume (0) | 2019.04.21 |
[Kubernetes] Monitoring (0) | 2019.04.10 |
[Kubernetes] Job & CronJob (1) | 2019.04.06 |
[Kubernetes] Ingress (0) | 2019.03.31 |
댓글