Logging Architecture
로그들은 에러를 디버깅하거나 클러스터의 status에 대해 자세히 알 수 있다. 앞에서 말한 목적때문에 대부분의 애플리케이션들은 standard output으로 로그파일을 남기고 있다.
그러나, 컨테이너 엔진 혹은 이전의 애플리케이션의 로깅 방법은 쿠버네티스에서의 로그 확인에 적절하지 않다. 사용자는 컨테이너 crash, pod 삭제, node VM이 죽는 경우에도 로그를 확인을 원할 수 있다.
그러므로, 로그는 모니터링 하고자 하는 쿠버네티스와는 무관한(별개의) storage와 lifecycle을 가져야한다.
이러한 컨셉을 cluster-level-logging 이라고 부른다. cluster-level-logging은 각각의 분리된 저장소, 분석 솔루션, 대시보드가 필요하다. 쿠버네티스는 로그 데이터를 위한 storage solution을 제공해주지 않는다. 쿠버네티스에서는 여러 로그 처리 방법을 추천하므로, 이 중 필요한 것을 적절히 써야 한다.
Basic logging in Kubernetes
apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
$ kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml pod "counter" created $ kubectl logs counter 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 ...
Logging at the node level
Cluster-level logging architecture
방법1. 모든 node에서 동작하는 node-level logging agent 활용(바로가기)
방법2. 각각의 application pod에 로깅을 위한 sidecar 합치기(바로가기)
방법3. application이 특정 로깅 db에 직접 log를 푸시(바로가기)
사이드카 컨테이너 로깅은 이미 node-level logging agent가 심어져 있는 경우에 효과적이다.
apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {}
apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-log-1 image: busybox args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log'] volumeMounts: - name: varlog mountPath: /var/log - name: count-log-2 image: busybox args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log'] volumeMounts: - name: varlog mountPath: /var/log volumes: - name: varlog emptyDir: {}
$ kubectl logs counter count-log-1 0: Mon Jan 1 00:00:00 UTC 2001 1: Mon Jan 1 00:00:01 UTC 2001 2: Mon Jan 1 00:00:02 UTC 2001 ... $ kubectl logs counter count-log-2 Mon Jan 1 00:00:00 UTC 2001 INFO 0 Mon Jan 1 00:00:01 UTC 2001 INFO 1 Mon Jan 1 00:00:02 UTC 2001 INFO 2 ...
하지만, 이러한 방식은 file로 로그도 떨어뜨리고 stdout으로도 로그를 떨어트리므로 disk를 두배로 사용하게 될것이다.
사이드카 컨테이너 로그 에이전트 방식은 리소스 낭비가 심하다. 또한, kubectl logs 명령어를 사용해서 로그를 볼 수도 없다. 이미 사이드카 컨테이너가 사용하고 있기 때문이다!!
apiVersion: v1 data: fluentd.conf: |
(2) pod의 sidecar 설정
apiVersion: v1 kind: Pod metadata: name: counter spec: containers: - name: count image: busybox args: - /bin/sh - -c - > i=0; while true; do echo "$i: $(date)" >> /var/log/1.log; echo "$(date) INFO $i" >> /var/log/2.log; i=$((i+1)); sleep 1; done volumeMounts: - name: varlog mountPath: /var/log - name: count-agent image: k8s.gcr.io/fluentd-gcp:1.30 env: - name: FLUENTD_ARGS value: -c /etc/fluentd-config/fluentd.conf volumeMounts: - name: varlog mountPath: /var/log - name: config-volume mountPath: /etc/fluentd-config volumes: - name: varlog emptyDir: {} - name: config-volume configMap: name: fluentd-config
상기와 같이 설정하게 되면 stackdriver interface에서 로그를 확인 가능하다.
단순하게 application이 직접 로그를 푸시하는 경우가 있을 것이다. 그러나 쿠버네티스 외부의 로깅 api를 application 내부에서 써야한다는 점이 있다.
출처 : Kubernetes logging architecture(https://kubernetes.io/docs/concepts/cluster-administration/logging/)
'DevOps > 쿠버네티스' 카테고리의 다른 글
Elasticsearch와 Kibana, filebeat 를 활용한 쿠버네티스 로깅 아키텍쳐 (1088) | 2018.08.29 |
---|---|
쿠버네티스 Multi-container pod 종류 및 예제 (969) | 2018.07.08 |
쿠버네티스 kubectl 설명 및 예제 모음 (945) | 2018.07.07 |
쿠버네티스 RBAC(Role-based Access Control) 상세 설명 및 예제 (1314) | 2018.06.26 |
[쿠버네티스 기초]spring boot rest application POD 배포하기(part2) (1090) | 2018.06.26 |
[쿠버네티스 기초]spring boot rest application POD 배포하기(part1) (1449) | 2018.06.25 |