[ 쿠버네티스 입문: 90가지 예제로 배우는 컨테이너 관리 자동화 표준 ] Chapter17. 로깅과 모니터링

17.1 로깅

 

오케스트레이터를 사용하는 환경에서 로그를 수집할 때 로그를 로컬 디스크에 파일로 저장하지 말아야 함.

 

쿠버네티스는 특정 앱 컨테이너의 로그를 확인하려면 전체 클러스터의 노드 중 어떤 노드에 해당 컨테이너가 실행되었는지 확인해야 로그도 확인이 가능함.

 

1. 파드 로그 확인하기

‘Kubectl logs -f 파드이름’ : 파드의 로그 확인

 

   2. 일래스틱서치로 로그를 수집한 후 모아서 보기

 

로컬 디스크에 로그를 저장하면 용량 문제로 삭제한 예전 로그들을 확인할 수 없음.

 

장비 각각에 저장한 로그를 한 곳에 모아서 살펴보도록 서버를 구축함.

 

<로그를 수집할 일래스틱서치>

일래스틱서치 파드를 배포하고 서비스를 붙여 외부에 노출시킴.

 

<일래스틱 전용 대시보드 UI인 키바나를 함께 사용>

 

키바나는 일래스틱서치의 데이터를 검색하므로 접근할 도메인을 알아야함. env의 ELASTICSEARCH_URL=‘주소값’을 줌

   

     3. 클러스터 레벨 로깅

 

컨테이너가 비정상 종료되거나 노드에 장애가 있더라도 앱 컨테이너의 로그를 확인 할 수 있어야 함. 그러므로 스토리지는 생명주기와 분리되어야 함. 

 

클러스터 레벨 로깅은 생명주기와 분리된 스토리지를 구축하는 아키텍처임. 자체에서 지원하지 않으므로 외부에서 구축함.

 

• 컨테이너 로그
  컨테이너 수집은 도커(컨테이너 런타임)이 담당함.
• 시스템 컴포넌트 로그
  
  

     4. 플루언트디를 이용해서 로그 수집하기

 

플루언트디는 범용 로그 수집용 오픈소스 프로젝트임. 다양한 플러그인 사용 가능.

• 로그 수집기는 여러대 노드로 구성된 클러스터 모두에 실행해서 로그를 수집해야 하므로 데몬셋 컨트롤러로 생성함.
• .namespace : kube-system으로 설정하여 사용자가 직접 실행한 앱 컨테이너와 분리시킴.
• 환경변수로 플루언트 도메인,포트 등을 설정함.
• 로그 내용은 실제 로그 저장경로를 설정해 볼륨으로 마운트함.

 

    5. 스턴을 이용한 실시간 로그 모니터링

 

실시간 로그 모니터링 도구.
‘stern kube -n kube-system’으로 로그 확인 가능.
: kube로 시작하는 파드들 (네임스페이스는 kube-system)의 로그를 모두 살펴본다는 것.

 

17.2 쿠버네티스 대시보드

 

쿠버네티스는 웹 UI 기반인 쿠버네티스 대시보드를 제공함. 

깃허브에서 kubernetes-dashboard.yaml 다운로드

 

 

 

 

 

• .args 값으로 인증 토큰 없이 접속할 수 있도록 —enable-skip-login과 —enable-insecure-login을 추가
  또한 HTTP로 접속할 수 있도록 —insecure-bind-address와 --insecure-port를 추가

 

 

• nodePort 값을 30880으로 추가
• Port, targetPort값 줌

 

17.3 쿠버네티스 클러스터 모니터링

 

1. 쿠버네티스 모니터링 아키텍처

 

시스템 메트릭과 서비스 메트릭을 수집해서 확인할 수 있음. 

구성요소들을 직접 관리하는 코어 메트릭 파이프라인과 필요한 정보를 모니터링하는 모니터링 파이프라인으로 구성됨

 

• 시스템 메트릭

 

노드나 컨테이너의 CPU, 메모리 사용량 같은 시스템 관련 메트릭

 

코어 메트릭은 내부 컴포넌트들이 사용하는 메트릭. 

현재 사용할 수 있는 자원이 얼마인지 파악함.

‘ Kubectl top ‘ : CPU/메모리, 파드/컨테이너의 디스크 사용량

 

• 서비스 메트릭

애플리케이션을 모니터링할 때 필요한 메트릭.

 

쿠버네티스 인프라 컨테이너에서 수집하는 메트릭은 클러스터를 관리할 때 참고해서 사용 가능.

 

사용자 어플리케이션에서 수집하는 메트릭은 웹 서버의 응답 시간 관련 값 등의 서비스 관련 정보를 파악함.

 

• 코어 메트릭 파이프라인

 

쿠버네티스 관련 구성 요소를 직접 관리하는 파이프라인.

코어 시스템 메트릭을 수집해 핵심 요소의 모니터링을 담당함.

Kubelet, 메트릭 서버, 메트릭 API 등으로 구성됨.

 

kubelet에 내장된 cAdvisor는 노드/파드/컨테이너의 사용량 정보를 수집함.

메트릭 서버는 이 정보들을 kubeletdptj 불러와 메모리에 저장함.

 

• 모니터링 파이프라인

 

기본 메트릭을 포함한 여러 가지 메트릭을 수집함.

클러스터 사용자에게 필요한 모니터링에 사용함. 외부시스템과 연계되어있음.

시스템 메트릭과 서비스 메트릭 모두 수집 가능. 원하는 모니터링 도구를 조합해서 쓰면 됨.

 

• 모니터링 아키텍처의 전체 구조

 

   2. 힙스터

 

기본 모니터링 도구.

파드로 실행함. kube-apiserver와 통신해서 전체 클러스터의 노드와 파드 현황 목록을 불러온 후 모니터링에 필요한 데이터들을 수집함.

힙스터는 노드 각각의 kubelet에 접근해 각각의 메트릭을 수집하는 도구인 cAdvisor로 데이터를 불러옴.

그리고 별도의 스토리지 백엔드에 저장함. (데이터 조회시 그라파나 사용)

 

   3. 메트릭 서버

 

코어 메트릭 파이프라인을 효율적으로 사용하기 위해 모니터링 표준으로 도입한것.

kubelet으로 수집해 메모리에 저장한 파드나 노드의 메트릭 데이터를 kube-apiserver로 조회하는 메트릭 API를 제정함.

데이터는 메모리에 보관함.

 

   4. 프로메테우스

 

• 주요 기능

데이터 수집 시 시계열 데이터 저장 가능. 전용 쿼리 언어(PromQL) 사용.

수집 대상은 정적 혹은 동적으로(서비스 디스커버리 사용) 설정 가능. 

외부에서 직접 푸시한 모니터링 데이터를 푸시 게이트웨이로 받아서 저장 가능.

모니터링 데이터는 단순하게 디스크에 저장. 필요 시 외부 스토리지 사용 가능

 

• 아키텍처

프로메테우스 서버 : 시계열 데이터를 수집해 저장함

클라이언트 라이브러리 : 프로메테우스에서 데이터를 수집하도록 만드는 라이브러리

푸시 게이트웨이 : 클라이언트에서 직접 프로메테우스로 데이터를 보낼 때 받는 역할

익스포터 : 프로메테우스 클라이언트 라이브러리를 내장해 만들지 않은 애플리케이션에서 데이터를 수집함. 

알림 관리자 : 알림을 보낼 때 중복 처리, 그룹화 등을 하며 알림을 어디로 보낼지 관리함.

 

• 프로메테우스와 그라파나 연동