1. Logging
1.1. 정의
컨테이너 오케스트레이션 플랫폼인 쿠버네티스에서 발생하는 애플리케이션 및 시스템 로그를 관리하기 위한 프로세스다. 애플리케이션 및 인프라스트럭처의 상태 및 동작을 추적하고, 문제를 진단하며, 보안 및 규정 준수를 유지하는 데 도움을 준다.
1.2. 로그의 종류
● 노드 로그
노드 레벨의 로그
● 컨트롤 플레인 (API Server, Scheduler, Controller Manager) 로그
쿠버네티스의 오브젝트에 대한 이벤트로는 원인을 파악하기 힘들 경우 컨트롤 플레인에 대한 로그를 통해 보다 쉽게 원인을 파악할 수도 있습니다. 이러한 로그는 호스트의 /var/log/ 디렉토리 아래에 존재합니다.
● Audit 로그
시스템 내부에 누가 무엇을 했는지에 대한 로그로 보안에 관련된 모니터링을 위해 사용합니다. 하지만 대규모의 클러스터 환경에서는 로그 양에 의해 시스템 부하가 발생할 수 있으므로 가이드를 참고하여 구성해야합니다.
● 애플리케이션 컨테이너 로그
애플리케이션의 상태에 대한 Observability를 제공합니다. 애플리케이션을 수집하는 방식은 직접 STDOUT을 통해 내보내거나 Sidecar를 사용하는 방법과 같이 여러 방법이 존재합니다. 자세한 내용은 관련 문서에서 확인하실 수 있습니다.
1.3. 노드 레벨에서의 로깅
컨테이너화 된 애플리케이션의 stdout(표준출력), stderr(표준에러) 스트림에 의해 생성된 모든 출력을 컨테이너 엔진이 처리 및 리디렉션한다.
기본적으로, 컨테이너가 다시 시작되면, kubelet은 종료된 컨테이너 하나를 로그와 함께 유지한다. 파드가 노드에서 축출되면, 해당하는 모든 컨테이너도 로그와 함께 축출된다.
노드-레벨 로깅에서 중요한 고려 사항은 로그 로테이션을 구현하여, 로그가 노드에서 사용 가능한 모든 스토리지를 사용하지 않도록 하는 것이다. 쿠버네티스는 로그 로테이션에 대한 의무는 없지만, 디플로이먼트 도구로 이를 해결하기 위한 솔루션을 설정해야 한다.
1.3.1. 시스템 컴포넌트 로그
Kubernetes 자체 시스템 컴포넌트들의 로그는 '컨테이너에서 실행되는가'의 조건으로 2가지로 나눌 수 있다.
컨테이너에서 실행된다: kubernetes scheduler, kube-proxy
항상 /var/log 디렉토리에 기록
컨테이너에서 실행되지 않는다: kubelet , container runtime
systemd를 사용하는 시스템이면 journald에 작성
systemd를 사용하지 않는 시스템이면 /var/log 디렉터리의 .log 파일에 작성
시스템 컴포넌트는 klog 로깅 라이브러리를 사용한다.
kube-up.sh 스크립트로 구축한 쿠버네티스 클러스터에서 로그는 크기가 100MB를 초과하면 logrotate 도구에 의해 로테이트가 되도록 구성된다.
1.4. 클러스터 레벨에서의 로깅
각 노드에 에이전트를 포함시켜 클러스터 레벨 로깅을 구현하는 방법
로깅 에이전트는 로그를 노출 및 백엔드로 푸시하는 도구
노드마다 존재해, 노드에 존재하는 모든 컨테이너의 로그파일에 접근할 수 있어야 한다.
에이전트는 노드별 하나씩 존재해야하므로, DaemonSet 으로 동작시키는 것이 추천된다.
1.5. 사이드카 컨테이너 사용
● 사이드카 컨테이너 스트리밍
○ 사이드카 컨테이너가 애플리케이션 로그 자체를 원하는 형식으로 받아 stdout 으로 스트리밍 (로깅 에이전트 별도)
● 로깅 에이전트 사이드카 컨테이너
○ 사이드카 컨테이너가 로깅 에이전트를 실행하며, 애플리케이션 컨테이너에서 로그를 가져오도록 구성