kubernetes - log

kubernetes log architecture

• https://kubernetes.io/ko/docs/concepts/cluster-administration/logging/

클러스터-레벨-로깅을 하는 이유?

• 애플리케이션 내부에서 발생하는 상황을 이해하는 데 도움되는것이고,
• 문제를 디버깅하고 클러스터 활동을 모니터링하는 데 특히 유용하다.
• 컨테이너 엔진들도 로깅을 지원하도록 설계되어 있는데,
  • 컨테이너화된 애플리케이션에 가장 쉽고 가장 널리 사용되는 로깅 방법은 표준 출력과 표준 에러 스트림에 작성인데,
  • 컨테이너가 크래시되거나, 파드가 축출되거나, 노드가 종료된 경우에도 애플리케이션의 로그에 접근하고 싶을 것인데, 클러스터에서 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야 하기 때문에 클러스터-레벨-로깅을 해야한다.

• 노드-레벨-로깅
  

  • 컨테이너에서 로깅 드라이버로 리디렉션
    • 컨테이너화된 애플리케이션이 stdout(표준 출력) 및 stderr(표준 에러) 에 쓰는 모든 것은 컨테이너 엔진에 의해 어딘가에서 처리와 로깅 드라이버로 리디렉션한다.
  • 로그 로테이션
    • 로그가 노드에서 사용가능한 모든 스토리지를 사용하지 않도록 정리해야함
    • 기본 : 10MB 초과시 로테이션 처리
  • 시스템 컴포넌트 로그
    • 컨테이너에서 실행되는것과 컨테이너에서 실행되지 않는것
      • 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다.
        • systemd를 사용하지 않으면, /var/log 디렉터리의 .log 파일에 작성
          • 기본 : 100MB초과 시 로테이션
        • 컨테이너 내부의 시스템 컴포넌트는 기본 로깅 메커니즘을 무시하고, 항상 /var/log 디렉터리에 기록
      • Kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다.
        • systemd를 사용하는 시스템에서, kubelet과 컨테이너 런타임은 journald에 작성

• 클러스터-레벨-로깅

  • 로그는 노드, 파드 또는 컨테이너와는 독립적으로 별도의 스토리지와 라이프사이클을 가져야함

  • 로그를 저장하고, 분석하고, 쿼리하기 위해 별도의 백엔드가 필요함

  • Native Solution 제공하지 않음

  • 고려사항

    • 모든 노드에서 실행되는 노드-레벨 로깅 에이전트(fluentd)를 사용한다.
    • 애플리케이션 파드에 로깅을 위한 전용 사이드카 컨테이너(fluentd안의 log수집기)를 포함한다.
    • 애플리케이션 내에서 로그를 백엔드(Elasticsearch)로 직접 푸시한다 (

  • 방법

    1. 노드 로깅 에이전트 사용 (추천)
       

       • 각 노드에 노드-레벨 로깅 에이전트를 포함시켜 클러스터-레벨 로깅을 구현
       • 로깅 에이전트는 로그를 노출하거나 로그를 백엔드로 푸시하는 전용 도구
       • 일반적으로, 로깅 에이전트는 해당 노드의 모든 애플리케이션 컨테이너에서 로그 파일이 있는 디렉터리에 접근할 수 있는 컨테이너
       • 로깅 에이전트는 모든 노드에서 실행해야 하므로, 이를 데몬셋 레플리카, 매니페스트 파드 또는 노드의 전용 네이티브 프로세스로 구현하는 것이 일반적
       • 쿠버네티스 클러스터는 노드-레벨 로깅 에이전트를 사용하는 것이 가장 일반적이며 권장되는 방법
       • 노드별 하나의 에이전트만 생성
         • 노드에서 실행되는 애플리케이션을 변경할 필요가 없기 때문
         • 노드-레벨 로깅은 애플리케이션의 표준 출력과 표준 에러에 대해서만 작동
       • 추천 : 쿠버네티스 릴리스에는 두 가지 선택적인 로깅 에이전트가 있음
         • Google 클라우드 플랫폼과 함께 사용하기 위한 스택드라이버(Stackdriver) 로깅
         • 엘라스틱서치(Elasticsearch)
       • 이 두가지 모두, 사용자 정의 구성이 된 fluentd를 에이전트로써 노드에서 사용

    2. 로깅 에이전트와 함께 사이드카 컨테이너 사용 (비 추천)

       • 두가지 중, 한 가지 방법으로 사이드카 컨테이너를 사용
         • 사이드카 컨테이너는 애플리케이션 로그를 자체 stdout 으로 스트리밍
           
           • 사이드카 컨테이너를 자체 stdout 및 stderr 스트림으로 스트리밍할 수 있음
             • 각 노드에서 이미 실행 중인 kubelet과 로깅 에이전트를 활용
             • 사이드카 컨테이너는 파일, 소켓 또는 journald에서 로그를 읽는다
             • 각 개별 사이드카 컨테이너는 자체 stdout 또는 stderr 스트림에 로그를 출력한다
           • 이 방법을 사용하면 애플리케이션의 다른 부분에서 여러 로그 스트림을 분리할 수 있음
             • 이 중 일부는 stdout 또는 stderr 에 작성하기 위한 지원이 부족할 수 있다.
             • 로그를 리디렉션하는 로직은 미미하기 때문에, 큰 오버헤드가 거의 없다
             • stdout 및 stderr 가 kubelet에서 처리되므로, kubectl logs 와 같은 빌트인 도구를 사용할 수 있다.
         • 사이드카 컨테이너는 로깅 에이전트를 실행하며, 애플리케이션 컨테이너에서 로그를 가져오도록 구성
           
           • 노드-레벨 로깅 에이전트가 상황에 맞게 충분히 유연하지 않은 경우, 애플리케이션과 함께 실행하도록 특별히 구성된 별도의 로깅 에이전트를 사용하여 사이드카 컨테이너를 생성
             • 예) 로깅 에이전트로 fluentd를 사용하는 스택드라이버를 사용

    3. 애플리케이션에서 직접 로그 노출 (비 추천)
       

       • 모든 애플리케이션에서 직접 로그를 노출하거나 푸시하여 클러스터-레벨 로깅을 구현
       • 이러한 로깅 메커니즘의 구현은 쿠버네티스의 범위를 벗어남