GKE 에서는 Google Cloud's Operations Suite 이라는 로깅, 모니터링, 트러블슈팅을 위한 통합 플랫폼을 지원해준다.

 

여기서는 Google Cloud's Operations Suite 기능들 중 Logging 부분만 집중적으로 살펴보겠다.

 

GKE 에서 로그를 보는 방법은 크게 두 가지가 있다:

  • kubectl log [POD_NAME] 명령을 통해서 보는 방법:
    • Pod 내 컨테이너에서 실시간으로 출력되고 있는 로그를 보는 방법이다.
    • 그러나 Pod 가 재시작하는 경우 로그가 모두 없어진다는 문제가 있다.
  • Google Cloud Logging:
    • GKE 에서 발생시키는 로그는 모두 스트림 처리되서 Google Cloud Logging 라는 곳으로 간다.
    • GCP Console 에서 Google Cloud Logging 에 있는 로그들을 조회할 수 있다. 여기에 어플리케이션 로그 뿐 아니라 시스템 로그와 쿠버네티스 클러스터에서 발생하는 Event 까지 볼 수 있다. 
      • Event 는 Control Plane 에 저장되다가 로그 수집기에 의해서 Cloud Logging 으로 전송된다. 
    • 여기서는 30일치의 로그를 보관하고 있다. 필요하다면 Big Query 나 Cloud Storage 에 전송해서 더 길게 보관할 수 있다.
    • Google Cloud Logging 는 유료 제품이다.
  • 쿠버네티스 노드의 /var/log 디렉토리:
    • 컨테이너에서 발생한 로그들과 쿠버네티스 노드 내에서 발생하는 시스템 로그들 (e.g kubelet, kube-proxy 에서 발생한 로그들) 이 저장되는 곳이다.
    • 여기에 저장된 로그들은 디스크 공간이 가득 차는 현상을 막기 위해서 최근 5개의 로그 파일만 유지되어있다. 나머지는 다 Google Cloud Logging 로 이동되어있음.

 

로그를 지우지 않으면 쿠버네티스의 노드의 디스크 공간을 모두 사용할 여지가 있기 때문에 주기적으로 지워줘야한다.

 

GKE 에서는 기본적으로 Google Cloud Logging 로 로그가 이동하게 되고, Linux의 logrotate 유틸리티를 통해서 자동으로 주기적으로 지워준다.

  • 로그를 관리하는 정책은 1일치의 log file or 100MB 넘는 log file 단위로 관리되며, 최근 5개만 유지한다.
  • 로그가 자동으로 옮겨지는 이유는 GKE 이 모든 노드마다 로그 수집기인 FluentD 가 설치되어있고, 이녀석이 Cloud Logging 으로 로그를 보낸다.
  • Fluentd 는 그러므로 DaemonSet 으로 실행된다. 모든 노드에 동일한 Pod 가 실행되어야하므로.

 

Pod 가 지워질 때는 컨테이너에서 발생시킨 로그도 같이 지워지지만, Pod 내의 컨테이너가 재시작하는 경우라면 이 로그는 유지된다.

  • 재시작 하는 경우는 Liveness Probe 에 실패한 경우, 어플리케이션의 실행 에러, 리소슷 부족으로 인한 경우 등에 발생할 수 있다.

 

Pod 가 갑자기 죽는 경우에는 그 시점의 일부 로그는 Google Cloud Logging 으로 보내지지 못할 수도 있다.

+ Recent posts